It's go time: project updates and some teaser art for Dead West

Dead West went into full production last week -- it's been a while getting to start on this one, but fortunately we're way ahead on the art production side. First demos will be around the time of (and at) GDC early March. In the meantime an update on other stuff and some of our latest characters and level background style updates...

Another Hyperion update was submitted last night -- it features an in-game tutorial and tips system. Great for both new and experienced players. Watch for that hitting the App Store -- we're dropping the price at the same time. And by dropping the price, we mean making it free.

As usual we're involved in a couple of long-term and couple of shorter-term consultancy and service projects. This year we're being somewhat more discriminating about what we accept though -- if you need help give us a shout at help@36peas.com. We generally always have capacity for iOS games projects and normally (depending on other commitments) some back-end multiplayer and infrastructure stuff as well.

iPad Game Design -- slides from Develop Liverpool December 2011

I presented this at Develop Liverpool yesterday -- similar to what I did at 360idev Devner back in September.

Note: SlideShare seems to have had some kind of fit with the title slides. I really don't repeat myself that much ;)

A lot of the salient parts were made by me vocally. As far as I'm aware there wasn't a recording -- and I don't have notes, but you should get the general idea from the slides above.

There's also a great write-up by Keith Andrew over at PG.BIZ.

Free to Play*: what's all the fuss about? (Venn included)

Abstract, summary and conclusion all in one Venn for the impatient:

And, actually, I'm kind of impatient too. So here's some some shortform notes on what I was thinking about when the above popped into my head.

• We named it wrong -- it's not "free" at all. It's just another way of try before you buy
• This is not a post about shitty energy system time management games interactive experiences
• * I would write Free 2 Play... but I was reliably informed at GDC Online that the term is trademarked by K2 Network -- in a talk, by them, about the wonders of this "new" model 

We've a bunch of other terms to describe this stuff:

• Freemium: apparently it's different, though I hear it used interchangeably with free to play
• Freeware: stuff that is actually free
• Shareware: stuff that is feature or content limited until the user hands over some cash

Wait a minute, that definition of shareware sounds kind of familiar... in fact, isn't that a better description of what we're trying to describe here? Instead of copying floppy disks and installing from free CD-ROMs, we're pushing this stuff out digitally... but we're still targeting the maximum possible audience with the free stuff in order that the ones who really like it want to pay more to play more -- and can? Right?

Okay, "shareware" isn't a great name either... but it at least is a little more accurate. And it doesn't sound quite so manipulative. Have you thought about other words with "free" in them. There are more poor examples than great ones.

Anyway, back to that diagram. It's pretty self explanatory. This is nothing new... we're just finding new ways of getting the reach we need in order for people to reimburse us as and when they want to. In fact, it's a little better -- the green circle being inside the red circle means everyone paying us money has already played our game... the chances of them being satisfied with their purchase are much higher.

AS A COMPLETELY SEPARATE ISSUE, we have to remember that in parallel there's a bunch of other crap being pedalled under the "game" moniker -- if we continue to make high quality games and at the same time experiment with these new delivery and commercial mechanics, the distinctions will become clearer.

Blackboard storage for your game's component architecture

When I was preparing resources for the talk I did on component architectures for game development at 360idev in Denver earlier this month I came across a post on blackboard data storage over at the excellent AIGameDev.

In this post I've outlined a couple of ways this kind of data storage can be used alongside component-based stores for global state and shared data.

 

Background and context to date

To date we'd been sharing global data using one of the following methods:

1. The GameWorld's local store (a dictionary)
2. Properties on the GameWorld object itself
3. In-component referencing / lookups

These have all got problems -- the first requires proper management of lookups, is slow for common lookups (each lookup is a key search) and is clunky for access outside of the game world (i.e. by controller interfaces; the second requires modification of the GameWorld class -- this feels very wrong and makes the GameWorld code completely unportable, and; the third leads down the road of interdependency and presents similar problems to traditional OO hierarchies (inflexibility, obfuscation and bottlenecks).

No perfect solution

A component-oriented design really should be as component centric as possible, but there are cases where there is no clear "component" solutions, for example:

• GameWorld <> Application <> OS communication
• Controller interfaces and attachment
• Game state
• Caching

The blackboard architecture helps with all of the above cases.

It also helps with more debatable components -- things like map managers -- where there's a strong case for externalising the functionality of a component but also a desire to have belong in the game world (especially for the purposes of messaging, updates etc). Other components can acccess said map managers directly as if they were singletons or external systems, but they can also participate in the gameworld's messaging system or update loops as required.

How to implement a component-friendly blackboard data store

We're simply creating a blackboard class and hosting an instance of it on the GameWorld object itself. This means that:

• Specific data stores are exposed through properties
• As a result data access is type safe
• The blackboard can house it's own LoadData function to populate from persistant storage if required
• The blackboard class itself is project-specific but it's hosting in the GameWorld is generic (keeping your game world, objects and components generic utilities)
• Access is direct for all components (e.g. component -> object -> world -> blackboard)

Smarter game components and behaviours

Abstracting away shared storage has a couple of other benefits at the component level as well.

A great example of this is, in the iOS/Cocos2d space, sharing sprite batches between instances of the same component. Our simple BCharSprite is instanced in a number a different types of game objects and hence is difficult to build factory and shared methods for -- it's a true component in it's isolated behaviour. However, we want to be able to re-use sprite batches when the sprite sheets themselves have already been loaded by another component. This is accomplished very easily using a blackboard using a single NSMutableDictionary accessed as follows:

 

Should I use a blackboard for storing data in my game's component architecture?

As with anything component-oriented (and really any software design) this does require some forethought and consideration -- you need to understand why you are implementing this kind of storage, how your comopnents are independent and (as they inevitably will be in some way) interdependent.

There is no perfect solution, but there are lots of great ones. This seems to be working for us so far.

More information:

• object composition and lightweight game component architectures
• our original game component architecture design
• blackboard data storage

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

Want to take a look at a component architecture in practice? Attend my talk at 360idev yesterday and want the code I promised? Have no idea what object composition is? Awesome -- this is just for you then.

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.