Resurrection ahoy! It’s about the time of the year when I dust off my blogging gloves and list what’s been keeping me from doing stuff over the past 365 (or so) days.

The format is as follows: games in bold are ones I finished (to my satisfaction) in ’09, games in italics are ones that I plan to finish, and they’re sorted alphabetically by platform.

Let’s start with the Wii. The single and only game that I played on the Wii this year was… *sigh*

• Wii Fit

I spent a few hours on it at the start of the year – had some fun mini-games and stuff! However, doubt I’ll ever be going back to it.

DS

• GTA: Chinatown Wars
• Professor Layton and the Diabolical Box
• Scribblenauts

I’ll get to them, I promise…

360 (thank the Maker for online played history)

• Banjo Kazooie: Nuts & Bolts
• Batman: Arkham Asylum
• Bionic Commando
• Brütal Legend
• Chronicles of Riddick: Assault on Dark Athena
• Dragon Age: Origins
• Geometry Wars Evolved 2
• GTA IV: The Lost and the Damned
• Mirror’s Edge
• Peggle
• Red Alert 3
• Red Faction
• Resident Evil 5
• Rock Band 2
• Splosion Man
• Scene It? Box Office Smash!
• Shadow Complex
• Super Streetfighter 2: Turbo HD
• The Saboteur
• Trials HD
• WET

Once again my preferred platform – however, the PS3 took up a large chunk of my time with some great exclusives…

PS3

• Demon’s Souls
• Metal Gear Solid 4: Guns of The Patriots
• LittleBigPlanet
• Uncharted: Drake’s Fortune
• Uncharted 2: Among Thieves
• Valkyria Chronicles

PC

• Captain Forever/Captain Successor
• Empire: Total War
• Left 4 Dead 2
• RunMan: Race Around The World
• Spelunky!
• Time Fcuk
• The Last Express
• The Witcher

Similar to the DS, I didn’t really give enough time to my PC in ’09, despite getting decked out with a schw33t gaming rig. Will try and remedy that this year!

And finally, my top 5 for ’09 – a year that turned out to be pretty fantastic overall.

5. Demon’s Souls

4. Spelunky!

3. Valkyria Chronicles

2. Batman: Arkham Asylum

1. Dragon Age: Origins

With Uncharted 2, Brütal Legend, and GTA IV: The Lost and the Damned close runners up, and Dragon Age: Origins handily sneaking into first place in the final days of the year.

My goals for 2010? Turn quite a few of those italics into bolds, and to buy less games! My current plan is to buy one game a month, which is now looking like:

January: Mass Effect 2

February: Bioshock 2: Sea of Dreams

March: Splinter Cell: Conviction

April: Red Dead Redemption

May: Crackdown 2

June: Alpha Protocol

July: Mafia II

Whenever Heavy Rain drops, everything else will probably be delayed a month, and Max Payne 3, Alan Wake, and The Last Guardian all look pretty exciting as well. From what I can tell so far, it’s going to be pretty hard to stick to the plan… but hopefully it’ll give me time to finish some older games that I’ve been meaning to finish for a while, and for (hopefully) spending some more time making games as opposed to playing them.

Been a bit quiet here as of late, partly because of Batman: Arkham Asylum, but also because of the iPhone game I’ve been working on, which we’ve tentatively named Darkness Falls. After the Digital Distribution Summit two days ago, I realised that if I want this game to get noticed at all I’m probably going to have to do some more work on the promotiony side of things. Simon Carless’ speech was pretty schweet.

Anyways, part of that is the neeeeeew website! Which we’ll try to update every now and then with how we’re going, images, video, etc.

Regarding the game itself, I’m starting to get the first few lines of dialogue in (whee!) and working a bit more on the hud and visual aspects, just to try to spit shine it and make it look a little bit more presentable.

More soon!

On the 8th of June, my two artist friends and I sat around a table slurping down noodle soup and discussing possible ideas for an iPhone game. Six weeks, hundreds of work hours and five thousand lines of code later, we are knee-deep in the production phase, taking our initial prototype and turning it into a fully fledged game.

While I’m not prepared to reveal exactly what the game is yet, I feel comfortable divulging developmental information and thoughts, mostly because I think the notion of absolute secrecy in game development is paranoid and regressive in regards to the evolution of games as a whole. [1]

I’ll try to cover a few aspects of our development process in this journal – for starters, the choice of the foundation of the game.

