Hello Player 1

Login

4 color rebellion GameSugar Toronto Thumbs Phantom Leap Tiny Cartridge Rising Stuff

Inside The Indie Game Development Cycle

Recently, I released an Xbox indie game named Word Duelist. It’s a pretty small game. It’s not really comparable to God of War or Heavy Rain – it’s not even on the level of Alien Hominid or Cave Story. However, it is a finished game, complete with a certain level of polish and playability.

I’m not mentioning this to promote my game. Instead, I’d like to use Word Duelist as an example – a case study to illustrate the development cycle of a typical video game. As I said, it’s a small game – and not all the concepts scale perfectly to a full triple-A production – but it’s a decent jumping off point until I’m ready to discuss how the big boys develop.

Word Duelist "Press Start" screen

Pre-Preproduction

As with most things, a game starts with an idea. In my case, the idea was actually generated years ago for an Experimental Gameplay Competition sponsored by Red Octane. The competition asked for games which could be played via a DDR dance pad, and my mind nearly immediately jumped to Wario Ware – an eccentric collection of minigames. After some tinkering around in my favorite text editor, I came up with the idea of a student at a university challenging other students to telepathic battles. The player would engage in these fights through a series of short games using the DDR pad. Now, if the concept sounds at all like Volcano High, it’s because I had just watched the movie weeks prior. Hey, ideas aren’t generated in a vacuum.

Fast-forward a few years. I had just wrapped up my first XBLIG game, and I was gearing up for my second. I wanted to be pragmatic – I needed a small game that could be finished in a few months by a couple people. I had this old concept laying around, and the idea of reviving it with better art and a fresh concept sounded appealing, so that’s what I did. Instead of dance pad games, I decided to shift to word games. Don’t ask me, “Why word games?” I can’t answer that.

The Duelist had no artist.  Forgive me.

Preproduction

There’s a pretty common misconception floating around of “The Designer,” who sits in his ivory tower crafting a magical design document which, upon completion, is handed to the developers for implementation. This document, of course, would have all of the details a development team would ever need from player statistics to level layouts to weapon specifications. If the reality were so neat and simple – that is, if such a document could actually exist – games would be a lot easier to make.

First ideas rarely work when creating games. Second ideas generally work just as poorly. To really land on something special, you need to wade through all your horrible concepts (and they really are horrible despite your genius) until you strike gold. This doesn’t happen by writing a monolithic document and yelling, “GO!”

I find a more iterative approach to be far more valuable. Rough ideas are prototyped to see if they work in practice. If an idea doesn’t work, it can either be modified or discarded in favor of something more appealing. If an idea does work, it can help spawn further ideas and drive other design choices in the game.

The first implementation of Word Duelist was pretty painful. Selecting letters for words was clunky, duels were either too hard or too easy or too long, and the interface was unnavigable. The second implementation was better – letter section was streamlined and combat was fleshed out – but there were still various flow issues. It took a few more iterations and a lot of throw-away code before everything felt right and I could move on to actual production.

Production

This is the stage where you’ve settled on the core concepts of the game, and you’re ready to really push forward. You flesh out the system designs, often keeping track of everything in an evolving design document. Code gets written. Content gets generated. The bulk of the workload happens.

Word Duelist features 17 minigames, about 19 characters, and nine locations. Each of those minigames needed to be fully implemented (including the AI that drove the computer opponents). Each of the characters needed to be given dialog, and often that dialog had to be driven by player progression/decisions. Each of the locations needed to be populated and connected. The multiplayer component needed to be built.

On top of all that, the game has a bunch of art and a complete set of sound effects and a handful of songs. It has a giant word list that required editing. It even has things that I can’t even remember putting in.

The final navigation system for Word Duelist is entirely menu driven.

In short, there was a lot of stuff to do. Game development is very much a job, and that is no more evident than during production. Some days are good, some days are bad, and pretty much all of them are work. If it’s the type of work you want to be doing, you’ll push through. Many, many indie developers fail here.

It can be a struggle. Guess what? There’s a ton of stuff involved in making games that isn’t just dull, it’s actually pretty painful to do. No artist wants to model Crate #43. Fixing bugs is a constant, thankless battle that software engineers fight daily. Word Duelist had problems in bulk.

The iteration that you started during preproduction continues during this phase, too. Any real system changes as it grows, and games are no different. Gameplay must constantly be rebalanced. Difficulty levels, for example, must be adjusted as features are added. I was tweaking those bloody Word Duelist duel difficulties until the very end.

The final iteration of dueling

End Cycles

There’s a saying about software development that floats around the Internet: “Once you’ve finished the first 90% of the development, it’s time to start on the second 90%.” Despite what your mathematician friend might say, that quote is actually spot on.

Once the game is “finished” – and by that, I mean that all the features are in place – it’s time to make the game really shine. Polish work is what separates a hobbyist from a real developer. Interfaces need to feel crisp and friendly, animations need to play to make the world feel more alive, dialog needs to be tweaked. Consider everything you did in production as a “solid rough draft,” and each edit during the end cycles is intended to bring you closer toward perfection.

