You Need Four Coders [Game Development]

Games are changing. Lower costs, liberated distribution and single-franchise business models all mark quite a shift from the old days of console development and one shot economics. It’s encouraging more investors, startups and other outsiders to get involved in making games. All of these are positive things.

At the same time, I think outsiders believe too much in the hype of lean and agile development. Spreadsheets which describe getting-to-market plans with only one coder are pretty common. They’re lowballing to appear more attractive to investment, which is understandable but terribly naive. Their game will likely never get to market, or if it does it will be terrible and die on the vine.

So consider this a golden rule if you plan to make games: You Need Four Coders.

 

Lack of Visibility

Any good business training will teach you the value of reducing costs, externalising problems and finding ways to keep your business lean and mean. This is all useful learning, especially in resource-poor times like these. The problem is that such learning is often abstract. Without the pragmatic experience of doing and seeing process in action, abstract trainees find visualising the steps to get a product to market difficult, and that gets them into trouble.

Software projects are especially vulnerable to this problem. Code is oblique, takes years to understand, and its physical output can be highly deceptive. Most of what coders do happens behind the scenes. It’s arcane from the outside, and this leads the outsider to either think that something is much more sophisticated than it actually is, or much simpler than it actually is.

Abstract lean thinking (particularly people who have not actually read Four Steps to the Epiphany) leads to the second mistake. Games made in Flash to go on Facebook look a lot simpler than they actually are, especially in comparison to big videogames.

A game like Assassin’s Creed might take 100 developers two years to make because it looks sophisticated, but surely Mafia Wars just needs one coder working away on the weekends to put together, right? Actually Mafia Wars is apparently maintained by a team of over 50 people. It merely looks cheap rather than actually being cheap.

The point is that it is very hard to have a sense of the scale of the problems that developing software involves unless you’ve actually been through the mill a couple of times. It’s easy to play games with spreadsheets that show business acumen by adding people, features, and revenue lines which scale up and down as cash comes in.

It’s also delusional. Production does not need hundreds of people slaving away at the code face, but if you’re serious about creating robust games for people to play which also stand a chance in the market, there is a minimum bar under which your project plan simply becomes a work of fantasy.

That bar is four full-time developers.

 

You Don’t Need Four Coders to Prototype

A prototype is a proof of concept made of quick and dirty code that is meant for internal evaluation. It will have dozens of holes, hacks and quick fixes within it, will lack many key features, fudge others and have only a vestigial version of the game’s predicted back-end. It won’t be balanced, and certainly won’t play well, but it serves an important role. It lifts an  abstract idea from a design document and gives it some life. One coder can fairly quickly prototype almost anything.

Here, the prototype says, it will work a bit like this. Outsiders often confuses prototyping with production, meaning that they’ll look at a prototype and declare it to be a ‘beta’. In the language of lean or agile development, all coding seems to be iterations, and so why wouldn’t you release iterations as quickly as possible to get customer feedback?

This is how terrible software is made. Production is a much more significant undertaking than a prototype. Production is building the software properly.

In the old days that might have meant a multi-year project with a large team, but no longer. These days it means learning the lessons of what not to do that the prototype uncovered, and then building the base of the game in such a way that it will scale. You’ll want to put in content, distribute it via Facebook to a million people, run test driven development and other similar ambitions. You can’t do any of that with a prototype. So it’s not a beta. Not even close.

Production code is what gets you there. Once you have iterated on a prototype and then worked on a production model and iterated on that, by all means put it live. Iterate in public, be lean, use your metrics to guide further content and optimise. But you need to be doing that with production code, not your horrible prototype that doesn’t work very well.

 

The Lone Ninja

Some (usually younger) coders do not like the idea of teams. These lone ninjas are convinced that they can do everything themselves, and that the best way to retain the purity of a project is to forge ahead alone. Heroes of engineering like Steve Wozniak act as inspiration for this idea, and movies like The Social Network perpetuate the idea that one coder with sufficiently ninja skills can change the world.

A few individuals working on particular kinds of project can indeed change the world. The reality, however, is that most lone ninjas are not quite the geniuses that they think they are. They are just socially awkward coders that don’t like the stress of working with other people.

The other aspect of the lone ninja is that the projects that they choose to work on are impractical. I’ve had several developer friends of mine, for example, tell me that they could make a FarmVille clone in a few weeks by themselves. I’ve met a couple of guys who work alone in their own basements, who have a plan to take down World of Warcraft using procedural content. For every Cliff Harris or Jeff Minter making awesome software by themselves from their homes, there are a hundred would-be ninjas who have no sense of the real scale of what they are trying to attempt.

Which is fine, unless your business plan is basing its route to market on what one over-eager developer thinks is practical. It’s pretty common to find investors who have one developer mate that thinks he can invent the whole product, and every time I encounter this dynamic I know it is destined for failure. The workload is simply going to be too big and the pace of delivery frustratingly slow, and it will fall apart.

Even many semi-successful indie developers are making the mistake of having too few coders. As I discussed in the Love Your Pirates article, a real problem that many indie developers have is a conversation gap.

They work on a game, get some hype, release it and take some sales. Then it takes them another 18 months to get their next game finished. In the mean time, they often go dark. They simply don’t have rapid-enough release patterns to keep community interest in their game sustained. It compromises their ability to turn their game into a franchise, and so they end up back at zero, having to market their game all over again, and caught in a hazardous cycle.

 

Why Four?

Code is slow, incremental, involves many blind alleys, research, rethinks and realisations. It is never a stable process, and that instability intensifies if you only have one developer. When she gets lost in one of those blind alleys then the entire project grinds to a halt. This in turn leads to frustration, tension, extended deadlines and an increasing lack of confidence in the project.

