It's not what you do, it's the way that you do it

There are as many different ways to develop games as there are game developers. Maybe more.

Pretty much all of them agree that it's a good idea, early on in the project, to take a look at the way the development is going to continue.

The hollywood production

Massively rooted in the cathedral model, some developers would set a date for the projects completion, based upon what they think about the market, and then start planning what features go in when.

Important decisions would be made by a small (three or four) man team, who would dictate to the rest of the team.

It would likely be a big team. This model works, when it works, by throwing money at a problem until it goes away. The theory is that when you're spending a billion on marketing, a couple of extra tens of grand in development is cheap.

I'm not going to talk in much detail about this model, as obviously, I don't have the funds to actually do it - but I'll point out that when such a project tanks, it tanks big. Sometimes you get good games out of such a model, and almost always you get very polished ones.

The visionary approach

Once upon a time all games were produced by coders working late into the night in sheds. Sometimes literally. Nowadays almost any game is going to need some kind of a support team, but certain big projects can still work this way.

One single person does the main part of the coding. Integration is done first, and they usually build the 'engine' singlehandedly. The rest of the team does art, level design, sound and so forth.

The 'single person' guides and builds the game, and estimates when he'll be done. Once he's done they announce a ship date, and start polishing. Whatever the rest of the team has done at that point, ships.

For the simple reason that this is a LOT of work for the one person, I'll not be using this - but the 'celebrity status' of certain game designers is definately making this model very popular right now.

Sourceforge

The bazaar model of coding, the current source is available to all, and anyone can add anytyhing. No 'single product' is designed and created, and it's very hard to guide the project - if some coder adds a toaster to your design, your design now has a toaster in it.

The plus side, is that if you have a 'nifty project' then you can get a lot of help on it. Also, because of the varied coding approaches, you tend to end up with very stable core modules - and it tends to run on any hardware you can imagine.

There are several disadvantages to this model for a game.

The first is that the project is ALWAYS out there - it's very difficult to build up enthusiasm for a 'release' and thus a marketing push is hard.

Also the core designer loses a lot of control.

Finally, it tends to be very slow. A heck of a lot of time is spent co-ordinating the various groups working on it, and recovering from groups that fail to fulfill their promises.

It can work, the mod community most games have is proof of that.

Central Planning

A group of four people reaches a decision far more easily than a larger group.

A timeframe is drawn up by splitting up the spec. Times include estimated time to design the spec. Double the total time, and put a priority on the feature set. Now you have your estimated release date.

Split up into teams, and start designing the interfaces for integration.

Regular meetings cross team, always trying to keep below four, are held to keep everything up to date.

Once you're about halfway through the time, the initial core team takes about a week out to overview the state of play, and then re-arranges everything to try and get the critical bits out on time. If, as does, very rarely, happen, the project is ahead of schedule, then they start adding features.

Finally you freeze the feature set, and work to break everything.

The key features of this organisation are to have small groups doing the planning - a good composition is one person who wants to make the decision, one person who doesn't want it, one person with the knowledge to (quickly) give an estimate of how long any given proposal would take, and one person with the authority to say 'yes' or 'no' on the spot, so that work is never waiting.

Continuing this structure all the way down from the highest level decisions (shall we have this work on a mac?) to the lowest level (the texel preprocessor is too slow, do we rewrite?) should, in theory, mean that decisions can be made quickly, with the minimum of over-ruling.

Disadvantages are that it takes a lot of cunning to design the meeting groups to work well - and if they don't work well, the whole system can fall apart.

It also has a potential morale problem (work done at a low level becomes pointless because of a higher level decision) and that can cause a lack of communication.

It also has a fairly high management overhead, lots of meetings per work unit ;)

Informal Organisation

Sceptics of this would call it "rant and pray" - optimists who felt inclined might use words like "synergy" and "diverse vision base"

Basically, you only employ people who share your 'vision' of what the product should be, periodically hammer home any unpleasant realities (nice, but no time! No time!) and, pretty much, let 'em rip.

The more successful mod projects have generally used this model. TF for example. (CS was more the 'cult - single god coder' model)

The disadvantage? A fair chunk of those mods that failed miserably have used this model too.

So - what's best?

Well - what's best is what turns out to have worked for you.

For this discussion, we will be using a mix between the central organisation and visionary models. Maybe later we'll throw it open to the bazaar (once we've got something to show)

Oh - I just thought up a new model. To compete with 'central planning' you'd have 'capitalism' - throwing open parts of the coding, and even the central core, to bids from any team who want them. Pay 'em on completion, and largely with profit shares as incentive to do well. Also have the traditional test team animosity, as they get paid for modules that fail to get in... It's a theory, but one I've never seen successfully employed to any degree. See the NHS.

State of play

We're about ready to write out the first draft of the product requirements spec. Yeesh - you'd think my repeated requests for feedback woulda produced SOMETHING by now.

Arbitarily, right now, I'm going to set a release date of three years from now.

Right - get your butt back to catnews or take a gander at the previous episodes of this fantastic adventure into the mind of someone pretending that they can write instructions on how to write a game without writing a game:

1. Story telling
2. Game design
3. Initial Concept
4. First Impresisons
5. Lasting impressions