how to make a computer game

Introduction
OK, you’ve been daydreaming about making computer games haven’t you? You just don’t know where to start though. Am I right? Well here is your jumping off point.

This short document was written to give people who are interested in making computer games a place to start. It’s intended for people who don’t really know anything about game development or the game industry but want to learn about what is involved in making games. It’s also intended to be a high level road map for making a game if that is your desire.

You’ll find introductory information here about design, programming, artwork, audio and networking. You will NOT find any information about how to independently publish a game. I’ve chosen not to include that even though, if your intent is to distribute or sell games on your own, it is probably the single biggest problem you’ll face.

For programmers, there are no program code examples here. Part of what makes programming fun is writing the code. That’s why programmers do what they do. They enjoy finding a way to write code to solve a problem. As such, I am going to do you the generous favor of presenting you with a bunch of problems and no solutions. (-:

So let’s get started.

The Commandments
The first thing you need to learn are the two commandments of game making:

1: Thou shalt finish the friggin thing
You must finish a game in order for it to be a success. That means it must have a beginning, middle and end, like a story. The simplest example I can think of would be a minimal “Bounce” game. This game is boring and lame in the extreme, but if you did all these things, it would be FINISHED! And that is very important. Here is the game design for it.

Beginning
A screen that comes up saying, “Welcome to bounce”.

Middle
a dot that moves toward the bottom of the screen, bounces off of a paddle that moves horizontally under your control. If you miss it, you lose. Each time it bounces off the ceiling, you get a point.

End
when you drop the ball and loose, your score is displayed with a message saying, “Game Over. Press any button to play again”.

.That was tough.

2: Thou shalt make it fun
In order for something to reasonably be called a “game”, it has to be fun. That doesn’t mean that it has to be WILDLY fun, or the funnest game ever invented. But it does need to have at least the tiniest detectable amount of fun. The Bounce game described above would qualify. Barely. It might be engaging for about 15 seconds, but that’s enough. If there is absolutely no detectable entertainment value whatsoever, or worse … “detectable unpleasantness”, then it’s not fun. Otherwise, you’re OK.

These two commandments are crucial if you are serious about making games. If anything in your game gets in the way of achieving either of them, exterminate it with extreme prejudice.

Print out these commandments and staple them to the wall near your computer screen.

Design
Create a design document
The design document is something you write up to help clarify in your mind what it is you want to do. It’s much more important to have it if you will have multiple people working on your game.

Keep it short. DO NOT make this document highly detailed. It will be wasted effort. The game will change dramatically as you create it. You will find some things are impossible for technical reasons. You’ll find that other people have ideas that you like and want to incorporate. You’ll find that some stuff just isn’t fun.

The design document should take between 15 minutes and 1 day to write depending on the scale of the project you want to do.

Keep it simple. Consider that every “neat idea” you have, when written down in the form of “one sentence” could be equivalent to 3 weeks of hard, fulltime labor. Shoot for a design that seems ludicrously simple, and shallow if you’re just starting out. Shoot for something that just seems simple and shallow if you’re experienced.

Choose a programming language and operating system
Decide what operating system you want your game to run on (which will typically also be the one on which you program the game) and what programming language you want to use.

Obviously, there are zillions of options for both, but let me suggest getting the Java SDK from java.sun.com and creating an Applet game (runs in a browser). There is an SDK for windows, Linux, and many other operating systems. The code will be portable enough to run in any well-known browser on any operating system.

Also, Java is a good language to learn with. It’s well designed and consistent. It won’t give you maximum performance, but you don’t need that starting out. If you are beginning programmer, it will steer you towards good habits at the outset. Eventually, if you need greater performance, you’ll move on to C/C++.

Game states or “screens”
All games will have at least a few different “states” that they are in at any given time. They are sometimes referred to as “screens”. For example, the “title screen” is the state in which the game is showing the title of the game and probably prompting you to “press any key to start”, or something like that.

Describe the various states your game can be in and how you the player can move from one to the other.

Menus
All games will have at least a main menu. You should have at least “Play” and “Exit” items in your main menu.

Some other selections might include “Settings”, “Help”, “About” and “Difficulty”.

Each of these menu items, when selected will send you to a different game state. Your game design document should describe the various menus that your game has, what items are in each one, and where they take you, or what they do.

Game Play
Describe the game “mechanics”. That is, how the game is actually played.

If it’s a board game or card game or puzzle game, explain the rules, the legal moves, etc. (don’t get too involved here unless you are creating a game where the rules are already known, like chess. If you’re making up the rules, you’ll spend a LOT of time later finding out that what seemed like neat rules are not fun to play and changing it all around).

If you are making a game where most of the action involves running around and killing things, describe how the player can move, what he can do, what sorts of things he can kill, where he can go, etc.

Is your game an adventure with a story? Outline the story and the basic sequence of events. Don’t go into a lot of detail, it’s not necessary at the outset. If you can’t resist, write a book and sell it as fiction.

Game Over / Victory
When a player loses, there should be a “game over” screen. When they win, there should be a “victory” screen. You would probably want to make a much more elaborate victory screen than game over screen, possibly with all sorts of cool animation and special effects.

Controls
Explain the various keyboard, game controller or mouse functions. Explain how the player interacts with things on the display. Is he a little animated badger? Explain the things you can make him do.

Multiplayer issues
Multiplayer games have a lot of issues that single-player games do not. If you want to make a multiplayer game, plan on it being at LEAST twice as hard, and taking twice as long to create. If you’re starting out, figure 3 or 4 times. I don’t suggest doing this until you’ve got a lot of games under your belt.

Actual issues are discussed below.

Programming
This section is for the programmer of your game and assumes he or she knows generally how to program a computer.

All games work generally the same. The most common difference between a game and any other type of program is that a game is usually always running flat out. It’s doing stuff, even if you are not. It is usually computing the positions of objects and moving things around, animating graphics etc, even if you are just sitting there. Games also tend to have a lot of code dedicated to drawing graphics. 3D games also have a lot of code dedicated to manipulating the objects in the 3d world in order to make them appear to move in 3 dimensions.

Here is how the code is normally arranged.

Init
Load up all the graphics and sounds up front if you can. Keep it simple. Don’t try to recover from errors or struggle on. If something isn’t where you expect it to be or can’t be found, just exit.

You will invariably have code that opens a display of some sort. On a computer, this is often a window, or the full screen.

Audio systems are set up.

If it is a multiplayer game, you will likely open connections to other computers such as a game server or a matching server.

Loop
The main loop is where all the real work is done. This is where the game spends most of it’s time. In truth, there may be several loops depending on which state the game is in, but we’re basically taking about the loop where the game is actually played here.

Render
This is the actual drawing onto the screen or window of what the user sees. For example, if it’s a flight simulator, you might draw a blue sky, then draw some airplanes in the distance, then draw a graphic representing the cockpit and canopy, and then draw some gauges on top of that.

You draw the display by starting with the things in back first, and then working up to the closest items.

Tick
This is where all of the objects in your game world “think”, “move” and “react” to stuff.

Let’s say you’re making the bounce game described in the introduction. You might internally have an object representing the wall, one representing the paddle, and one representing the ball.

When you “tick” the ball, it would advance it’s position on the screen (without actually drawing .. that happens above). After moving, you would check to see if the new position is one that overlaps the wall (collision detection) and if so, reflect the direction of travel so that it will move away from the wall the next time through the loop. You might also fire off a sound effect at precisely this instant.

If the object animates, you would probably advance an index number here so that a slightly different image gets rendered each time through the loop.

User Input
After you’ve “ticked” everything you would then check for user-input events. In this section, you would watch for any button clicks, keystrokes, mouse movements, etc., that you’re interested in taking the appropriate action when they occur. For example, if the operating system says that a mouse movement has occurred, you might want to move the position of the paddle in your bounce game.

Sleep
After doing all the work for one pass through the main loop, you should attempt to calculate how much time has elapsed from the top of the loop to here. You have to throttle the rate at which you go around this loop or everything will move too fast. So pick a “frame rate” (the number of loops per second). For example, a good frame rate is anywhere from 10 to 30 frames (loops) per second. If you get through all the work for one loop early (which should be the case most all of the time), then calculate the remaining time and put yourself to sleep until it’s time for the next loop.

Done
When the user wants to exit the game, your code will fall out of the main loop somehow. When that happens, you’re supposed to clean up. Free up all the memory you allocated. Close up all the resources you accessed, etc. Personally, I find that is a big waste of time in most cases. Read the documentation for the platform you are developing for and the resources you are using. If it says that you ABSOLUTELY MUST free up something gracefully or bad things will happen, do it. If not, then just exit. Most operating systems will clean up most stuff for you like allocated memory, opened windows, opened sound devices, etc.

Structures and Objects
I suggest making a very simple array of structures to represent the objects in your game world. You can organize the data that makes up your world any way you like of course, but experience has shown me that a flat, simple array always works best.

Also, don’t be afraid to impose limitations on things. For example, a fixed size array is fine. You could use a linked list scheme to hold your objects so that there is “no limit” to how many there are, but trust me, this will only take longer, introduce complexity, it will not help you, and it will probably hurt you down the line. If you don’t believe me, then go ahead and do it your way. If you continue to make games, you’ll eventually understand.

Don’t create big hierarchies unless you really need to. In general, keeping your data simple, and “flat” works better. This is lbecause a game is a creative process in many ways, and that means that you’ll be experimenting a lot. Trying different things out to see what is fun and what isn’t. If you build up a big, carefully arranged hierarchy of objects or data, you’ll just have to rip it all apart and build it up again repeatedly. Do yourself a favor and keep it simple.

Don’t worry about your code being all “perfect” and everything. Games are, to a certain degree meant to be disposable. The whole idea is to create something new and different every time. That’s why game “engines” tend not to work well. When you make a new game, you want to make a NEW game. You’re trying to do something new and different. This is not conducive to code re-use. There is a lot of stuff that you can re-use and you should put care into that stuff, but a large hunk of your game will be written once and then thrown away. That part can be as ugly as you like.

Art
In the old days, the artwork and programming was done by the same guy. The technology is so much better now that good artwork is pretty important, and almost always beyond the abilities of the programmer. I am unique, I have a lot of experience in both but that will probably not be the case for you.

Sprites
The term “sprite” is usually used to describe any sort of bitmap or image that moves around independently from the background. Sprites in a 2D game are usually just a bitmap which has a transparent color so that the image can have irregular edges.

When creating sprites, it’s almost always a good idea to have the edges of the image fade to black or “toward” black. A dark or black edge will pretty much look right against any background. Also, the mind and eye naturally expect things that curve away to become darker as less light reflects directly into the eye. Lastly, a black edge helps to really clarify the edges of an object which can be very important in distinguishing objects form one another when they’re moving around. It’s not a hard and fast rule, but is almost never a bad thing.

Backgrounds
Backgrounds are the most distant imagery. Often times a single big image that covers the whole screen is used as a background.

Some games use a “tiling” system where the background is composed of a bunch of smaller rectangular bitmaps that are drawn in such a way that they appear to form a large, continuous image. This is done when you want to make a big, huge world that scrolls around behind your sprites. You usually need some special tools to create tiled backgrounds.

Animation
Sprites will usually animate. For example, if you have a game character that runs back and forth across a platform, then the character will need to have a “running” animation. The artwork for this would be in the form of a series of bitmaps that are flipped through rapidly to create the illusion of movement, just like an animated film.

There are also things like buttons for user interfaces which will normally require different images based on the state of the button. For example, a normal image, a “roll over” image that is displayed when the mouse touches it, and a “pressed” image that is displayed when the button is actually clicked.

Real time 3D
Real time 3D games are pretty standard today. They are usually higher budget and take longer to create. There are a lot of differences in doing a RT3D game, but much of the preceding information still applies. I’ll try to describe some of the differences here.

Programming is different
The game world is different in a 3D game. All of the data representing the objects and the world itself describe sizes and positions in 3 dimensional space instead of just 2D coordinates. Moving objects around in such a world is not a lot different than 2D, but there is a lot of other special programming required to render the display because it is usually from a first-person point of view. That requires a lot of special rotating and transforming of the data to create the illusion.

RT3D also tends to be a lot more cpu intensive. Specialized code is necessary to make the world appear correctly and run fast enough such as back-face culling and z-buffers.

On the plus side, there are lots of special 3D game engines which are designed all of this easier. Back on the downside again though, they usually require a license fee for use.

RT3D games are not for the faint of heart. I don’t suggest getting into them until you have gotten a few games under your belt and have become familiar with the basics of making a good game.

Creating artwork is different
Artwork for real time 3D games is very different. As an artist, you will spend a lot of time “modeling” 3D objects in a special tool for that purpose. The object would be made up of a bunch of flat rectangles or triangles which are attached in such a way as to make a mesh in the desired shape.

You then create 2D bitmaps that are applied to the triangles as “textures” to create the effect of a solid, 3D object.

The artwork would be supplied to the programmer in the form of special data files that include both the model and the textures. The programmer might then move the objects or parts of it programmatically when the game runs.

Audio
The audio in a game is generally made up of “sound effects” and “music”. Sound effects are sounds which are usually tied to some sort of event. Such an event might be when the ball hits the wall in the Bounce game. When that happens, a sound effect like “boing!” would be played and heard. Music, on the other hand, is just a long looping sound track that plays continuously in the background and is meant to establish a mood.

The audio for a game will not require nearly as much time and effort as the programming and artwork. As such, it is often not started until the game is largely done or at least well into development. However, I can’t stress enough how important audio is.

A game with good sound effects and music will be VASTLY superior to one with bad or no audio. Because it is a comparatively smaller investment of time and effort, but has such a huge impact on the feel of the game, it’s crucial that you have good audio.

Multiplayer
Multiplayer games are those in which 2 or more humans are playing, either with or against each other. The players usually interact across some sort of network connection, most commonly the Internet.

Multiplayer games, like RT3D games represent yet another order of magnitude of complexity. If a single player, 2D game takes 3 months to create, a single player 3D game might take 6. Add multiplayer to it, and it could be 9.

Types of multiplayer games
Turn based
A turn based game is a game where a player has to wait until the other player is finished moving or providing input before he can do the same. The players “take turns”. Examples would be board games and card games. In the multiplayer game world, turn based games are the least likely to have problems with cheating and have the fewest annoying, thorny problems associated with them.

Real time
Real times games would be games in which all the players are seen to be in a single game world, and are all acting independently at the same time and interacting in real time. Examples would be role-playing games such as Ultima Online and Everquest, or real time strategy games such as Real War. These games are the most difficult multiplayer games to implement. They suffer from cheating, lag and synchronization issues. These things are problematic because the games attempt to create the illusion of a single game world which is in a continuous state of flux. The nature of the Internet makes it very difficult to keep all of the players’ computers synchronized and up to date across such very short time intervals.

Sockets
Computers communicate with one another across a network using “sockets”. Sockets are like the ends of a piece of pipe or hose. To communicate with another computer, your computer opens a “socket” which establishes a pipe between the two machines. Your computer can then talk into one end of the pipe and the message will come out of the other end at the remote machine. The remote machine can talk back in the same way and at the same time.

Client/Server
Most network communications use the client/server model. A server is simply a computer which is “waiting” to receive a new socket connection from another computer. The client is simply the computer doing the connecting. Some games are designed as client/server games. In these games, a single, central computer is in control of and drives the game world, and the clients are really just terminals which allow the user to interact with that world remotely.

 

Oh thanks for this wonderful guide on Runescape....

 

copy and paste much? no way in hell you spend 4 hours typing it

 

Yay. Now I know how to make Runescape.

Except... it's more of a common sense guide rather than a technical, scripting guide.

 

Leel nice guide , but maybe change the first few sentences , i thought you were talking about a private server of some kind

 

nice guide mate another easy to use computer game maker is RPG maker xp

 

yes that also true

 

if any one needs help makin one pm me

 

HMMMH any even tryin to make game?

 

i guess not.. =/

 

Oh thanks for this wonderful guide