Many years have passed since the days when games were designed in a couple of
hours at the family barbeque. Today, games are required to be fun and addictive,
but at the same time meaningful and intuitive. The latest games released by the big
companies take months to design—and that is with the help of various designers.
Contrary to popular belief, a game designer’s sole purpose isn’t to think of an idea,
and then give it to the programmers so they can make a game. A designer must
think of the game idea, elaborate it, illustrate it, define it, and describe just about
everything from the time the CD is inserted into the CD-ROM drive to the time
when the player quits the game. This chapter will help you understand a little more
about game design, as well as give you some tips about it, and in the end show you
a small game design document for a very popular game.
This chapter goes over the software development process for game development,
describing the main steps involved in taking a game from inspiration to completion.
This is not about creating a hundred-page document with all the screens,
menus, characters, settings, and storyline of the game. Rather, this chapter is
geared toward the programmer, with tips for following a design process that
keeps a game in development until it is completed. Without a simple plan, most
game programmers will become bored with a game that only weeks before had
them up all night with earnest fervor.
Here is a breakdown of the major topics in this chapter:
n Understanding game design basics
n Understanding game development phases
n Recognizing post-production woes
n Future-proofing your design
n Understanding the dreaded design document
n Looking at a sample game design
Game Design Basics
Creating a computer game without at least a minimal design document or collection
of notes is like building a plastic model of a car or airplane from a kit
without the instructions. More than likely, a game that is created without the
instructions will end up with missing pieces and loose ends. The tendency is
always to jump right in and get some code working, and there is room for that
step in the development of a new game! However, the initial coding session
should be used to build enthusiasm for yourself and any others in the project, and
should be nothing more than a proof of concept or an incomplete prototype.
Like most creative individuals, game programmers must have the discipline to
stick to something before moving on, or they will fall into the trap of halfcompleting
a dozen or so games without much to show for the effort. The real
difference between a hobbyist and a professional is simply that a professional
game programmer will see the game through to completion no matter how long it
takes.
Inspiration
Take a look at classic console games for inspiration, and you will have no trouble
coming up with an idea for a cool new game. Any time I am bug-eyed and braindead
from a long coding session, I take a walk outside and then return for a
gaming session (preferably with a friend). Consoles are great because they are
usually fast paced and they are often based on arcade machines.
PC games, on the other hand, can be quite slow and even boring in comparison
because they have so much more depth. If you are in a hurry and just want to
have a little fun, go with a console. Video games are full of creativity and
interesting technology that PC gamers usually fail to notice.
Game Feasibility
The feasibility of a game is difficult to judge because so much is possible once you
get started, and it is easy to underestimate your own capabilities (especially if you
have a few people helping you). One thing that you must be careful about when
designing a new game is scope. How big will the game be? You also don’t want to
bite off more than you can chew, to use the familiar expression.
Feasibility is the process of deciding how far you will go with the game and at
what point you will stop adding new features. But at the very least, feasibility is a
study of whether the game can be created in the first place. Once you are certain
that you have the capability to create a certain type of game and you have
narrowed the scope of the game to a manageable level, work can begin.
Feature Glut
As a general rule, you should get the game up and running before you work on
new features (the bells and whistles). Never spend more than a day working on
code without testing it! This is critical. Any time you change a major part of the
game, you must completely recompile the game and run it to make sure you
haven’t broken any part of it in the process.
I can’t tell you how many times I have thought up a new way to do something and
gone through all the source code for a game, making changes here and there, with
the result being that the game won’t compile or won’t run. Every change you
make during the development of the game should be small and easy to undo if it
doesn’t work.
My personal preference is to keep the game running throughout the day. Every
time I make even a minor change, I test the game to make sure it works before I
move on to a new section of code. This is really where object-oriented coding
pays off. By moving tried-and-tested code into a class, it is relatively safe to
assume the code works as expected because you are not modifying it as often.
It really helps to eliminate bugs when you have put the startup and shutdown
code inside a class (or within the Allegro library, where the library handles these
routines automatically). There is also another tremendous benefit to wrapping
code inside a library—information overload.There is a point at which we humans simply can’t handle any more information,
and ourmemory starts to fail. If you try to keep track of too many loose ends in a
game, you are bound to make a mistake! By putting common code in classes (or
in a separate library file altogether), you reduce the amount of information that
you must remember. It is such a relief when you need to do something quickly
and you realize that all the code is ready to do your bidding at a moment’s
notice. The alternative (and old-school) method of copying sections of code and
pasting them into your project is error-prone and will introduce bugs into your
game.
No comments:
Post a Comment