Summary of the latest component stuff published at 360idev yesterday...
We use a pretty lightweight component architecture for our iOS projects. It looks exactly like the structure above.
- Game World -- container for game objects; entry point for broadcast messaging, update loops, cleanup messaging and object removal
- Game Object -- container for components (or behaviours as we actually call them in code); parse for loading objects from templates; proxy for messages, loops and cleanup
- Component -- a specific piece of encapsulated game logic or functionality
The component is the critical thing -- this is where you put your stuff. Game objects are a composition of components. I'm not going to try and explain that here -- I suggest you check out the links below, or wait until John gets the session recording up from 360idev in which I talk about this quite a bit.
- Original outline post written here: 36peas component architecture
- Refactoring Game Entities with Components
- Property and evented style components
- Theory and Practice of Game Object Component Architecture (PPT)
- A Data-Driven Game Object System (PDF)
- Game Programming Gems 5 (2008) -- Bjarne Rene -- Component Based Object Management
- Not quite component-architecture specific, but this post re static blackboards on AIGameDev is useful if you choose to implement data storage in that way.
It's critical not to get hung up on trying to implement or decide upon a perfect architecture. There isn't one.
- Object-orientation isn't bad -- but composition is very different, so they end up competing
- Though most composite systems utilise OO structure and design in their implementation
- Messaging and data storage/access need to have solid design (there are several options -- see links above) before you start coding
In implementation that we use, a component (behaviour):
- Gets used more-or-less generically
- Receives messages and acts on them
- Sends messages to it’s game object or the game world
- Reads and writes data from the game object’s store
- Handles messages on the update loop (and draw loop potentially)
- The components contained in an object represent the only formal definition of that object -- don't add or remove components to an object after its initialization
- You need to be watching performance -- certain tasks (like key lookups on a shared store) can be expensive if done frequently (design around these or embed other systems within your component architecture)
360idev Game Jam example and code
The Game Jam's theme was "opposite" and the entry I put together was titled "Fungal Adventure." Summary of the game is pretty much:
- 2-player local iPad game (vs -- with players on opposite sides of the device)
- Move your dude left and right
- Objective is to get to top of screen to win, or to force other player to die
- Eating a mushroom makes you go faster for a little while
- All mushrooms have some effect on you -- which must be countered by that mushroom's counterpart (edible<>toxic; psycho<>medicinal).
- If you don't eat the right counterpart you die (and lose)
- Eating any mushroom also swaps all other mushrooms of that pair (i.e. all edible become toxic etc)
It looks like this:
Aside from the obvious game wrapper stuff (menus, scores, tallies etc) I'll be following this up with some additional features and changes before releasing it, including:
- Swap out one set of mushrooms for something else to make it a bit clearer how the pairs work
- Add an AI for single player use
- Add some other obstacles and game-state-changing elements
If you'd like to take a look at the code itself (which I know at least a few of you do judging by the numerous requests and feedback I got after the session), you can download it below.
However, please read the following disclaimer:
- It was written in a 12-hour game jam on zero sleep
Which means that:
- It's incredibly sloppy
- There's very little memory management
- There are huge performance problems if you replay the game a few times
- Sometimes you can't win
- Occasionally mushrooms spawn on top of a player and end the game immediately for no apparent cause
However, on the upside:
- It's an excellent demonstration of what you can do with components in a short space of time
- The component architecture itself (the DW* classes) are not sloppy -- I've re-used them
- The game code itself is so incredibly shoddy you can see that it's not important how to build a component system, just that you do so in the first place
Download it here -- Fungal Adventure (36peas 360idev 2011 Game Jam project).
Notes on use:
- Do what you like with the code
- Name and all artwork are copyright 36peas
- I've had to remove the background music as I'd borrowed it from another project
Enjoy -- give me a shout if you've any questions on the above, would like to see the same material at a different conference or just want to chat. You can get me on twitter @36peas or by email firstname.lastname@example.org.