I came to the iPhone a complete and utter noobcake, so I went through a few UIKit tutorials (that’s the Interface Builder and .xib files and all that stuff), before I realised that most games used OpenGLES, cuz’ for apps that need full-screen refresh (like most games) it’s waaaay faster. I didn’t like the sound of starting from scratch in OpenGLES, so I decided to look at some kind of middleware solution, and… tasted a few.

All game engines lie somewhere along a spectrum. On one end of the spectrum (let’s say, the left) is flexibility and speed, and on the right end of the spectrum is ease of use and the amount of game that is already made for you. The fastest and most flexible engine, which resides on the left limit of this spectrum, is no engine at all – you are unlimited in what you can create, and it runs infinitely fast. On the right limit of the spectrum is a complete game, which is so similar to your finished game that all you need to do is change the data that is read in, not the game itself – you are “modding” the existing game, as opposed to actually creating or modifying any systems code-wise.

Every developer has a preference for a different point along this spectrum. A lot of programmers that I work with at my day job prefer as close to the left limit as possible – they don’t mind re-inventing the wheel, because it’ll be their wheel, and they’ll know exactly how it works. On the flip-side, people in the designer role at big game development companies operate very close to the right limit – programmers make the game (by creating tools for them to use, and the environment that their content resides in, and the rules of that environment), and the designers mod it to fit their vision.

Personally, I live somewhere in the middle – I don’t like re-inventing the wheel if I can help it, but I’ve also worked with a few engines that do too much, which makes them slow, clunky and very intractable when you want to do something that the engine’s developer didn’t expect.

With that in mind, my thoughts on each of the major “engines” (which as of this writing are cocos2d, oolongengine, Unity, Torque 2D and SIO2) were as follows:

• oolongengine: We were initially looking at 3D as an option for the game, and while very fast, oolongengine is also extremely bare-bones – from what I could tell, at least when we were looking at it, it just handled importing PowerVR’s POD format and cobbled together a few other open source components into one package. This would be a good starting point for one of the hardcore programmers I mentioned earlier, but I didn’t like the prospect on spending a month or two setting up model managers, scene managers, animation managers, camera managers, etc. before being able to start work on the actual gameplay itself.
• SIO2: This option was a lot more along the lines of what we were wanting out of an engine – a lot of the base 3D stuff was there already, not to mention some sound, physics and lighting/shadows. Unfortunately, we discovered that the tool chain is based around Blender – a fine program I’m sure, but my art-monkeys are Maya-based, and this would require them learning a significantly different way of modelling in a new program. [2]
• Torque2D/3D: Do you remember the slow, clunky and intractable engines that I was talking about earlier? As part of a university group project I worked on a game called Cataclysm (video available on my terrible final year folio site) which used the Torque Engine, and while it was the right choice for game development novices such as ourselves, it definitely didn’t bend very easily when we wanted it to be something other than a 3rd person shooter. Having an engine that’s a lot closer to a finished product is great for some people, and the GarageGames community is a fantastic group of developers, but from my experiences I feel that Torque is one of those engines that isn’t intended as a foundation to build a game upon so much as it is a pre-existing game that you can mod and load custom content into. (This, as far as I’ve deduced, is similar to how a lot of big-budget engines – Unreal, Gamebryo, etc – are designed as well.)
• Unity: Lowest on my priority list was Unity – I’ve heard good things about Unity in general, but after looking at their website a lot of the points previously mentioned about Torque came up – I feel much more comfortable knowing and understanding roughly what’s going on behind the scenes, and in engines that are designed for “anyone” to be able to make a game in, it’s often a lot harder to get to the core of what’s actually happening (Flash, anyone?). The fact that it’s the most expensive option on the list didn’t help either.

And finally, cocos2d, which is what I decided to go with. As you can probably guess, it lies in that middle ground between complete game and flexible nothingness – there are a lot of core systems that I now don’t have to worry about (I don’t need to know how to load up a texture, how to apply that to a quad, render that quad, etc.) – but the engine (or API, I guess) is still designed for flexibility and speed over being noob-friendly – which suits someone with a couple of years of game dev experience such as myself perfectly.

That would have been enough for me – fortunately however, it wasn’t enough for Ricardo Quesada and his team at Sapus Media, and it also comes built in with a scene state manager, z-sorting with layer support, and a heap of nifty features such as scene transitions, sprite animations, tilemaps, etc. [3]