This sort of chaos stabilises by having a team of four developers. A team of four can be split into two useful units of two, and those two units can work closely together (even in an Extreme arrangement) on the various sub-systems involved. Coders help each other, review each others’ code, provide improvements and suggestions, and they also help to standardise each others’ work.

Standardisation is hugely important because it makes the code legible, so if a developer dies under a bus then others can pick up where he left off. Lone Ninjas tend to produce spaghetti code that only they understand, solve problems with insane workarounds, never comment anything and so if they go under a bus then your project is completely screwed.

But why a minimum of four coders? Why not two?

Any game has multiple areas that require attention at different times. There are front end, back end, security, platform, game engine, content tool and other areas that need work. All of those pieces are not equally sized, and one team of two working on them in sequence can lead to long uncomfortable gaps.

If you are working on a social game you’ll probably need coders that can work in Flash AS3 to deliver the game UI, objects, behaviours and so on. You’ll also need coders who understand databases, SQL etc to work on the back end. Those two areas are fairly different, however, and coders are generally only able to do one or the other really well. There are only a few people in this world who are able to do all kinds of coding equally well.

No team of two developers is going to be good at everything, so by having two teams of two you are much more likely to cover all the necessary bases. As the two code teams work alongside each other to produce amazing code, they will deliver more and more pieces of the game at different paces. This inspires continued confidence in the game because it means that the results are more tangible. Tangibility helps allay frustration, nervousness and other feelings.

Finally, a reality of working in software is that requirements change, often at short notice. For example, your coders are working hard on the game’s database, and then a requirement comes through to quickly do some work on the front end for an investor presentation. It is hard for the typical single coder (or team of two) to completely change perspective like that. What happens instead is a loss of concentration and trust.

Building complex code is like watchmaking. A watchmaker needs most of his concentration in the middle of the task to complete the watch. Interruption causes him to lose his place and emotional frustration, and so considerably more time is required to recover the previous place.

Breaks in concentration will happen but they can be partially offset. With tasks of differing sizes to complete, two teams quickly become asynchronous in their deliveries which means at least one of those teams is nearer the beginning or the end of a task when a requirement change appears. So concentration breaks are less critical, development is more flexible, and work can get done even though priorities may shift.

 

Momentum

Coders and designers do not operate at the same speed, and by having too few coders you sacrifice momentum. Game design is complicated, but it’s still much easier to realise it on a man-hours basis than code. Any game action that I design might take me a day or two to wireframe it, mapping out the logic, writing a short spec and answer a lot of questions from the coder who’ll build it.

He might build a scrappy prototype version first, but to make it work to a good standard that fits with the rest of the project might then take him several weeks to implement, debug and refactor. In the mean time, I basically have to wait for the code to catch up, and the longer I wait, the more I lose touch with it.

When one coder is working away in isolation, what often happens is that they run into a tough problem and the frustration of trying to overcome that saps their enthusiasm. Or they get ill. Or break their leg. Or get another job. And the project risks failure.

Momentum engages team members with enough new and exciting things on a regular basis to keep them interested. A good group of four coders helps consign frustration to the dustbin, allows time for the annual office flu, healing time for the guy who broke his leg, and even offers a grace period for recruiting a replacement without the whole project grinding to a halt.

Momentum builds more momentum, the coders believe they really can do anything, and then the project sings. The confidence that momentum brings is possibly the largest determining factor in whether a project will ever actually ship or not.

If your business plan does not allow for four coders, in my opinion you will fail.

Comments

[Pete]

Great post. The 'Four Steps' book you cite – is it the same as this?:

http://bit.ly/clo4lu

[Tadhg]

The very same.
Thanks!

[Pete]

Hooray. Loading it on to my phone because I can't justify a Kindle because I want the next iPad.

Although my Air might mean that I can't justify an iPad which means that I might be able to justify a Kindle after all.

So many choices, so little actual money. Hmmm.

[Michaelochurch.wordpress.com]

Here's a logistical question: if low-productivity, high-performance languages like C++ were replaced with high-productivity languages like Haskell or Ocaml, in which programmers can be 3-5 times more productive easily, would the 4-coder minimum be relaxed, maybe to 2 or 3?

The game industry loves C++. For high-performance, cutting-edge graphics, this is the right choice of language. On the other hand, I think there are a lot of games, especially toward the low-budget end, where the focus is on gameplay and more productive, higher-level languages would be very useful. Such languages, although inadmissible if a product requires cutting-edge graphics, would allow the designers and programmers to see the big picture, thus improving gameplay quality.

[Tadhg]

Possibly, but I'm inclined to think not. The 4-coders thing is more to do with the people dynamic, morale and the robustness in case anything should go very wrong.

Thanks for the commnent.

[Tynan Sylvester]

Tadhg, I've enjoyed many of your articles, but this one strikes me as strange. It's like a very well put together argument explaining why chicken eggs are all white.

My only response would be to point out some brown eggs:

Super Meat Boy
AI War
DEFCON, Uplink, Darwinia
World of Goo
MineCraft
Terraria
Braid
Bejeweled (the original)
Atom Zombie Smasher
Gratuitous Space Battles
Alien Hominid, Castle Crashers
Gish
Dwarf Fortress
AaaaaAaaaAaaaa
Rollercoaster Tycoon
Knytt
The Dishwasher
flOw

Hell, why not throw Wolfenstein 3D and DOOM on that list too?

"You need 4 coders" seems extreme. More accurate might be "It's really, really good to have 2 developers", for all the motivation-related reasons you mentioned above.