team working on your project from the very beginning, and those people need to be
kept busy making art, building levels, or coding up systems, even though there may not
yet be a functional and fun gameplay prototype. It does not take a large team to get the
initial gameplay working, and indeed such a large team may only get in your way as you
try to keep them busy while experimenting with how the gameplay will work. You may
also have demands from those funding your project’s development, whether it is your
employer or the publisher. Whoever is paying the bills may want to see a complete
design document or script up front, before a prototype of the game has been developed.
You may be forced to abandon those documents later as the gameplay turns out to work
differently than you had anticipated. Obviously, crafting these documents prematurely
can be quite wasteful, yet you are forever beholden to whomever is providing the fund-
ing for your project. In some ways, if at all possible, it may make sense to self-fund the
project until you have a fully functional prototype. Work on it “under the radar” if you
are at a large company, or work on the gameplay prototype before you try to find a pub-
lisher. Besides, a playable demo will make the game easier to sell to a publisher or a
green-light committee. Nothing proves to the financiers that your game is moving in
the right direction better than a compelling prototype.
Building the Game..............................
The best way to build your game is incrementally. Instead of working a little bit on all
the different components of the game, you should try to complete one system before
moving on to the next. Work on the most basic and essential systems first, and then
build the systems that depend on that system. This allows you to implement a system,
test it out, see if it “feels” right, and only then move on to the next system. That way, if
you must change the underlying system to get it to work properly, your subsequent
systems can be changed accordingly, before you have gone to the trouble of implement-
ing them. It can often lead to disaster when you have a number of programmers
concurrently working on coding up a variety of systems that work together. If one sys-
tem has to change, other systems may need to be radically reworked. Better to build a
solid foundation before trying to build on top of it. Programmers often enjoy working on
their own isolated part of the code without fully considering how it will have to interface
with the rest of the project. It is important for your programming team to be constantly
focused on the big picture of making the game playable and fun.
Core Technology.............................
Of course, all computer games rely on an underlying technology that has very little to
do with the gameplay, usually referred to as the game’s engine. Certainly you need to
make sure that this underlying technology functions at a certain level before any work
can be done on the gameplay. However, you do not need the engine to be perfect or fea-
ture complete before you can start building your prototype. Indeed, on a project with a
cutting-edge engine, waiting until the engine is truly finished may mean it is too late to
spend enough time refining the game itself. The peril of working with unknown tech-
nology is designing around projections of the capabilities of the technology. If you
design your game thinking you will be able to have ten enemies on the screen at once
and your engine turns out to be able to handle only three, you will need to radically alter
286 Chapter 15: Getting the Gameplay Working