Furthermore, along with being free (although I’ll definitely be donating to the project), cocos2d is open source, so I can go in there and change anything I want, or, more importantly, I can have a closer look and see exactly how a specific feature works. Looking through the cocos2d codebase, it’s obvious that the people behind it know how to code concisely and intelligently – pretty much everything that I look at makes sense at first glance, and for the most case the logic works in the way that I’d want it to if I had written it myself.

Cocos2d isn’t perfect – the lack of documentation makes the first few steps difficult, although there’s a great whitepaper by the folks over at Monocle Studios which walks you through getting set up and putting something on the screen. And, due to the nature of it being a work in progress, you’ll occasionally come across components that are not quite yet finished, or might need to change things around a bit when a new update comes through.

Regardless, I highly recommend it – a few measly hours after getting started I had a title screen fading through to a main menu (with clickable buttons!) and a little mans walking around on my iPhone screen, and it’s been smooth sailing from there.

There’s a lot more that I want to talk about (transitioning from C++ to Objective-C, the design and development process, team structure and work ethic), but I’d better leave it there for now. If you’re interested in cocos2d, here are a few other links that I found useful:

http://www.clintharris.net/2009/iphone-app-shared-libraries/ – Setting up cocos2d as a shared library in XCode.

http://www.bit-101.com/blog/ – Blog of a dude getting started with cocos2d, with tutorials.

http://lethain.com/entry/2008/oct/03/notes-on-cocos2d-iphone-development/ – Some notes on the core features/functions of cocos2d.

- Jason

[1] The games industry just got BURNT!

[2] Before you say it, yes there are ways to export models from Maya to Blender, then probably to SIO2, but in my professional game development experience, the more steps in your tool process, and the more programs involved, the more things are going to go wrong, and I didn’t want to have to spend lots of time dealing with the intricacies of exactly what would and wouldn’t carry over from Maya to Blender. That said, if you’ve had good experiences with this, let me know! If I go 3D with my next game, SIO2 might be my best bet.

[3] Another resource that Sapus Media has put out there is cocosLive, a service that you can hook up to your game that hosts a high score table for you – for free!

I’m in the process of making a few different design documents at the moment, so that our iPhone development team can have some options to choose from.

After writing a couple of docs, I’ve massaged my design document “template” into something that really works for me, and I think works better than the traditional formats for independent game development.

The documentation style you get taught in university and at game companies tends to have a large focus on target audiences, marketability and “selling the project” to whoever is reading it, as opposed to describing the project and laying it out in a more objective and easy to read manner.

The pitch approach is great for when you’re making something primarily to sell it – however, in the case of indie game development, often your goal first and foremost is to make something good that you can be proud of, and saleability/popularity, while still desirable, is not the highest priority. You don’t want to be filling your informative design documents with it.

After stripping that stuff out, and adding a couple of sections that are more important to focus on early for smaller development groups, I came up with the following layout. The blue sections are only for story-driven games. For games that are purely gameplay without a narrative, they can either be left out or replaced with a very brief thematic summary.

Intro

1 paragraph description of the game. Describe your game in as few words as possible, as if you only had seven seconds to explain it to somebody. Attempt to capture the feel of the game – general enthusiasm (“This is a fantastic and exciting 3D platforming game!”) is less valuable than text written in-theme, such as:

The dame’s gone missing, and, just like always, you’re to blame. Now you’ve gotta beat your way through an undead horde before she’s sacrificed to Zombie Jesus… and you didn’t even get to eat breakfast. The Battle for Zombie Breakfast is a horror/noir 2D side-scrolling beat-em-up starring Isaiah Stakes.

Character bios

1-2 paragraph description of each of the major characters. Mention in particular how they figure into the game itself, and the way the player will perceive them initially vs. once they get to know them.

Rough plot

4-6 paragraphs. With as little backstory as possible, describe the game from start to finish. Include a rough breakdown of what is cutscene, what is gameplay, etc. With each part of the plot, it should be obvious how it will be presented in the game itself.

Gameplay description

1-2 paragraphs describing each distinct mode of gameplay, starting with core gameplay. For instance, Half Life 2 would first describe general running around and shooting, then twists on the core gameplay (such as the gravity gun), then vehicle sequences.

Artistic style outline

2-3 paragraphs describing the artistic style and feel. Cover actual in-game art, UI and menus and sound. Mocked up screenshots are preferred, if not, reference art.

