The full post is here: 14 things I did to get from Ludum Dare prototype to fundable Kickstarter game

It includes such highlights as building alphas for one, iterating on design, essential UI and listening to and ignoring feedback.

I also posted it over at the Ludum Dare site -- you can find it there/here. Thoroughly excited about #LD26 this weekend.

As for Mineral Cities itself, well the campaign ends in a couple of days -- go back it now if you haven't already ;)

From the GDC Schedule page:

A one-day crash course in making iOS games. This daylong bootcamp will include enough specific technical and platform knowledge for attendees to either go away and start making their own iOS games, or to further understand the tools they are using. The day will be made up of a mix of discussion, deep dives, examples, and plenty of opportunities for audience Q&A. Session content will include an introduction to the iOS platform, crash courses in Cocos2d and Unity3d, popular/essential iOS APIs for games, and a deep-dive on game architecture selection and best practices.

Look forward to seeing you there ;)

G.

From the presentation abstract:

This talk is a follow up to my 2011 360idev talk on component architectures for iOS games. It includes specific in-the-field post mortems and performance analysis from the implementation of a variety of component systems, implemented by myself and others (including other 360idev regulars).

The performance measurement elements are applicable to all architectures and the post mortem information is full of technical goodies about iOS implementation detail and nuance.

Recent stuff includes:

• A write-up of the Component Architectures talk I did at iOSDevUK 2012
• A game prototype write-up of The Satanic Games
• Some fiddling I did with display modes on the retina MacBook Pro

This blog/site will likely be more focussed around 36peas stuff and garethjenkins.com about whatever I feel like writing about. Probably a good bit of crossover on game dev stuff, so I'll continue to cross-link where appropriate.

G.

Crow by Sunside Inc

Hadn't heard much about this iOS title until last week. Great stuff.

A Few Feet of Snow by Martin Wallace

So want this deck-building card game. Out of stock in the UK at the moment unfortunately.

Sine Mora by Grasshopper Manufacture and Digital Reality

This XBLA side-scrolling shooter is so beautiful it might just keep my attention long enough to figure out how to play one of these things properly. 

Design

Permanent Record - The Paradox of Online Worlds

Outline of the issues around designing for permanency and user consequence.

Rational Design: The Core of Rayman Origins

Great write-up on the rational design principles that underpin the fantastic Rayman Origins. Also check out Ubiart's blog for more on the same. Unfortunately stale, but some goodies remain.

Code

The Top 6 Misconceptions I Had About Unity

Great post on Unity and some general usefulness about component architectures in general.

Algorithm is not a 4-letter word

Great presentation from last year. Just go watch it if you've not already.

Events

Ludum Dare 23 & warm-up weekend

Warm-up weekend is this weekend, 10th anniversary of the actual event is next weeked. Excited about this one. Also check out some of the give-aways and IRL meetups.

Indie buskers

Also this weeked. Go throw some change at them.

Games

Home by Benjamin Rivers

Hauntingly beautiful pixel horror adventure.

Dyad by Shawn McGrath

Didn't quite get to see this at GDC. Wish I had.

Lone Survivor by Jasper Byrne

More pixel horror -- this one's out already though. 

Offspring Fling by Kyle Pulver

Just in case your twitter stream didn't explode with this Friday night -- go check it out.

Design

Controls You Can Feel

Slides & notes from Zach Gage's outstanding GDC 2012 talk on touch tactility.

Mirror's Edge: Building the impossible

Interesting commentary from Rob Briscoe on some of the decisions that went into the art decisions on Mirror's Edge.

Code

Git tricks, tips and workflows

I don't care what you do, if you do it with code this is useful.

d3.js

Data-driven documents. Such a clever way to do DOM bindings and transformations. So many ideas sparked from this already.

Cubes all the way down

Renaud's slides from his GDC/IGS Fez technical analysis. Full of interesting technical and design points.

Commentary / analysis

iOS Sales Statistics including Q1 2012: Split by Model and OpenGL ES 2.0 Support

Great analysis from Steffen on the breakdown of GL ES 2.0 support on iOS devices.

Blow on The Witness & Braid

Informative and practical design interview with Jonathan Blow over on the PA Report.

Resources & tools

Pixel Joint

Massive community of pixel art & artists.

Lost Type

Ridiculously high-quality fonts on a name-your-price basis.

Spriter

Kick Starter-funded multi-part image animation for 2d characters. Free beta also available.

Frustro

Typeface design is cool. Deal with it.

Sources & inspiration

Disasterpeace

Wonderful game dev for your ears.

Cargo

Art profile sites, running on Cargo's backend -- full of interesting art and inspiration. The image browse page is a good place to start.

