flipcode - Building A Game On Your Own http://www.flipcode.com/archives/Building_A_Game_On_Your_Own.

shtml

See what's going on with flipcode!

Building A Game On Your Own Return to The Archives

by Nate Miller (20 June 2002)

Introduction
Over the course of the past three months I have been working on a little game called
Lunar Lander 3D. My main reason for embarking on this project was to gain some
knowledge about what it takes to create a game. Other than that, I just wanted
something to distract me from school. Although my game is simple and small in scope,
the process of creating it has given me a great deal of useful knowledge. In this article, I
am going to go over some of the important things that I learned while creating my game.

Before I get into the meat of the article, I want to point out that I am by no means a
professional. I am just another goon with a keyboard. This article is meant for hobbyist
programmers who would like to create a game on their own time. The main emphasis
throughout this article will be on finishing the game you are working on, not making a
flashy technology-bloated half-game. And when I say finish, I don't mean working on a
game for a long period of time only to ditch it because a shiny piece of metal caught your
attention.

Your ideas are not sacred

If you ever want to finish a game, you need to realize this. No matter how much you
think of yourself and the ideas that you have come up with, you will need to toss most of
them out. When I started working on my game I had a mountain of ideas that I wanted to
use. I wanted to have moving platforms and hazards in my worlds, a complex camera
system and a number of other things. But I knew that if I ever wanted to finish my game,
I would have to ditch most of the ideas I had. It is important to remember that when you
are working alone, you can't come up with a project that would take a professional team
a year or more to make. While a year or so may be OK for a professional team, it is a bad
idea for a hobbyist programmer. Try to tailor your ideas so that you can work on your
game for a period of, for example, six months or less and you will be much better off.

Don't start from scratch

If you don't have a base of code to work off of, you shouldn't be writing a game in the

1 of 3 4/21/2014 9:20 PM
flipcode - Building A Game On Your Own http://www.flipcode.com/archives/Building_A_Game_On_Your_Own.shtml

first place. It is that simple. This may sound harsh, but let's take a closer look at the
situation. If you don't have a set of code that you use consistently, you probably haven't
been programming for all that long. If you haven't been programming that long, jumping
into a game is the last thing you want to do. When I started working on my game I had a
large base of code to work off of. I had code for general window creation, input
management, particles, math and various pieces of utility code. With all of this code
ready to be used, I was able to immediately begin working on things that were related to
my game. Additionally, I didn't have to test this code since I had tested it when I
originally wrote it. You don't have to write every piece of code you will ever need before
you start your game. Just take some time to lay a groundwork that you can build off of. If
you feel that you need to build up a code base, write small applications to test things out
before you start your game. I did this with my particle, input management and command
execution code. It may not be as exciting as a game, but it will definitely help you in the
long run.

Borrow ideas
I can't even begin to stress how important this section is, so let me say it again. This
section is important. When you are writing a game, don't be afraid to use other people's
ideas, libraries or utilities. Borrow as much as you can, it will do nothing but make your
life easier. In my game, I remembered Conor Stokes' soft hands and used his article on
axis aligned bounding box trees, I used Paul Nettle's collision detection document and I
used id Software's Q3Radiant level editor. Why did I use other people's ideas and tools to
solve problems that I could have solved on my own? The answer to this question is
simple: I used all of these different resources because it saved me time. By using an
established method for collision detection, I didn't have to waste my time coming up with
and testing my own collision method. By adapting id's map editor to my own devious
purposes, I avoided having to come up with my own. And, as an added bonus, id's map
editor lit levels for me, which is yet another thing I didn't have to deal with. Don't get
caught up in the belief that you need to have custom tools and solutions for your game. If
you are smart, you will know when to come up with new ideas and when to use
well-established ones.

Avoid the tar pits

What in the world are the tar pits? The tar pits are the so-called 3D and terrain engines
that everyone loves to work on. If you are working on an engine in order to create a
game, you will be like a mammoth stuck in the tar. No matter how much you try, you
aren't going to be going anywhere. The experience of working on a game has made it
clear to me that an engine is not needed when writing a game on your own. Remember,
you are a single person writing a game, not a company writing a family of games. You
don't need an engine to reuse over and over. While a good reason to write an engine is
code re-use, this can easily be obtained without an engine. With a reasonable design you
will be able to reuse parts from your game in other projects. For example, of all the new
code I wrote for my game that is not game specific, I can reuse 100% of it in other
projects. This is pretty good considering I never had this in mind as a goal. Writing an
engine to gain knowledge from the engine itself and the design process behind it is fine,
but you should avoid it if you are trying to create a game.

Don't get cute with graphics

When you are working on your game, don't bother adding graphic features that don't
make your game better. You know that cool extension on the GeForce20 that you want to
use? Don't use it. You know how you want per-pixel lit, bump mapped, texture animated,
per-pixel depth shaded magic snails in your game? You don't need them. If you define
your game by the extensions and eye candy in it, you probably don't have much of a

2 of 3 4/21/2014 9:20 PM
flipcode - Building A Game On Your Own http://www.flipcode.com/archives/Building_A_Game_On_Your_Own.shtml

game. What you have is a technology demo. The most complex graphics feature that I
use in my game is multitexture, but you don't even need it to run the game. I know that
I'm not id Software, so I have no business requiring insane hardware to play my simple
game. If you keep things simple, you will not only broaden your audience, but you will
also be able to focus on more important things in your game, like gameplay.

Conclusion
Well, I hope some of what I have said makes sense. It makes sense to me, but who knows
what other people will think of it. If you have any questions or comments, feel free to
e-mail me at nathanm@uci.edu and I will try to get back to you as soon as I can.

If you are interested in my game, you can visit the Lunar Lander 3D page and download
it.

Nate Miller

Copyright 1999-2008 (C) FLIPCODE.COM and/or the original content author(s). All rights reserved.
Please read our Terms, Conditions, and Privacy information.

3 of 3 4/21/2014 9:20 PM