Become a Computer Game Developer: Writing your first game








Chapter 5






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 important.


Necessary Elements of a Game





Title
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.


Title Screen
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.


Credits
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.


Intro
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.


Control Panel
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.


User Interface
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
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.


Mouse Cursor
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.


Art
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 page.



Storyline
Not all games need a storyline. Usually
adventure games and action games have storylines. But even a puzzle
game can benefit from a good storyline. Consider 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 .


Playability
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.



Levels
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
demos.


Utilities
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 need.


Demo Mode
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 their inclusion.


God Mode
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.


Exit Screens
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.


Documentation
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 documentation.


Copyright
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.


Setup Program
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.




Shareware Considerations
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.

READ.ME
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.


File description

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.



License Agreement

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.



Vendor Instructions

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.


Order Form
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".


Registration Incentives

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.


Time limits
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.


Packaging
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.


Web Page
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.


Other Marketing

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.











.
Diana rants... .
.
Are You A Genius?
Click Here




Home Page | Contents
Chapter 1 | Chapter 2 | Chapter 3 | Chapter 4
Chapter 5 | Chapter 6 | Chapter 7 | Chapter 8
Glossary | Author | Books | Links Discussion




This site created and maintained by Diana Gruber .
Graphics designed by Susan
Kelleghan .

Copyright © 1997 Ted Gruber Software, Inc.
All Rights Reserved.