Systematic breakdown of components

A rough outline of what systems will be required (for example, ones that will show up on most lists: 2D and/or 3D renderer, state machine, save/load system, UI system, collision system, particle system, etc). Include special features that, while they may not have their own system, will still need to be accounted for when creating systems (ie. day/night cycles, sound affecting gameplay, etc). If you will be using an API/SDK for a system, note it down – you’ll still have to do some work learning/integrating the foreign system.

Asset breakdown

Similar to the System Breakdown, but for visual assets, text and sound.

• Art Assets: List each major area of artwork (Player, Enemies, Worlds, UI/Menus, HUD, Effects), specifying roughly how detailed animations and states will be, and however much you know at this point about the pipeline/programs used.
• Text Assets: Identify major areas (tutorial, tips, scripted dialogue/quests, dynamically presented dialogue, narration), and attempt to gauge the amount of effort required on each section.
• Sound Assets: Similarly, the major areas (In-game sound, UI/HUD feedback sound, music, voice) should be detailed and described.

Suggested Game Flow Diagram

The intent of this section is to lay out, step by step, what the player experiences from as soon as they turn on the game until the end. While this can be generic and use a lot of loops (ie. Start Game -> Cutscene -> Tutorial -> loop(Cutscene -> Level -> Results Screen) -> End), it’s probably a good idea to attempt to envisage how your game might be able to break up the monotony that is evident in that design.

The great thing about this section is it gets you really thinking about what your game is and how it is presented, as opposed to the amalgam of disjointed ideas in your head. The deeper you get into this Game Flow Diagram, the more confident you will be about what your game is precisely made up of, and what the experience of playing it will be.

Suggested Project Timeline

Here’s where we get to the part where hearts break and tempers are lost – laying out a rough schedule for the game’s development that utilizes the breakdowns that were made earlier in the document. Schedule aggressively, but be realistic – you’re probably not going to get all of your menus in and working in a day. You don’t have to be specific about where and when – the most important information to end up with here is the number of man hours per team member required, and exactly who will be responsible for what.

Additional Ideas and Possibilities

This final section is a bit of an amalgam of everything that didn’t fit in the sections before hand. It’s an appendix of all of the things that you didn’t think were necessarily core to the game, but you’d like to consider along the way. It’s also for alternate possibilities – for instance, if you had two main characters in mind, put the better one in the main document, and then the alternate here. Finally, if you have any ideas that you’re not sure about, but would like to prototype, then this is the place for that stuff as well.

That’s it! Design Documents made in this layout can be anywhere from High Concept length (2-3 pages) to full GDDs (anywhere between 5-50 pages). And finally, a few general bits of advice:

• Be thorough, but don’t be absolute. Remember that everything must be allowed to change and evolve over the course of the project, and the design document is a general description more than a blueprint. If you end up with a totally different game to the one that you laid out in the design document, as long as it’s better it doesn’t really matter.
• Don’t be hesitant to name check other games; it’s often the best way to get across a point to yourself/your team members. That said, don’t make that all your document is. (“The wit of Grim Fandango meets COD4-quality FPS meets LBP user-creation” sounds great, but doesn’t explain what you’re doing or how you’re going to do it.)
• Write well. Just because this is for your team’s personal use doesn’t mean that you shouldn’t try to make it as readable and expressive as possible – remember, this is the document that you’ll be looking back on during development to try to recapture the feelings and ideas you had about the project in the first place.

HTH, HAND!

It’s been a little while since my last entry, whose soapbox flavour has irritated me every time I’ve glanced over it since it was posted.

In any case, Stuff[tm] has been happening while the blog went dark. After feeling like I’d hit a bit of a barrier with the Thief and the Nobleman project I decided to work on something less experimental – something that I can actually make and release.

I’ve begun work on the bare bones of an iPhone game, and am discussing possible projects with a few people I know. It’s cliche, I know, and I honestly don’t feel entirely validated with the decision to move to the burgeoning indie platform… regardless, it’s exciting, and at least for the next few months I can probably get my artist friends excited about it too.

There are multiple avenues open at the moment, particularly with 3.0 introducing paid DLC. Without divulging too much, the project that’s most on my mind as of late is an interactive short story. In any case, I’ll endeavour to keep this page a bit more up to date with the developments (courting artists, planning the project, production) of this… er… endeavour.

We live in interesting times!