I went to Borders today to look for a graduation gift for a friend. I stumbled upon a neat book, “Game Programming Gems” (a play on words with “Programming Pearls”). The book seemed really neat and it reminded me of our final project in cs248. It was quite strange how quickly we were thrown into this project. None of us had any experience in writing a game more complicated than Breakout.

I think one of the silliest things I came across while reading were tutorials on “the game loop”. While it seemed like the logical place to start, the game loop, unfortunately, is not very exciting. It basically looks like this:

init gfx and game state
while (true) {
  check if game is over
  physics engine takes a time step
  handle events
  update display
}

It works wonders when done right. Determining game end conditions should be available through querying the game state. The physics engine should take us from one game state to the next. The physics engine and IO devices may queue events into the event manager. And finally, displaying should be done entirely by querying the game state.

While this is a great way to decompose the game loop and works well in theory, it is quite hard to design a large system to actually hold to all of these ideas. I think seeing the correct data structures would have been much more informative.

Most of balloo is actually pretty well designed. We had a nice separation of data and processing. There were more than a few instances of both the MVC and visitor design patterns. Here are some of the high points (and some ideas we would have done given a second go). I must warn you, though, that these were written long after I looked at any of ballo’s code. Also, I probably idealized what our code did/could look like. I hopefully can try to write a small game that tries to stick to these ideas as an example.

Remember, I haven’t really fully flushed out this example, but if you hit a major roadblock, I want to hear about it.

Entities

Having the notion of an Object or Entity in your game is vital to managing game state. Your game state should simply be a collection of Entity’s. An Entity may be your character, your camera, the landscape, or possibly a light source. I would generally put things that belong as a model in the MVC pattern as an entity. If possible, refer to all Entitys using smart pointers. Disallow the copy constructor and operator=. This ensures that an Entity is unique throughout the system. Another way to think about an entity is to tie it to a “real life” object. (David Cheriton always uses the example of an F-18. You don’t copy them around, only create and modify references to them).

By guaranteeing that an Entity is unique, one can add a very useful feature: naming. Ideally, this would be a heirarchical naming scheme (like a filesystem) but even a primitive naming scheme does wonders. Naming aids in debugging, testing existence, searching, scripting, and loads more.

Components

One thing you may notice is that Entitys can be very different. For instance, your character can move via input controls whereas a tree cannot. You probably care about the hp of an enemy, but not the hp of the landscape. Though it may seem tempting to create an inheritance heirarchy of different Entity types, I would recommend against this. Componetize rather than inherit. (Some argue that inheritance is generally bad and using components is often the better solution). In this case, I would agree. Every Entity contains pointers to Components.

A Component is some logical clumping of data. Generally, you determine what constitutes a Component by looking at how it is processed. For example, properties relating to an object’s physical properties would be in a PhysicsComponent. Properties for game logic would lie in the “GameComponent”. There is a fuzzy line here that makes this a bit tricky. To help alleviate this problem, Components can have a back pointer to its parent Entity. This way, if data from another Component is needed, it can be accessed via its parent.

Not every Entity has every type of Component. For example, a tree probably plays no part in the game logic, but will participate in the physics engine. Having components lets us separate the data needed in different processing stages in a coherent manner.

Inheritance with components seems reasonable to me, though I’m not sure how well it will work out for other people.

Engines

This brings us to the next class of structure: Engine. An Engine should encapsulate the processing systems. They will store pointers to corresponding Components of entities. For example, the PhysicsEngine should keep track of all the PhysicsComponents.

This is not to say that only the PhysicsEngine can access this data. For example, the RenderingEngine may want to know the location of an object to draw it. It does not make sense to duplicate the state already in the PhysicsComponent so instead, it will just follow the parent pointer to access this information

rc->parent()->physics()->location();

In an ideal world, cross-component accesses like this one would be held to a minimal but I think we encountered this issue quite a lot.

Events

I would like to make Engines const with respect to game state. That is, Engines merely process but do not affect any change to the data. Instead, Engines return Events. An EventProcessor takes all of the Events and decides what changes to the game state to make. One big plus would be that all the Engine processing could be trivially parallelized and only the Events need to be done in serial. While concurrency is most likely not needed for cs248 projects, it’s still a nice, clean way to design code. Also, you always want to think ahead!

The downside is performance. Generating tons of Event objects and processing them is a bit expensive. A sophisticated EventProcessor could help coalesce duplicate Events to alleviate this problem, but it is more or less unavoidable.

Optimization: PhysicsEngine

One major problem with this is that you will get a lot of events from the physics engine just to resolve collision response. Handling these reactions directly in the PhysicsEngine will stop all these events from getting queued. I’m not sure if this is entirely necessary. It may be reasonable to actually generate events that take you from one physics state to the next but I’d imagine events from the character colliding with the ground to be overwhelming.