Spy vs Spy -- Omnibus Vol. 1

I don't seem to be able to detach myself from an endless stream of spy vs spy-like inspirations. Recent exposure to Gunpoint, Spy Party, Moncao and Beat Sneak Bandit aren't helping either.

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.

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.

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.

Hyperion is launching exclusively on iPad -- for those of you who've heard my iPad games design presentation at 360idev or iOSDevUK you'll know why. For those who haven't, I'd suggest you go get it and figure out why for youselves ;)

• to download from iTunes: Hyperion: d7
• for more info and useful discussion: Touch Arcade forum post
• news and further updates: www.hyperiond7.com
• news and updated by twitter: @hyperiond7
• on Facebook: hyperiond7.com/facebook
• on YouTube: 36peas YouTube channel

Additionally, you can get more development-related info on this and our other titles from:

• This site: www.36peas.com
• The RSS feed for the site: 36peas blog feed
• My twitter account: @36peas

Your support appreciated as always -- go buy it, review and join in on the discussion on Touch Arcade.

We've got a point release coming -- nothing major, but will be looking at tweaking some of the tutorial content and a few other minor additions.

Due to all the interest from 360idev attendees following the iPad game design talk (thanks for all the feedback), and the shitty hotel web connection, we're extending the offer price through to next Monday (the 19th) so you can all get it when you're on a real internet connection.

Anyone at 360idev who can't download it and wants to see or play it -- come give me a shout.

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.

I've included technical stuff (how to capture source video, how to get correct compression and import/export settings along the way etc) and direction/design stuff (how to pace the video, how to make it look good).

First off -- you better check out the Hyperion: d7 trailer itself:

This took us 4 hours -- including the time taken to capture the source video in the Simulator (not easy -- the iPad game itself really does need two fingers for effective gameplay) and the time taken to move video around between ScreenFlow and iMovie.

If you're not interested in the video how-to, but do want to know more about Hyperion: d7, skip to the bottom for more details.

What works -- what makes a good-looking video game trailer?

This process pretty much involved watching a lot of other trailers. Primary observations were:

• +/- 60 seconds seems to be an optimal length
• lingering gameplay shots don't work
• menus are dull
• teasing works better than describing
• tempo is critical
• everything hangs on the music

What we decided upon -- our video production rulebook

The details of specifically what we did are in the next section -- these are just the headline paramters for how we guided the process.

• Pacing should be consistent (all cuts the same length)
• We'd make the most out of the game's natural aesthetic (and concentrate on using clips that looked good -- not necessarily ones that we thought "played" good)
• Use the same effects/transitions in similar places
• Break up the action shots (doing so consistently -- again to aid pacing)
• Present some basic information about the game -- but don't worry about detail
• Do not re-invent the wheel

What we did -- step-by-step how-to for making our iPad game trailer

Technical pointers and specifics are in the next section -- skip ahead if you're not interested in the video production bits. If you are interested in the video production stuff, I'd encourage to read both -- there are useful (but non-specific) production pointers in the technical section.

1. Selected the background music we wanted to use -- we had an awesome original score to choose from. Two tracks stood out as obvious candidates.
2. Looked for appropriate 60-second-ish sections from the above tracks and selected one -- it was 63 seconds and had an appropriate open, close and riffy bits. From this point on everything was played back and tested against this music.
3. Decided on how many non-video (text stills) there would be -- we are using these as breaks in the action. We decided on two (plus the closing stills).
4. Picked our transitions (we did this by testing them against some sample captured video -- when using built-in fixed transitions they can look very different on different source material).
5. Decided where the transitions would be used (i.e. video>video; video>text).
6. Picked the text effects (same as the transitions -- try them out).
7. Worked out a good single cut length -- we did this by testing clips between two transitions over the top of the already selected background music. This got us to 4.5s per cut for video and 3s for text stills
8. We then broke down our 63-second timeline into the three sections demarked by text stills and populated the gaps with video cuts, getting us something like the following:
   
    
9. We wrote a list of bullets about the game but didn't dwell on the detail.
10. We wrote a list of things we thought might look interesting (not based on the list from the previous point).
11. We stated recording source video using ScreenFlow (more details below) and the iPad Simulator -- we weren't too worried about capturing the right stuff at this stage, we just follow the list from above.
12. Bringing that video into iMovie, we started to select and trim clips. For most clips we also applied either a single crop or a panning/zooming "Ken Burns" crop (see technical stuff below).
13. Added text from previous bullet list to correlate with what we'd captured (and to some extent what we wanted to say first / in what order).
14. We then repeated this whole process for the second section of clips -- we still weren't stuggling for what to record here (and this was with our tired-after-almost-2-straight-days-of-pre-submission-gameplay-testing eyes).
    
    At this point our source video window is starting to look like we have secret plans for a secret base in a secret spy world where nothing on the secret spy computer screens looks like what you'd see on a real computer screen:
    
    
