Lightweight component architectures and object composition -- including some "sample" code

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.

Remember:

• 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)

Additionally:

• 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 gareth@36peas.com.

--

Updated 21/09/11: Not quite component-architecture specific, but this post re static blackboardson AIGameDev is useful if you choose to implement data storage in that way.

Component Architecture links

Primarily for a talk give at 360idev -- link goodies on component architectures:

Piegons: Rock Pigeon

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)

Updated 21/09/11: 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.

A 360idev Game Jam post mortem… some useful things we learnt that you can apply elsewhere

In the last 24 hours we’ve been participating in the 360idev Game Jam along with a whole bunch of other developers in Austin and around the world. We’ve come out of it with a game prototype that’s solid and a bunch more enthusiasm for the original idea and getting it finished than we had before we started.

We did the bulk of the work from the UK, with @deltamikealpha on the ground in Texas keeping an eye out for the mammoth pizza delivery and proving much needed QA and general technical gubbins.

So, what did we do?

Directly following our game mechanics #idevblogaday post last week, we developed the Status & Ownership mechanics into a hex-based iPad-only game of domination and leveling (okay, the leveling’s not implemented yet – but we’ve got a good feel for how it’ll work). The project’s been titled gjat, Gobble and now Shingles. Yes, we’re going to come up with a better title. I won’t go into the detail of the gameplay right now – mainly as we’ll be finishing it up as soon as we can and getting it out there for you all to play.

What I thought might useful to both us and you is a recap, post-mortem style of what we’ve experienced and learnt.

"Feel" is important, specific game art not so much

We spent a lot of time (probably the first 3 hours) discussing and trying art ideas. It turned out that the art itself didn’t matter so much, but the “feel” of the game was crucial. The brainstorming we did about vector and painted styles, actual and abstract representations and dynamic art-based environments led directly to how we felt the game should play. It didn’t, however, get us to a final art-style. The in-game art we’re using now probably took about 2 hours in all and will likely take us another 20 or more to get to v1 release, but it carries the spirit and desired feel sufficiently for us to assess the “fun” of the game.

Mercurial, bitbucket, Google Docs, Skype and Dropbox FTW

This is kind of an obvious one, but our toolset is important. Yes, we needed XCode and Photoshop – but it wasn't them that held the thing together. It’s setting up and pushing a source repository in 4 lines, collaborating line-by-line on specs and bugs and seeing each other’s faces (this really helps at 4am) that got us through. Yes, the WiFi at the venue could’ve been better but it just about did the job.  As we all work from our homes and various offices anyway we’re used to this, but intensifying the requirement to collaborate through the 12-hour deadline forced us to use what does the job. Happily, this turned out to be what we use day-in day-out (yay for our normal efficiency and effectiveness).

Having a comprehensive framework is facilitative

Prior to the start of the Game Jam we spent a little a time isolating the component architecture we’ve put together for the other titles we’re currently working on and setting up an empty iPad+cocos2d+said architecture project. Whilst this took time it facilitated features that we just wouldn’t have been able to do in the time otherwise (including: duplicating AI players; having UI indicators for player/piece state, and; implementing a reasonable sound effects system in about 14 seconds).

We should’ve implemented a controller/player interface

This is pretty specific – but important, and something I may write a follow-up on if useful?

It was clear going into the first lines of controller code that the “correct” way of implementing both human and AI players was via a controller interface. But, we were still pinning down the hex map tools and it made sense at the time to consolidate human player control validation with consequential actions. When we came to the AI, a good chunk of this ended up be mirrored (not quite replicated, but not far off) because we didn’t have the interface layer. Suffice to say some of the bugs we were ironing out right at the end were solely due to the rule set being manifested in two separate place. Writing the proper interface layer is now a must before we embellish the core gameplay features.

Sometimes there just isn't a shortcut

I spent a good amount of time trying to sort out performance issues (performance issues that were making the prototype close to unusable) that were due to hacky AI loop. After an hour or two of plugging holes I ripped it all out and started again. I should’ve known better (although I had overestimated how long it would take to hook together the behaviors and components that now make up the AI loop). Performance went from being a massive problem to completely irrelevant – and actually gave us scope to do something we hadn’t anticipated in the prototype: multiple concurrent AI players.

Resources don’t need to be utilized 100% for them to be required

There were three of us working on the project: me, Gareth (@36peas), project lead and sole coder; Goose, artist (@goosemouse), and; Dave (@deltamikealpha), QA, asset management and general technical resource. Thing was, the bulk of the work ended up being in coding, and neither Dave or Goose were required for the full duration of the event. Initially I felt a little uncomfortable about this but on reflection I wouldn’t have had it another way – whilst I didn’t need them the whole time, the support they provided was invaluable.

