Protoyping is Underrated

Maybe underrated is the wrong word. Underutilized? I'm not going to say that prototyping is the silver bullet that will save the game industry from itself, but man, it sure can help. The ability to think, talk, act, and decide upon things based on decisions made while actually playing the game versus trying the same things when all you've done is thought about the game is just very powerful. How can you really decide that something sucks when you haven't even tried it? Some ideas are just obviously unfeasible or just plain don't sound like fun, but there are plenty of things that only show up once they're partially implemented.

A lot of companies pay lip service to prototyping but actually end up just implementing things too fast. And frequently gameplay can be one of the last things to be implemented. Having something up and playable is rarely as high a priority as prety graphics, this is somewhat understandable due to the fickle market that seems to be easily swayed by graphics, thus causing publishers to depend on graphics as a selling point and making it more difficult to sell them on gameplay alone.

And let's face it, fantastic gameplay with crappy graphics will rarely sell huge copies unless there is something truly amazing, new, and different (witness Wii). Even then it's unlikely. How many "fantastic" games do hardcore gamers lament as being killed due to an ignorant or immature marketplace. So yeah, prototyping is a tough sell to a manager of a game studio.

But it's really important to sell it.

I think it's the difference between a crap game and a mediocre game, a mediocre game and a good game, and a good game and a great game. It's the difference between spending time, money, and manpower on something that's not worthwhile and saving your resources for what really works. It's the difference between long masturbatory discussions about "big ideas" and hard nosed, nitty-gritty discussions about what's working and what isn't.

So now that prototyping seems to be A Good Thing, how do you do it? Normally a game team consists of artists, programmers and designers. Designers is a pretty broad term, usually this refers to level designers and mission builders. Programmers control the functionality of the game. They're the ones who do the implementation. If a programmer has game design or visual inklings or can be trusted to properly iterate a system, it's probably smart to have them be the driving force behind prototyping the feature. Some programmers don't have this inclination and are still useful to have to implement things, so in that case, the programmer should be paired with a designer or artist depending on the feature. This way a programmer can implement the base functionality and the designer or artist can then take what's there and tweak it and ask for different or more functionality. An example of this could be a skin shader that a game needs to make a character look right, and a programmer who isn't that visually inclined. That programmer could go to an artist, show him or her what it looks like, and expose parameters in the 3d modelling package for the artist to use to make the shader look right, the artist could also ask for different looks to the shader, which the programmer would have to then go and implement.

The same could be done with a design feature, a programmer could implement a drivable vehicle and expose a bunch of tuning parameters, and a designer could step in and tune the parameters to make the vehicle "fun", and thus be the driving force behind the prototyping.

The one constant rule is whomever is actually doing the prototyping is in control of the feature. Having a document written up for a programmer to then "follow" is not prototyping. One gets a feature into the mindshare of the team, gets it implemented by a programmer, and then either the programmer iterates on it, or exposes values for other teams to use for iteration. No one is reading a document and implementing, because whatever is in the document isn't as good as what can be implemented. Period. Long, detailed design docs that aren't a product of prototyping are by and large masturbation.

Anything too difficult to prototype as a game mechanic is very likely too risky to implment in the game, and so should seriously be considered for cutting, even during preproduction. Prototyping should be able to come before technology. If there isn't enough technology to prototype, then the team should be reduced in size until there are enough programmers to build an engine for prototyping and enough artists to support the engine efforts, or an engine should be licenced that allows prototyping. There should be no designers on a team like this. Unless they can prototype in some other, existing game engine while the other departments are working. Having a team of people churning out documents that no one will read is an incredible waste of time. Even if people do read them, they're usually not well-considered enough to be actual gameplay features.

Agile development seems to be a good way to go about prototyping with a focus on refactoring. Early prototypes should be hacked in to get the feature visible to the various departments, and then refactoring should be used to ensure the code stays maintainable. Unit tests may also prove useful in this endeavor. This relies on a very good prioritization of features, however. Without a strong list of features with a good prioritization, you'll end up prototyping the wrong things first.

In the future, as game projects become so expensive that any wasted time or effort is a huge blow to the product's success, I think prototyping will become the difference between a successful team and a failing team. Prototyping shows the compromises that will have to be made early, and it shows the best parts of your game early. It saves tons of time, effort, and money. It's just the right thing to do.