15. Once we'd got sections 1 and 2 in order, we looked at the list of things we wanted to say and worked out what we'd not yet said -- giving us a requirements list for the last lot of captures.
16. We chose gameplay to match those points (this was the upgrades bit in section 3) -- and spent a little more time than we had on previous captures making sure we got what we wanted.
17. We created a closing title card (we should have done this sooner -- it's the only bit we weren't 100% happy with).
18. Added the final stills (the closing title card and the 36peas logo). At this point, the timeline looked suspiciously familiar:
    
    
19. Watched it end-to-end.
20. Made some text tweaks (nothing significant -- just some modifiers and joining/flow bits)
21. Exported and watched again. And again. And again.

Seriously -- that was the process we went through. We didn't have to go back on ourselves, or figure out why it didn't feel right -- it just did. This is entirely down to the consistent, snappy pacing. The video flows and feels interesting because the tempo is good and there's lots of pretty colours moving about. The details presented in the video aren't what make that so. If you happen to be interested in those as well, even better.

Technical stuff -- gotchas, hints and techniques for the iPad/iPhone Simulator, ScreenFlow and iMovie

In no particular order (but all particularly important in their own way): 

• Before you even start check that you can record from the Simulator. We had to do some code massage to get it to run in the Simulator (you never test in the Sim, right?) and we had to hone our using-a-mouse-like-an-iPad-screen skills.
• Get your (lack of) compression settings right -- and then check them every time you do something. The only place you want your video compressing is at the very last stage in the workflow (i.e. when YouTube compresses it). Key stuff:
  • ScreenFlow -- Preferences > Advanced > Screen Recording Compression > Lossless
  • iMovie -- Preferences > Video > Import HD video as: "Full - Original Size"
  • (on export) iMovie -- Share > Export Movie
• ScreenFlow only records one display -- do a few test recordings before you spend 10 minutes getting frustrated with the Simulator only to find you recorded the output of the wrong monitor.
• You need to crop the captured video from ScreenFlow after the recording. If your game starts with a black background (ours did) you want to start with something else open -- like Safari -- so that you can line up the the crop window with actual screen (and not overlap the black bezel of the Sim).
• ScreenFlow can capture all sorts of stuff -- make sure you only capture what you need (screen and computer audio)
• Disable the in-game music for your game (you likely want to keep SFX). This way you can have the game's soundtrack (or some other piece of music) play throughout your cuts but keep the in-game SFX if you want them.
• Edit the audio properties (for volume/gain) for each inserted clip independently. For some clips (in-game footage) you probably want to keep the SFX high, for others (menu taps) you'll want it low. Pick consistent changes throughout (we ended up with all "high" SFX at 50%, all low at 20% and a couple of fade outs).
• Be aware of how iMovie handles clip length -- transitions by default play over and consume part of the adjacent clips, so what starts off as a 4.5s clip ends up looking like 2.2s on the timeline with transitions surrounding it.
• Adjust crop and position for every clip -- for example, the iPad screen ratio is 4:3, not 16:9 (which you want to be exporting in most likely), so you'll need to crop and scan each clip.
• Work out how to use the "Ken Burns" crop in iMovie (click a clip, click crop, crop start then hit "Ken Burns", then select red end rectangle and move/crop accordingly) -- it allows you to pan and scan on the fly, set scale transitions and track action. We used these extensively to add or enhance motion.
• ScreenFlow lets you add mouse pointer types -- obviously the default arrow pointer makes no sense, but the optional "circle" pointer works pretty well for finger simulation (we dropped the size and opacity for a subtler effect).
• Pay attention to what you're actually recording -- especially if you're using in-development or imediately-post-production code. For example, we had to fudge the "global high score" and "global average" parts of our fancy skills analysis charts so it didn't look so sparse.
• When creating stills to be used in the video (like the closing shot of the Hyperion trailer), create them at the resolution at which you intend to export the video (for example we were targeting 720p, so we created them at 1280x720).

Concluding thoughts -- would we use different tools? FCP? FCP X? Premiere?