--

Right, time for some sleep – we’ll get back to you just as soon as we have a real title, if not before. Hope this was useful, hope those of you who participated had fun too – looking forward to seeing more of the Game Jam projects over the coming days and weeks.

7 simple but proven game mechanics to prepare you for the 360idev Game Jam

A week from now, we'll have just finished the 360idev 12-hour Game Jam, and I'll no doubt be writing about the results right here.

In anticipation, I thought I'd put some thought into simple base game mechanics and mechanisms that could be easily built upon in a tight time frame to meet the objective of presenting a working prototype of a game in a yet-to-be-decided theme.

This will be the first time we've participated in the event, and we're honoured to also be sponsoring it along with a bunch of awesome iOS developers - see links to each at the end of the post.

A few months ago, TechCrunch published SCVNGR's game mechnics playdeck. While there's a good amount of duplication and a lot of reasonably obvious stuff, it seemed like an excellent starting point. So, the 7 mechnics below (and their definitions and examples) are taken striaght from the original 47 in TechCrunch's article. I've added some Game Jam-specific uses.

1. Achievement

Definition: A virtual or physical representation of having accomplished something. These are often viewed as rewards in and of themselves.

Example: a badge, a level, a reward, points, really anything defined as a reward can be a reward.

Potential Game Jam use: Implement nothing but the achievement system. Have a series of achievements with associated names, scores or artwork that are awarded for completing an otherwise mundane task. A ramdomly generated field of coloured shapes, for example, could require the player to repeatedly pick shapes of the same colour - sucessfully getting a certain number of a certain colour would award an achievement. Achievements themselves could be linked back in to the game itself (i.e. the unlocked items become playing pieces in the game itself).

2. Avoidance

Definition: The act of inducing player behavior not by giving a reward, but by not instituting a punishment. Produces consistent level of activity, timed around the schedule.

Example: Press a lever every 30 seconds to not get shocked.

Potential Game Jam use: give the player a fixed amount "health" or score and have them complete tasks to avoid being punished. Sucess in the game could be measured by the period of time the player manages to survive.

3. Behavioral momentum

Definition: The tendency of players to keep doing what they have been doing.

Example: From Jesse Schell’s awesome Dice talk: “I have spent ten hours playing Farmville. I am a smart person and wouldn’t spend 10 hours on something unless it was useful. Therefore this must be useful, so I can keep doing it.”

Potential Game Jam use: endless building games seem to be the obvious striaght-forward implementation. A tongue-in-cheek implementation of a Farmville-like mechanic would likely work well. An endlessly expanding cabbage patch springs to mind for some reason.

4. Countdown

Definition: The dynamic in which players are only given a certain amount of time to do something. This will create an activity graph that causes increased initial activity increasing frenetically until time runs out, which is a forced extinction.

Example: Bejeweled Blitz with 30 seconds to get as many points as you can. Bonus rounds. Timed levels.

Potential Game Jam use: repeat the same basic play over and over, each time with a reduced amount of time available to peform the core actions. Tapping critters is an easy one - the intesity of the experience is held by a careful, balenced reduction in time available to get each critter.

5. Ownership

Definition: The act of controlling something, having it be *your* property.

Example: Ownership is interesting on a number of levels, from taking over places, to controlling a slot, to simply owning popularity by having a digital representation of many friends.

Potential Game Jam use: local multiplayer (thinking iPad-specific here) split-screen action that somehow involves removing "pieces" from the opponents stash. Obviously there has to be complexity in retaining one's stash whilst also diminishing that of your opponent.

6. Status

Definition: The rank or level of a player. Players are often motivated by trying to reach a higher level or status.

Example: white paladin level 20 in WOW.

Potential Game Jam use: a simple domination-of-like-and-lower-level characters with an experience and levelling mechanic and some random generation of enemies at appropriate levels.

7. Appointment Dynamic

Definition: A dynamic in which to succeed, one must return at a predefined time to take some action. Appointment dynamics are often deeply related to interval based reward schedules or avoidance dynamics.

Example: Cafe World and Farmville where if you return at a set time to do something you get something good, and if you don’t something bad happens.

Potential Game Jam use: things that require attention in the very traditional Cafe World/Farmville cast - can be applied to any context or theme, just figure out something a: great and b: unfortunate/funny/bad to happen when the play meets or misses the timers. Very similar (in fact really an extrapolation of the Countdown mechanic).

--

Just in writing this up I've a few generically-themed ideas that we could easily build on top of the component architecture we've using for the titles we currently have in development.  Looking forward to next week.

As I mentioned above, we're one of a group of indie devs (links below) who've gotten together to sponser the Game Jam - it's open to all (whether at the conference or not). Hope to see you there.