Writing Your First Game
Ready... Set... Compile!
In this chapter we will discuss some of the necessary elements of
a game. Some of these ideas are going to seem very obvious to you,
but you would be surprised at how often the obvious is overlooked.
I'll start by listing the elements of a good game, and then I want
you to get to work. When you have your game up and running, come
back and look at this check list. Make sure you didn't miss anything
Necessary Elements of a Game
The title should say something about the game, and should also
jump out and grab the player. It should make your game stand out from
the 16 billion other games. Choosing a title is difficult. Good luck.
Believe it or not, the first game I wrote (back in 1987) didn't
have one of these. I don't know why, I just forgot it. Put a title
screen on your game. Title screens are important, because they set
the mood for the whole game. This is where you make your first
impression. Make it nice.
If you don't know where to begin working on your game, this is a good
place to start. If you can display a title screen, that means you have
leaped over some major hurdles. You have created your first piece of
artwork, using some kind of paint or art program. You have set the
video mode to a graphics mode. You have displayed the graphic in the
chosen video mode. Congratulations, you have accomplished something.
If you need help setting the video mode and displaying the graphic
file, don't panic. Grab a copy of
Fastgraph to make this first step very easy.
ALWAYS ALWAYS ALWAYS give yourself credit. Do it even if you are humble.
Do it because I am telling you to do it.
You may put credits wherever it artistically suits your fancy.
Credits can go on a screen by themselves, or on the title screen, or
on an exit screen, or on all three places. They should go in the
manual too. More about this in Chapter 8.
Give everybody who worked on your game credit, within reason.
Your artist and musician should definitely get credit. If a beta
tester is particularly helpful, you might mention him with a "special
thanks to". It is not necessary to give your tools credit, unless you
feel they are especially wonderful. Some people give Fastgraph credit
in their games, but most people do not. If you use a particularly
good rendering program to create your artwork, you can mention it if
you like. It is not customary to give credit to Microsoft for the
operating system, or to Borland or Watcom for the compiler. But
otherwise, giving credit where it is due generates goodwill, and tends
to come back to you.
Some kind of intro sequence greatly helps many types of games.
Whether the intro involves elaborate cinematics, a text narration
of the storyline, or just a static screen that sets the mood, your
game will benefit from an introduction.
Be careful when using elaborate introductions, though. They tend
to get old. Allow the user to press a key to bypass the intro
sequence if it is long. Also, you may want to give the player the
option of viewing the intro again, perhaps by selecting a menu item.
Give the user a chance to impress his friends by running through the
intro sequence again.
Put some thought into how the player will control the game. The
player should be able to pause and resume the game, start a new game,
turn the music off and on, display high scores and instructions, and
perhaps even print the order form if the game is shareware. An
attractive, innovative control panel is more interesting than a plain
Windows menu, but the Windows menu is more familiar and will be
easier for novice users to navigate. Experiment with this.
The user interface is not the same as the control panel. A control
panel may pop up as needed, but a user interface is necessary to control
the game play and exists throughout the execution of the game. Elements
of the user interface include keyboard, mouse and joystick control as
well as menus and score panels.
Help screens need to be designed carefully. They should be helpful.
They should also be easy to get to. Try to anticipate where your users
are going to have trouble, and give them the help they need.
Why would you want to stick with a boring old arrow-shaped mouse
cursor when a whole world of images is available to you? Some
developers like to change the shape of the mouse cursor when the mouse
moves over an active area of the screen, or "hot spot".
Music and sound
Modern games are expected to support sound cards. Windows makes this
task a bit easier, although there are DOS sound and music toolkits
available. The irony is, most people turn off the music when they
play a game. People like to listen to their own music on their home
stereo system. But if music is not available, your game will be considered
substandard and unprofessional. Go figure.
You need art. Don't try to do all the art and programming yourself.
Make friends with a good artist. Treat your artist well. If your artist
has trouble with things like VGA palettes, write palette matching
utilities and work around him. For articles on palette matching utilities,
refer to my other web
Not all games need a storyline. Usually adventure games and action
games have storylines. But even a puzzle game can benefit from a good
Rings of the Magi. It's a simple puzzle game where you push tokens
around and clear the board by matching pairs. The game would play the
same with or without a storyline, but the author chose to include
a story about magicians and their apprentices, and a mythical land
graphically displayed in the opening cinematics. This simple game
won Computer Gaming World's puzzle game of the year award .
A game needs to capture the imagination of the player. It needs to
be fun. It needs to be easy enough that even a novice can start playing
and challenging enough that it can't be beat in the first hour. Desiging
a game with excellent playability is the essence of game development.
Good luck with this.
Many types of games have levels. Put the easy levels first, to
hook the user in and convince him he is capable of mastering the game.
Then put in some hard levels to keep the user from getting bored.
Games with levels lend themselves well to many kinds of marketing
strategies, including shareware distribution, add-ons, sequels, and
If you are going to have levels, you will need a level
editor. Similarly, if you are going to use sprites, you will need
to acquire (or write) a sprite editor. You will also probably need
things like palette matching programs, and programs to organize and
compress your data files.
Utilities tend to be specific to the game you are working on. In
other words, plan on writing some utilities yourself, because chances
are you will not be able to find, buy or download all the utilities you
Demo modes have various functions. They can be used as selling
tools, tutorials, cheats, or screen savers. Not all games lend
themselves to demo modes, but those that do benefit greatly from
Cheat mode that allows the game developer, his best friend,
and all the hackers on the internet to obtain all the power, wealth,
energy and weapons. This game element is usually dispensable.
Think about your goals when designing your exit screen. In a
shareware game, this is an excellent place to ask for the order. In
other games, this is a good place to invite the user to come back and
play again later. Personally, I don't care for insulting exit screens
("giving up, wimp?") but some people use them, and perhaps they fit
in some games.
The game isn't finished until the paperwork is done. You need to
describe how to start the game, how to play the game, common
problems, how to order the game (if it is shareware) and where to go
for more information and technical support. Also, in an effort to
make your documentation interesting, try putting a bit of the
storyline in your documentation, or a bit of humor.
Proof-read your documentation for accuracy and readibility. Then
proof-read it again. Be professional. If you have trouble with this, get
help. Ask your beta-testers to look over your documentation, or ask your
girlfriend or your mom. Do whatever it takes, but don't skimp on the
Put a copyright notice on everything. Put it on the documentation,
on the artwork, on the game, and on your web page. Consider registering
your copyright. It isn't expensive (around $25) and the benefits usually
outweigh the inconvenience. If you have questions about check the
U.S. Copyright Office
web page , or read a good book on the subject. Better yet,
consult an attorney.
Just when you thought you were done, you get to start all over again
on a whole new program! Isn't game development wonderful?
I remember the old days when all your users expected out of you was a
GO.BAT. Now they want you to unarchive their files for them, put them
in a subdirectory, and add an icon to their Windows desktop. What fun.
In addition to the game elements listed above, you will need to
keep your marketing strategy in mind if you are writing a shareware
game. In particular, remember the user will generally see the software
without written instructions, and will often need some help getting
started. Also remember the role you are assuming: you are
self-publishing software. That means you need to handle the marketing
elements as well as the design and development aspects.
This would be a good place put instructions on how to download
and unzip the file, except that your users will never see it unless
they have already downloaded and unzipped the file. Think about it.
Most people put the file description in a file called FILE_ID.DIZ
This helps sysops (webmasters?) describe your game on bulletin boards
or in internet archives. There is a particular format for these files,
left over from the days when BBS file descriptions were 40-something
characters wide. Whatever.
The license agreement states under what circumstances a user can
play your game. In the case of a shareware game, this includes how
long a user may "evaluate" the game before they must "register" it.
Look at other license agreements to see what is standard for games in
the market you are targeting. Also read books on the subject. If you
are not sure, consult with an attorney, but beware -- not all
attorneys understand the nuances of software distribution. Try to
find a good, knowledgeable attorney.
Take control of how your software is distributed! Your copyright
means exactly what it sounds like -- you have the right to determine
under what conditions your software may be copied. Take steps to
retain and exert that right. At the very least, require that vendors
get written permission from you before putting your shareware versions
on their CD-ROMs or selling them in retail stores. If your game is in
demand, consider requiring royalties from vendors.
It's not enough just to tell people to register your shareware.
You have to tell them how to regester it. Put an order
form in your shareware distribution, and make sure it contains all
the necessary fields: name, address, title, cost, shipping, and
method of payment. Don't make the order form difficult to find. If
possible, print it as a menu option in your game, or better yet
put it on your exit screen: "Print order form now? Y/N".
This is vitally important to the success or failure of your
shareware business. Give the users a good reason to send you money.
Don't just nag them. Give them something of value in return for
sending in the order form along with their check. You can give them
more levels, another game, printed documentation, or a key that
unlocks certain features.
An unregistered shareware game doesn't have to work forever.
After a while, start nagging the user. After another while, your
program can stop working. If you want, you can embed the date of
first use into the high scores file. Your users can reset the
program by deleting the high scores file, but a majority of your
users will not be that sophisticated. You might as well keep
your security measures simple, because anything can be hacked,
and people who are clever enough to hack a sophisticated system
will likely not buy your program anyway.
File integrity checks
By this I mean something as simple as a CRC check to ensure the
integrity of the high scores file. You may want to do this even when
there seems to be no obvious need for it. At some time in the
future you may want to run a contest as marketing promotion. Your users
can email their high scores files to you, and you can check them
for integrity. That way you will know if the user is cheating or if he
legitimately beat the boss enemy in less than 13 seconds.
It is not necessary to spend a lot of money on packaging a
shareware program. Unlike a product sold in a retail store, the
customer will not see the packaging until he has already bought
the product. An expensive box with glossy graphics will not
increase your sales.
On the other hand, you will be showing your game to people,
including magazine reviewers and potential publishing partners.
You want your packaging to look clean and professional. Put some
effort into making a nice disk label and printed manual.
Virtually all games, shareware and retail, have web pages. Some
authors start their web pages before the game is finished, and
provide blow-by-blow progress reports as the game is developed. Some
authors are better at making web pages than they are at making games.
Regardless, you should plan on having at least some kind of web page
for your game. It will serve as a marketing tool, as well as a place
to refer potential customers, team members, investors and publishers.
You will need to send out press releases and review copies. You
will need an attractive web banner to draw users to your site from
other sites. You may want to design advertising for magazines or
newsletters. Some authors even have brochures. Be clever, and do what
you can on a low budget.
So you probably thought all you needed to write a game was a fast
game engine that did a few tricks like z-buffering and flicker-free
scrolling, didn't you? Admit it, you did a few fast blits and you
thought you were well on your way to being a game developer. Well
study this list again. There is a long way to go between making a
game engine and making a game.
But don't get discouraged. You can do it. It may take you a little
longer than you expected, but your goal is achievable. Lots of other
people have done it, and you can do it too. And guess what? It gets
easier with practice. Many of the above elements are reuseable, as is
much of the code you write. That's why I recommend your first game be
something simple. Get a feel for what kind of effort it takes to put
the whole package together, and try not to get bogged down in any
single aspect of development.
After you write your first game, don't stop. It is already time to
get started on your second game. For some tips on that, consult Chapter 6.
This site created and maintained by
Copyright © 1997, 2000 Ted Gruber Software, Inc. All Rights Reserved.