A lot of time during the end cycles is dedicated heavily toward finding bugs in the game and fixing them. I mean heavily – users are going to do things that you didn’t anticipate. They’re going to do silly things with their controllers or storage devices, they’ll crawl into that crevice in your game you thought nobody would find a way to reach. It’s unacceptable for your game to break in these cases, no matter how much you want to cry, so you’d better find these issues before your players and fix them.

Here’s an example from Word Duelist: Word Duelist has a multiplayer mode. Two players can get together for some one-on-one word fighting. It turned out that during this time, if someone picked up another controller (one that wasn’t playing) and fiddled around, the game would crash hard. Which you might think is a silly thing to do, but people with children know that this kind of thing is going to happen and don’t expect it to be a problem.

In a perfect world, nothing ever goes wrong.  If things go wrong, we have to handle that.

Requirements Checking

This isn’t a PC requirement, but every game console has a certain set of requirements that are absolutely mandatory to get a game on that platform. Nobody’s going to take your word that your game works, so other people check.

If the game fails here, it’s a Bad Thing. Doing the checking takes time, and fixing whatever issue was found for another round of checking takes even more time. That’s time that’s better spent with your game out in the wild making money.

Word Duelist failed here. Three times.

Ideally, had the end cycles done their job, this wouldn’t have happened. When your group of testers is two people hacking in their spare time, though, things fall through the cracks. This is why you can see that this stage is required.

Was it a Bad Thing for me that the game failed? Consider this: when Word Duelist was initially submitted for requirements checking, it was during a relatively light time for XBLIG releases when competition would’ve been sparse. When my game actually was released, it came out around the same time as two or three other word games – direct competition. I don’t have any data that suggests this actually hurt sales, but I would like to believe that it did.

Release

Hurray! You’re done!

Post-Release

You’re not done.

You’ll need to advertise to get sales, otherwise nobody’s going to know about your game.  As the game hits a wider market, new eyes find new things – new bugs, new ways to improve the game. If you’re lucky, you’re on a system that facilitates updating your game. Word Duelist is – XBLIG has the ability to update games after release.

At any rate, it’s time to decide how much more investment you’re going to put into the game. This is usually a business decision – should you spend time (read: money) updating a product, or does it make more sense to start work on the next game?

A good update can serve almost as a second release – it brings public attention back to the game and inspires sales from both people who already own the game and new people who didn’t catch your game the first time. What’s more, the cost of doing this update in terms of development time will likely be considerably less than making a brand new game.

In the case of Word Duelist, the game’s base sales are pretty low, so making an update doesn’t make a great deal of sense. I might be able to get a few more sales, but given how much time updating the game would take in development and testing, it wouldn’t make financial sense.

Conclusions

I don’t want you to go away thinking that the above stages are all that’s involved in game development – this is very much a high level view. Each of those sections warrants at least another article’s worth of discussion.

Hopefully you’ve gained some appreciation for the work involved in even a small game, because that workload only gets larger when developing more ambitious projects. In the end, though, the challenges are worth the rewards – game development is an excellent job full of inspiring people and interesting problems.

And at the end of the day, how many people can say a stranger in Singapore is enjoying something they created? I can.

Sowaz - April 25th, 2010 - Reddit Facebook Twitter

the 4cr members
seal of approval

Indie Game Spotlight – Tower Climb

Indie Game Spotlight – Hero Core

Humble Indie Bundle is Bundleicious

Mckma on April 25, 2010 at 11:02 pm

Really cool article. I would love to see more as things like this always interest me. You mentioned a couple of other topics (i.e. elaborating on the already outlined here as well as talking about “bigger” games), are you going to potentially be writing more articles/a series?

1643

Sowaz on April 25, 2010 at 11:20 pm

Thanks! The idea is to have something fairly regularly (not weekly – some of us have day jobs :-). There’s definitely plenty of material to run with.

N/A

Nick on April 26, 2010 at 12:51 am

Sowaz, that was an amazing insight into video game development. I too hope you keep bringing us more info. Can’t wait to get more in depth on some of the details as well. So cool.

Mckma on April 26, 2010 at 1:00 am

Yeah I understand, whenever they come out, they come out (oh I do not look forward to having a job that requires regular/full-time hours)…

1643

Nick on April 26, 2010 at 1:50 am

Oh, and it should go without saying, but Ill definitely go get this on XBLA.

Edgar on April 26, 2010 at 9:56 am

Wow, great job Sowaz. Being a programmer myself (business programmer), I really liked reading this.
And like Nick, I think I will go grab this on XBLIG this week

EdEN on April 26, 2010 at 11:58 am

Making a game, even a “casual” one takes time and great effort. Still, what really kills a game is lack of advertising and it’s here were indie developed games suffer the most.

Sowaz on April 26, 2010 at 7:14 pm

EdEN: Advertising is… tricky. Especially with indie games, where many of the advertising venues (ie: review sites) themselves don’t have a great deal of exposure. Couple that with limited budgets not permitting paying for advertising, and you really have to hope you just get, well, lucky. Unfortunately, that kind of luck is fickle (I’ve seen plenty of standout titles ignored in the press in favor of some real rubbish).

If you know anyone with marketing sense, I’d love to meet them. :-)

2

LOGIN

close