We're pretty pleased with the results -- there are a few bits we'd like to do slightly different given different tools (iMovie's UI sucks -- and it crashed my MBP twice in the process) -- and will certainly be sticking with this formula for future Hyperion (and likely other) videos, but we will look at other edit suites. The restrictions (fixed transitions and single video playback being the primary ones) actually helped us make quick what-can-we-do-with-what-we've-got decisions -- but with more varied source material and evolving requirements we might benfit from taking that self-imposed ruleset to a more sophisticated tool chain.

Er, so what's Hyperion: d7 then?

You'll be hearing a good bit about the Hyperion game itself in the coming days and weeks -- we literally just submitted v1 for approval and finished up on the trailer this morning. We're starting launch activities next week -- but we were eager to get this post out there to the #idevblogaday audience as soon as possible -- we'd have found this very useful 12 hours ago ;)

Should you find yourself needing to make further reference -- or just for the sake preparing for those hexes, here it is again, Hyperion: d7...

We’ve been discussing this recently in the context of a new project – you might also find our recent posts on the production/promotion balance and launch-marketing an iOS/iPad title useful.

1. Subscriptions – free to download, but pay for a subscription for so long as you want to play

2. Free trial versions – limited by features, limited by time, limited by expiry date

3. Sale of in-game objects or item for convenience sake (things that you could otherwise create, accumulate, find in-game but might not care to spend the time to do so)

League of Legends is free to play, but sells users a wide variety of playable champions, skins, boosts and other items

4. Selling ancillary stuff – e.g. ads, merchandising (and keeping the game free to play)

5. Pay for access to under-the-hood services (e.g. use of an API, access via 3^rd party services)

6. Hosting of private servers, lobbies for paying customers

7. Sale of cosmetic/aesthetic items or game objects

8. Subscriptions for different levels of access (e.g. free for a single character, paid for multiple characters)

9. Sponsorship of in-game items (advertising)

Burnout: Paradise serves up in-game advertisements as, well, advertisments

10. Pay for services, in-game tools that make it easier to manage/retain your character, world etc (pay not to play)

11. Mixed mode sale (e.g. one-off purchase of items, or fixed-rate subscription for unlimited use / access)

12. Upfront purchase – like how we used to do it

13. Pay for offline automation of persistent character (e.g. AI-like tactics, alerting services)

14. Highlighted/premium status in game-related sites or communities (e.g. forums, wikis etc)

15. Access to in-game, non-core services (e.g. whisper, party chat)

16. Pay for the services of other players (guides for hire)

17. Pay to fail – e.g. allow resurrection where it wouldn’t otherwise be possible

18. Sell in-game real estate

Second Life auctions off chunks of land directly as they’re made available (as well as letting users trade land)

19. Sell choice of spawn locations, other otherwise random new player variables

20. Sell vanity services – naming terrain, aesthetic improvements

21. Currency exchange – sell in-game currency for real-world Dollars/Bahts/whatever

Temple Run, the latest from @nattylux and @kshepherd, allows users to buy coins that can otherwise be accumulated through play

Gutenberg Neto (another #idevblogaday author) recently posted a great article on getting free-to-play right. That’s worth a look.

Honarary mention to Mike Berg (@weheartgames) who reminds us that “no connections, almost no marketing = very low sales. :)” – which pretty succinctly says exactly what I was going to in conclusion: it doesn’t matter how you monetize, if you don’t tell anyone everyone about what you’ve made you’re not going to get paid.

To clarify: we know how to market ourselves and our games, we just need to get on with doing it. In order to remind ourselves (and yourselves) of a couple of those basics (because this stuff is basic) we’ve brought them together in this semi-glorified bullet-point list. 

General promotion

• Ensure you can balance sustainability (cash flow, sanity); development effort; profile promotion and title promotion. Without each of these playing its part (you can merge the latter two if  it’s absolutely necessary and done incredibly carefully) you’re not going to see any significant forward progress – and in fact, you’ll likely fall apart or end up going backwards.
• Pay attention to everything. This is targeted primarily at other indies, but relevant to all, because: you should pay attention to what everyone is doing. AAA marketing budgets don’t come easily, but neither does the inventiveness and passion seen in the marketing and promotional efforts of indies.
• Talk to everybody. Network. Targeting individuals is fine, but talking to everybody is better – you don’t know where the pivotal conversations will happen until after they happen.
• Tell people about what you are doing. This is the most important thing. If no one knows what you’ve done, it doesn’t matter how great it is. Your blog, other people’ s blogs, Twitter, Facebook, Google+, forums, mailing lists, traditional media – anyone who’ll listen.
• Get involved. Enter your stuff into competitions. Participate in game jams. Not only do they bring exposure to your work, but they also help you refine your processes around specific points in time and force you to show what you do best: create stuff.

Operational stuff

• Plan what you plan to do. If nothing else it holds you to account and gives you some method by which to assess your progress. Make sure you set yourself lists of forward moving actions – and make sure you review them to make sure they stay relevant and reflect the iteration of your plans as you progress through specific tasks.
• Do everything as cheaply as possible, but no cheaper. It’s astonishing what you can get for little or no money – whether it’s products and services or the time and commitment of others. Just because other people are paying through the nose for something, doesn’t mean it’s the only way.
• Invest in tools. Yes, yes – as per above – but it’s a worth remembering that great tools can make several orders of magnitude’s difference in your most valuable resource: your time.
• Get your commercial and legal bits in order. Legal incorporation and shareholding, banking, insurance, payroll, taxes, copyrights and trademarks. All of these can and will screw you if you don’t get them sorted early on.

Getting better

• Get stuff out there. Putting something out there is better than putting nothing out there. Especially in games development. Getting anything to the point of distribution is hard – regardless of the complexity of the title itself. Once you’ve done this, you can concentrate of improving the core product.
• Sunk costs. Understand the core principle of sunk costs. Make decisions based on what happens next, not what went before. Costs to date should not sway the balance of an otherwise clear decision.
• Analytics and metrics. For your promotional activities as well as for the games themselves. There are a wealth of services out there to help you with this (e.g. Google Analytics, Flurry). It’s amazing what you find out when you start measuring stuff. There’s no better way to challenge and improve your assumptions than with data.
• Take a look at the services others are using. See what they can do for you (can they meet needs you don’t know you have). We’ve seen value beyond solving our initial problems from Skype, Google Docs, Dropbox, BitBucket/Github, Bitly etc.
• Do all of this, then do it again. There is always scope for doing more.

Specifics on – conferences

• Do not dismiss conferences. There’s a reason why pretty much everybody in the industry (AAA, indie and otherwise) treat them as pivotal points in the year.
• It’s surprising what you can learn from others. Whether it’s an introduction to a new topic or reinforcing an existing one, giving yourself the opportunity to absorb information and reflect on your work is incredibly valuable.
• It’s very hard not to network. People want to talk to other people.  Talk to them about their stuff; tell them about yours. It’s the whole fucking point.
• Present your stuff. There’s a wealth of interesting material in what we do – and for sure someone will be interested in what you’ve done. If you’ve ambitions on presenting at GDC you’re going to have to start somewhere.

Specifics on – funding

• Always think about getting paid. No one else is going to do this for you, but no one minds if you make this the most important thing – 9 times out of 10 they’re thinking about the same thing.
• Funding means everything that gets  you paid. Everything from revenue based on past successes, self funding (subsidizing) and borrowing through to angel and VC investment falls into the same category.
• Learn from the pros. VCs and angel investors generally look at you & your team, your competition, their (and your) exit strategy, user acquisition, results to date and transformational potential – you should too.
• Look at yourself from the perspective of others. Regardless of whether you’re seeking funding or not, viewing your work (and more specifically your actions) from the perspective of an outsider can highlight stuff you might not otherwise have seen. If you wouldn’t invest in yourself (or your idea, current plan etc), why would anybody else?

We just finished up an outline launch task list for our soon-to-be-announced iPad debut title – this post contains that list, effectively a draft iOS marketing plan. It’s pretty generic, so we figured it might be useful to everyone else out there.

We’ll be revisiting this over the coming weeks – if you’ve got input, questions or whatever let us know – we’ll update this post and report back as we fill out the gaps.

Where are we at right now?

Right now – July 28^th – we’ve got a mostly-finished game, a name and this list.

This is our first _proper_ release on the App Store – we’ve put a few things out there before, but this is the first time we’re doing a launch proper. We don’t expect everything to magically go in our favor – but we do know that if we do everything we can this time round we can only make positive iterations from there on out (we’ll have other stuff launching this year as well).

Required Assets (things we’ve got to make):

1. The game itself (full/paid version) – see list below of new/related features

2. Additional SKUs/version (lite/ad supported etc) – TBD

3. Various videos (launch trailer, full trailer, gameplay footage etc)

4. App assets (app description, screenshots, icon, press release/launch text etc)

5. Game website

• Cross-site stuff with this site
• Leaderboard integration with OpenFeint stuff
• (post v1) level/map sharing

Things we need to decide:

6. Decide on launch price

7. Decide on free version (lite or ad supported)

• (lite) launch date
• (lite) what features
• (ad supported) launch date – presuming same as full version at this point
• (ad supported) ad location / integration
• (ad supported) future feature set – will it get all post-v1 features?

8. Confirm app name

• Current use (revisit this since originally deciding on name)
• Trademarks in relevant regions (at least US & UK)

9. Game website URL (dedicated domain or sub-site to this one)

Features required in app (that relate directly to this list)

A good chunk of these are specific to the game we’re launching – though all are specifically launch/promotion related so completely relevant to other games, just need some adaptation.

10. News and updates pull RSS feed for front page with optional links (to other parts of app; to external URLs)

11. Separate feed (or filter for full/free apps) such that in-app cross-promo news items make sense

12. Finish “challenge” levels design – including having 4-8+ weeks worth of challenges

13. Figure out challenges integration for OpenFeint (if possible) and pushing of leaderboards to game website

14. Decide on final stats and analytics (just Flurry or our own stuff as well)

15. Decide on & implement final version of level sharing – particularly external services and iOS protocol handlers for twitter, facebook, google+ etc

• Do we register our own handler?

Other things to think about / research

16. Do we need to think about readying App Store promo / feature assets in case we get one?

Launch schedule critical path

Fill gaps, estimate time scales and update/re-sequence this launch sequence list:

17. Announce game

• 36peas blog
• Dedicated game site
• TA forum post (initial launch post) + announcement trailer
• Media host locations (youtube, vimeo)
• Offer limited number of public beta test spots

18. Release full trailer

19. Announce to iOS press

20. Distribute promo versions

21. Submit for approval

22. (update, resubmit, required)

23. Announce launch date (decide on best day of week)

24. Release v1 (at promo price)

25. End promo period

26. Announce v1.1 features

27. Launch v1.1 + promo price

Launch activities (not on critical path)

Plan and prepare for other launch-related activities (that are not on above critical path:

28. Solicit media requests for promo material

29. Identify “target” list of game biz people, iOS people, developers, media etc and do direct notifications where known or relationship exists

30. Cross-posting elsewhere of dev- or launch-related contents (inc #idevblogaday, The Cocoa Mag)

31. Speaking engagements and other public events (360idev – we’ll be speaking there and at iOS Dev UK)

32. Identify other timely launch-time events (game jams?)

33. Complete schedule of development content (blog posts etc) related to the game’s development

34. Get in touch with Mike Berg to update last year’s 360idev game jam site – this title is based on a prototype that originated in Austin 2011. Also give Jon Wilker a shout to encourage a mention – timing should be close to this year’s game jam

35. Identify and schedule other promo opportunities and offers – are “freeappaday” promos still worthwhile?

36. Release soundtrack via iTunes & some form of (free?) direct download

Post v1 features

37. Sort out development time scale such that we know when a v1.1 is released (presuming point releases – 1.1, 1.2 etc are feature-full, others 1.0.1 etc will be fix releases)

38. Decide on known likely post-v1 features (multiplayer, map editor + sharing)

Post v1 activities

39. Update this plan with an ongoing retrospective analysis / results

40. Release gameplay stats

41. Release commercial stats

42. Announce next version

43. Release next version

44. Identify competitions, summits etc -- anything applicable to enter title into

Your input wanted

Did we miss something? Is there an area you'd like us to expand on? Let us know in the comments -- we'll update this as we go.

---

Updates

28th July -- Added #44 -- re competitions and summits

Which brings me onto the key point in all of this: access. If that means $10 on a book because I didn't buy it already / don't have it to hand / lost access to it due to a poor purchasing decisions -- then so be it. Next time it'll be $0 on a wikipedia article or blog post or whatever.

If you really do want to "own" your digital content in the I-can-and-will-take-all-responsibility-for-its-wellbeing sense, then you can -- all the major digital book services provide you with permanent, resilient, local, disconnected copies of files. You just need to know how to manage each and every source and be prepared to do a little management. Compared to the pain in the ass that is finding, moving, storing and living with a large number of physical books I think it's no big deal.

Wired: "An unfinished e-book isn’t a constant reminder to finish reading it." WTF? An unfinished e-book isn't a burden on your conventionally-bent self assessment. As it happens, I do finish most books I read. In fact, I finish far more ebooks than I did physical ones because I've always got them all with me. Further counters to Wired's nonsense an be found here at allaboutthevoluntary.com.

Revisionism is a valid concern. But with a little more market saturation and a few more tools, it'll be hard to get away with. Once DRM goes away (it will), it's a non issue as copies proliferate and comparisons are easy. Existing DRM will be brute-forced in about the same time it takes for DRM in the book space to go away. It's really not an issue from a technical point of view. Sure, it'll happen (and does in print books as well as ebooks), but it'll be highlighted.

In the Kindle app on my iPhone I generally have between 10 and 15 books on the go, and manage to get through 1-2 a week. This is done either in 15-minute segments when I have a free hand and eye, or as a reference to whatever I'm working on. At the minute that includes Enter The Kettlebell!, Replay: The History of Videogames, Atlas Shrugged, The War of Art,  The Art of War, The Vegetarian Myth,  and The Art of Game Design: A Book of Lenses, Demon's Captive and Fun Inc. That includes a book not available in this country in print, one that I've been reading for about 3 months, one that's entirely reference, one that has been revised and translated many, many times but I was able to find an as-far-as-can-tell faithful translation of and one that even I may be too embarrassed to own in print.

We're at same point we were 5-7 years ago with digital music. The transition might take a little longer (recordings of music as property have been around for far less time than the printed book) but it'll happen, and in so happening a lot of these little things will go away. Those who really care about "books" (I don't by the way, I care about information), will revel (I am revelling already -- see above paragraph) in the access granted to them and embrace digital books. For the majority, the perceived snobbishness around books will eventually go away with this realisation.

The motivations of the remaining minority will become clear. Either they do actually prefer physical books as a way of accessing and digesting information (and this is entirely reasonable) or they perceive some other value in the ownership and accumulation of those physical books.

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

I'm pretty fucking chuffed about that.

We've spent much of April buliding up resources for Dead West (see DevSpawn if you're an artist and interested) and, very satisfyingly, working on a smaller side project (based on last year's 360idev Game Jam project).

That latter thing now has a name, and an art style (which oddly enough, and completely counter to Dead West, requires little art work) -- more on both in the coming week.

I have very much enjoying engaging in Warhammer Fantasy -- playing, strategizing, optimizing, painting, crafting, acquiring etc. But last Thursday night (the last game Goose and I played), for the first time, I didn't really enjoy it (this was from the outset -- not just after I started loosing). This I found especially odd as all the circumstances were supportive of a good time: we'd had a very significant output for 36peas that day; I had a busy but well-prepared-for day of PBAL the next day; the kids were in bed etc.

I'm pretty certain – in fact I know for sure – that this was because in the preceding 10 days I'd spent no time whatsoever engaging in Warhammer stuff – I'd not thought about army lists, strategized, painted or done any related activity.

Last night I spent an hour painting – and I deliberately set aside an hour so that I'd a.) have some measurable and quantifiable assessment, and; b.) go to bed at a reasonable time in order to be up this morning.

I thoroughly enjoyed it. And this morning I am happy and enthusiastic about playing later in the week and already spending my off time (time when I can't fit any other activity in -- normally between modes of transport, in lulls of conversation etc) strategizing about how I intend to play, what things I'd like to paint in advance, etc. I also listened to TWIT live in that time, something else on my list of must-do-regularly-because-get-a-good-bit-out-of-it-personally-and-professionally.

This brought me round to thinking about discipline and immersion (the latter of which Goose and I talked about in GDIM #4). Do I (can I) only enjoy the separate elements of Warhammer when I engage in them all? And does that have to be on some kind of regular basis?

Given the variety and volume of different things that I do, this is something that worries me – I want to understand better that behavior (immersion in multi-genre gaming pursuits) but I find it unlikely that I (personally) would naturally end up keeping to any kind of regular pattern of engagement (at this point in my life) because of the multitude of other (self-imposed) demands on my time. But I really, really enjoy this particular pursuit, and I find it rewarding and useful as a game designer.

So, in the interests of full immersion (I’m one army of 10+ into one game of 3+) I’m going to try something else I’m interested in – disciplined activity. This is unknown for me – I do a lot of stuff, but it’s almost all on either a get-as-much-done-in-the-time-permitted or a just-in-time basis. First part of said discipline (KISS for now) will be to spend an hour painting at least 5 evenings out of 7. I always have other activities I can combine with this (watching, listening, thinking) and it I don’t expect to have to shift anything else out of the way – but doing it against a personally-imposed discipline may change how I look at this, and, more importantly, other pursuits in the future. I hope it will also give me a better view on games from the perspective of a fully-immersed player. 

We went on to talk about a number of related areas -- primarily we were trying to pin down specifics around what engages players beyond the ostensible gaming session.

Here's the link -- Game Dev in Motion #4: Engaging Players Beyond the Medium.

For those who didn't catch the video last time, here's the audio for -- Game Dev in Motion #3: Theme, Context and Player Engagement.

If you'd like to read more of the normal excellent technical, game design and controversial game industry posts we normally write -- or watch more of the Game Dev in Motion video blog series we started recently, subscribe here by RSS or follow @36peas.

Moral Combat?

In this last week I've been less and less tolerant of, well, most everything -- writing this comes toward the end of day of further intolerance. Timely then that I've just been pointed at this: Moral Combat, Why do liberals play computer games like conservatives?

I'm not going to get into arguing the politics or philosophy of the thing -- there are others far better suited. But Just a couple of observations...

I don't think this (which, by the way is an article about The Sims and to some extent Sim City, Civ and Call of Duty -- not video games) and its suggestion of games being anti-liberal is about game developers deliberately setting about making anti-liberal games. In the case of these games, they set about making simulations -- and, because we live in a conservative society, these __simulations__ simulate conservative tendencies.

As members of that merry system of reinforced groupthink and repressed individualism, the general populous thrive on being rewarded for being themselves. That ostensibly conservative actions are rewarded for the most part is somewhat irrelevant -- it's that people are doing well at simulating the real world. They're being validated as Citizens.

People like to pretend -- and generally their imaginations are limited -- get them to play something more abstract (like Love) and they're lost, get them to play something more removed from their reality (like Dragon Age) and they're put off by the fantasy and childish "make believe".

Call of Duty, is this context, is something of an anomaly here -- it's only conservative if you define violence (not the reasons for violence, but the act of violence itself) as something exclusively conservative. The context in the CoD games is generally too shallow to assess the reasoning for why -- only enough to suggest what. That it's so popular is as much about individuals’ generally power-derived pleasure and need for constant validation as it anything else.

Oddly enough, it's only The Sims (the primary reference material -- in fact the pivotal reference material) that I don't enjoy -- it provides me with no fun. Sim City and Civ I find enjoyable because I assert power over the game itself through my learning and digestion of the apparent complexity. Call of Duty I enjoy because of the more visceral development of skills and, yes, application of power.

In summation and argument for these games as an exploration of liberal and conservative methods, Greg proffers:

The lesson: Getting results from liberal policies takes a tremendously long time.

What nonsense: of course you are more likely to more rapidly succeed in a simulation of a conservative society by behaving conservatively.

Edward Castronova extends this further and asks if there are liberal and conservative moments in games -- and if incentives in games are strong enough to lure people into acting contrary to their moral commitments. Of course on the former - look for something and you'll find it. On the latter, well, yes - people naturally (it seems) want to perform better: if the games they play set about simulating a (conservative) reality, then acting (conservatively) will improve your performance.

Edward also suggests that research on Moral Foundations Theory by Jonathan Haidt is the "best thing yet offered on the difference between liberal and conservative thinking." If it's supposed to be in any way comprehensive, it seems to be wholly inadequate when I try to use it to describe my own "intuitive ethics".

Back to, er, reality

Like I said, if you'd like to read more of the normal excellent technical, game design and controversial game industry posts we normally write -- or watch more of the Game Dev in Motion video blog series we started recently, subscribe here by RSS or follow @36peas.

Thanks Miguel for setting up #idevblogaday. I'm excited that with the new rules we'll get a constant cycle of authors and content. Good luck to the rest of you, I look forward to welcoming you here in the short term - and back on the #idevblogaday list in the long term / long list.

We cover:

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.

Innovative multiplayer design can be built atop underlying mechanics that don’t necessarily even need to be iterative – they can simply be reused.

Most contemporary multiplayer (especially in the AAA space) is repetitive. Shoot this, capture that, win the match – etc. Because of the (human) nature of such multi-player experience this does – don’t get me wrong – provide a lot scope for a lot of fun gameplay. But we can only change the scenery so many times.

However, a couple of recent stand-out multi-player (featuring) titles have used this to their advantage. Instead of re-inventing the core, they left it as is and created a novel multi-player experience on top of it.

Left 4 Dead took what Valve had already perfected in the Half Life engine and underlying systems and added a fixed-build co-op setup (4 players, with 2-4 being either human or companion AI) and truck-loads of pretty stupid – and pretty terrifying – zombies. The result: a survival co-op experience that forces the player to work as a team and co-operate with their companions to succeed (which, funnily enough is exactly how the gameplay is packaged: 4 strangers meet under unknown circumstances and are forced to work together else die alone). This “forced” nature that I’m getting at isn’t a player-1-press-this-while-player-2-presses-that – it’s completely emergent; founded in the fact there’s a lot of zombies and as well as acting as bait while your buddies take out the tank… you’re also going to need to be helped up every time one of them jumps you.

Assassin’s Creed: Brotherhood does something very similar with an emotive multiplayer experience that we wrote about last week. It uses the solid foundation of its ancestry (and many stealth action games that went before - see above) as the platform for a competitive multi-player game mode that on reflection is obvious – and ends up with you needing (not being forced) to play the role of an assassin in order to succeed.

So?

So, they stand out because they do something new – both provide an emergent role-playing  (note the lower case “r” and “p” there) experience by offering novel game design atop solid genres, building further on the inherent emergent properties of multi-player games.

As well as providing new multi-player experiences, embellishing well-trodden genres with your own magic sparkle gets around the risk of un-polished (or outright un-tested) underlying mechanics (there’s really no excuse for this in the FPS/TPS genre): all you have to test - and perfect - is the sparkle.

You don’t need to re-invent the wheel to provide a new and interesting multi-player experience. Use what you know – just do *something funky with it.

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.