I'll be giving early demos of Dead West to those who are interested as well -- we're looking at distributing alpha-like demos the week after GDC so what I'll be showing is the very last stages of getting to that point. Given we only got round to the writing code for this thing in the last 5 weeks, we're doing pretty well :)

Give me a shout by email gareth@36peas.com, or twitter @36peas.

In related news, we just put up a Dead West holding page and news sign up thingy. Go sign up for news and updates about Dead West.

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.

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.

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

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.

Last week we set about putting some parameters around the remaining design work for the core feature set of Dead West. We’re not trying to pre-emt derived and iterated gameplay stuff -- just get a basic framework to aim for.

One of the biggest remaining decisions is whether we're targeting aracde-style replay or campaign-like progression through the various maps and levels. We've a lot of flexibility in how we spawn, introduce and balence enemies -- so we can take a basic "x enemies == y time" sense of anything.

In order to produce for ourselves both a chicken and an egg, we decided to firewall some assumptions against the level designs we currently have. After a good amount of pondering on how we do that, we:

1. Took a straight line (quickest) path through each level*
2. Calculated a walking traversal distance for that path (based on what looks right in our current codebase)
3. Inserted a number of enemy encounters that we felt looked right based on the aesthetics and feel of each map
4. Timed those encounters (based on a completely different game)

* this sometimes meant picking arbritary start and end markers

The point of doing this was to answer the question "if we just give the player a simple A-B experience in each level, how long would it take them to complete the set of designs we have"... hopefully leading us towards a design on arcade or campaign/completion play.

Some detail on the techniques we used:

• Stopwatch was invaluable for working out a pixels-per-second walking speed for our standard heroes.
• "Mean time between interesting shit" was calculated/measured in Fable 3's gameworld
• Reasonable encouter sizes and hits-to-kill enemies was estimated based on Battleheart
• Relative encouter sizes and likely time differences were based on Warhammer Fantasy unit balance calculations

We got to a level completion time of between 25 and 40 minutes... and an answer on what kind of map progression and session play style we're targetting. We'll go into more detail on that in the future -- but suffice to say it's nice having the flexibility.

By far the most difficult bit was simplifying the problem set -- we spent a long time stopping ourselves from talking about enemy encounters and the complexities therein. We ultimately boiled them down to "Small", "Medium" and "Large" encounters, safe in the knowlege that if GW can genericse everything to a points value we will be able to as well.

Other pleasant side effects of the whole thing included a prototype for how we can offer variable play based on player preference and player experience -- and a good number of ideas for where we go next in regard to spawning and triggering of enemies (all of which seem simpler than we'd anticipated).

In it we cover wrangling perspective and the use of 3D-like environments for our upcoming 2d, action-strategy iPad game, Dead West. See below for a further breakdown of contents.

We also start to talk about some of the level design itself -- and how that impacts on the art and art design.

All the artwork featured was produced in PhotoShop, and the video's full of hint-shaped nuggets for producing exactly this kind of art in PhotoShop.

The video also features early previews of some of the original score from Dead West.

Game Dev in Motion?

What do you think of the format? Let us know in the comments -- we're thinking about doing more.

We’d written a little about Brotherhood in a post last week, but on getting into the detail discovered that there’s something very interesting going on in the multi-player experience. The game carves out a multiplayer mode based not on the conventions and received wisdom of its contemporaries (those being other AAA titles) but based on a gameplay experience that has been evolved and perfected over the series*.

As a result of this, the gameplay experience delivered by Brotherhood’s multiplayer mode is nerve-wracking, tense and thrilling. And it’s all of those things because of the clever way other human players are introduced into the game world established by the single-player Assassin’s Creed experience.

If you’ve not played it, the best introduction is probably seeing it in action:

Some from-the-horse’s-mouth (well, actually a Goose in this case) observations:

Ignoring the ridiculous wait times (I timed 19 minutes on one occasion) to get into the game, the level of tension generated in the Brotherhood multiplayer experience is second to none. To be successful in a match you must act swiftly to score as you are competing to finish top of the leader board. This works contrary to you having to behave in a calm manner so as to avoid detection by the player you are hunting. This juxtaposition is heightened by the fact you are sometimes being stalked by many opponents - and other players may also be tracking your target, increasing the necessity to locate and dispatch your prey quickly and quietly. On a number of occasions I’ve witnessed a player break cover and assassinate his target only to be brutally stabbed in the face a split second later.

The chaos that ensues when a player acts inappropriately can at times be both frightening and hilarious: you may find yourself calmly walking amongst a crowd approaching your prey - lining yourself up for the perfect kill - and then, for no apparent reason, the calm is shattered as someone nearby starts to run. At this point it becomes a true test of nerves. There are many reasons the character may be running: they could be under chase; they may be after your kill; they may be coming to kill you, or; it may just be the AI fucking with you and there’s nothing wrong. Either way, at this point, nine times out of ten the majority of players in the area panic and scatter, some will die, others will escape but your perfectly lined up kill has gone and you must steady your nerve and begin again. The level of concentration this demands is so much more than in most multi-player experiences and the depth of emotional involvement it demands is truly mind bending. Never before have I played a multi-player game that has the player so engaged that the emotive drive actually parallels the events occurring on screen. Whilst from a tactical point of view it may help to have a soldier-like mind set while playing the latest Call of Duty, at no point do you actually feel like you are a soldier or part of a unit. The level of distrust and suspicion of everything in your environment goes a long way to making you feel like an assassin in Brotherhood.

As mentioned before the overall mood of the game is generated by its conflicting pace, this however does open it up to criticism as at times the second greatest frustration raises it’s head, on a number of occasions I have found myself with no target for various reasons and at points the time it takes for the player to be assigned a new target can be quite lengthy. When playing a game when the suspension of disbelief is anchored around its pacing this problem is quite a large one if for no other reason that you can’t ecru points and maintain your position on the leader board if you have no targets to kill... especially if other players are racking up kills during this down time.

There are a number of  issues in the game play’s architecture and design though – primarily that the issuing of targets isn’t consistent (i.e. it can take you a lot longer to be allocated a new target than your competition). At these points the attitude towards the game can be adversely affected. In some instances the focus can easily switch from the cloak-and-dagger approach intended and generally desirable to a “shit... I really need to get a quick few kills to regain my place on the leader-board”-type attitude. This negative change in attitude often sends a ripple through the other players’ behavior. If for whatever reason players start dashing around to grab quick kills, the atmosphere of stalking-while-being-stalked quickly dissipates and the mood becomes more brawl than a battle of wits and holding of nerve.  On the whole though these situations are rare and the game really draws the player into a unique and innovative style of game play that – no insignificant feat considering the vast array of design variables involved multi-player game play.

What next?

Playing a Call of Duty or Halo game in a multiplayer mode does provide a challenging and changing experience because of the nature (and varied skill sets) of human player opponents – and how they behave differently from AI opponents. Brotherhood relies on this differentiated behavior (of human-played characters over AI characters) in order to drive it’s game play. It’s like a sequence of inverted Turing tests – convince the human that you’re a computer.

The recent popularity of bot modes in AAA titles (e.g. Firefight in Halo: Reach) already highlights that players are interested in multi-player experiences that do rely on there not being human players as opponents (it wouldn’t be possible to organize and coral so many human players into a horde-like attack of the opposing team). But, whilst interesting – and a lot of fun, it’s no co-incidence that the heavily-human-player-behavior reliant experience of Brotherhood is also an emotive one. What else can we do to drive such emotive responses?

* I’ve not played it myself yet, but according to all accounts a lot of what’s good about the behavior-based tensions and skill in Brotherhood is also born out in Chris Hecker’s upcoming SpyParty.

I’m sick of hearing iOS devs complain about Apple, about Apple’s policies and about Apple’s terrible treatment of developers.

It’s their platform. They created a market. If you don’t like it, fuck off.

I wrote started to write a full post about this earlier, and planned to bring together my thoughts coherently. I had references on market laterals from the HBR and everything. But I can’t be bothered. I am very much looking forward to getting this off of my chest as quickly as possible and getting back to what’s important: testing earth-tone base colors for the delivery of Citadel goodies I’m expecting tomorrow.

In virtually un-edited form, here are some of the notes I started to make earlier: 

• Apple created a market. Duh.
• It is, was and probably always will be their platform
• Apple are known for lock-in to their stuff
• Apple are known for not sharing things until the last minute
• Re devs not having access until launch, some people seem to have managed just fine in getting stuff ready.
• Just because you’re developing for the App Store, doesn’t mean that you represent the average, typical or most likely example. “Camera+ from Tap Tap Tap sold 78,000 copies on Christmas day, but no one else I know sees numbers like that” << of what relevance is that?
• People like to moan… so most of what you read on the web (yes, including this) is people moaning. Those who are doing well have got better things to do.
• Apple most probably think about what they do and how it affects developers – they know what they’re doing.  Maybe their considered opinion is that it works best this way.
• Apple tend to stand by the information they do publish – they told us the Mac App Store would be 90 days, and it was 90 days.
• “Apple's secrecy cripples their ability to have a positive relationship with developers.” So what? Their App Store continues to lead the space.
• iTunes (the music store) is notoriously lacking in features for both users and creators / publishers… yet it is still head-and-shoulders above the competition (it also created a market). 

One particular game is relevant to this post: Reckless Racing.

A couple of times in 2010 we spent some development time on a top-down, drift physics racer. Originally titled Retro Racer, then later some part of our Unga Bunga project and most recently Dwarf Dash.

The time we spent on each form of the project was useful – in its first instance it was a case of getting a prototype working, with physics written from scratch. It took about 3 days and was fun and effective-for-a-prototype playable.

In its second form, we did little (no) work on the game code itself, but a lot on the design and concept – this ended up forming the grounding of a completely unrelated god/sim game: Unga Bunga.

In its third, most recent and final form (as final as it’ll get) it was titled Dwarf Dash (which we started as part of the Ludum Dare Challenge). This involved a re-think of the concept, related art and general game design issues, as well as a re-implementation of the original prototype in our new component architecture. What we learnt here from a technical point of view was invaluable and fed directly into how we used that architecture in the two titles we now have in active development.

Where does EA come in?

As it turns out (and we could’ve figured this out in advance, but didn’t) there’s not a huge amount of original design, iterative design change or innovative implementation involved in something that is quite squarely another crack at a well established genre and game type.

We were doing this because I very much enjoy top-down drift physics racers. And this is where there’s an important (and not often explored) message:

Creating games that you (the indie dev) want to play isn’t enough.

As indie developers with no external constraints, we should be be mindful of the required development and design implementation: we should be working on things that are interesting and exciting to develop as well as play. This is how we bring real value.

Producing video games is a vast and varied undertaking. I’m insisting that we select titles based on their innovative design value, as well as their desirability as a game player. Let’s leave the implementation of well-trodden game types to EA (and those like them) and enjoy the fruits of their constraints. Reckless Racing, aside from minor criticisms of the AI and a few other bits, is a pretty damn good implementation of a top-down drift physics racer for iOS.

To conclude

Thank you EA for sating my need to drift rigid bodies around finely-tuned curves. And thank you EA for getting me to this point and letting me get on with innovating and creating.

The day’s events prompted a number a thoughts for game development ideas, most of which are quite well suited to iOS. Instead of staying up several hours longer than I’d like and writing up one of the general game design posts we’ve been working on, or finishing the 2010 gaming retrospective we’ll likely post next week, I thought I’d spend a smaller amount of time expanding on the ideas below.

Balance: removing the normal visual cues

Park a truck on slope sideways, with an exit on to a level path. Then get inside said truck and bend to pick something up – all of a sudden you realize that a lot of what you rely for balance and stability has gone and it’s actually quite disconcerting.

Taking this idea, it’s pretty easy to extend it to an accelerometer-based game that involved some abstracted form of “balance” in the game world. Progress the game by making the player dependent upon visual cues and then – bit by bit – removing them.

Logistics: right resource, right place

Take 4 people, 4 vehicles, 2 primary locations and several secondary locations and then try getting things in the right place at the right time. When the respective skills and properties of those people, vehicles and locations are varied (and in some cases absolute) things get mighty tricky.

This is an idea needing a context / world design – but anyone who’s ever considered game design has plenty of those. Apply one to the other for puzzling or real-time management fun.

Environment cycle: the massive effects of night and day

Doing things in the dark has its problems, doing them in the dark when the temperature drops another ten degrees below zero between day and night is another thing entirely. The knock-on consequences of several cycles are interesting too – a snowy hill is drivable one day, but unusable the next because it that snow was compacted and is now sheet ice.

Degrading performance: hampering expected ability causes frequent re-planning

Locomotive movement, respiratory function and agility are generally predictable for any human being. But when the environment they’re operating in affects those things significantly they’re forced to frequently re-assess their ability and re-plan their actions.

The obvious game mechanic here is in gradually degrading the abilities of the player, forcing them to perform faultlessly or otherwise find alternative methods.

Displacement and misplacement: confusion and exploration

When you’re familiar with how your objects are connected to your environment (physically and functionally) it becomes very difficult to answer normally-trivial internal queries (where is this, what do I need to do that).

This is likely best applied as a specific element of a wider game – one in which the player becomes familiar with their tools and their abstracted connection to the game world. Changing that environment around them (i.e. not giving them a new environment, but one that provides the same function in a one-home-for-another like way) presents them with challenges they wouldn’t have expected and likely aren’t well prepared for.

Space is premium: confinement drives perfection

The main criteria for selecting our new home were all about space – specifically the size and space within each room. Already (and we’ve not fully lived here yet) we can see the massive (beneficial) change there is in doing very simple things – like moving in and out of rooms.

Have a player perfect something, then make them do it again with less “space” – two examples spring to mind here: PacMan and the usefulness of many entry/exit tunnels and what happens if you take them away, and; Osmos and the affects of a more confined (or densely packed) play area.