So How Do You Make A Game? Part 1
Subtle difference from my previous post (which was more about how you get hired in the industry). I've had a few people ask just about how you make a game, period. Often at work. I jokingly reply, "Well, you start with 'int main()'," if they are programmers. (If you are not a programmer - well, the joke sucks anyway, so don't worry about it).

I wrote an article last year about Hackenslash - that provides a little bit of insight, but that's not really the focus. There are several books on the subject which can go into more detail than I can here. But here's some hints from how I started. If these are useful - cool. If not, well, like I said, there are books on the subject.

I had the same question when I was 12 years old - when computers were still envisioned as gigantic room-filling monstrosities, except for arcade games which were now appearing in pizza parlors and pretty much anywhere else you looked (including, of course, arcades). I heard someone tell me that their uncle wrote those games, and I was fascinated. I was hooked on Asteroids at the time (among other games), and I was trying to imagine how you informed the arcade machine what the player's ship was supposed to look like, or how it knew to fire a bullet when the player hit the fire button.

My first computer (received later that year) was a Sinclair ZX80, which cost us less than $200 I think. This little machine had NO power whatsoever. I think there were pocket calculators at the time with more memory. There wasn't much I could do, but I did learn to program in BASIC on it. And somehow fit certain tiny programs into 1K of RAM. A little while later - once my dad figured that it was more than a passing interest, we got one of the very first Commodore 64's off the assembly line. I think it cost about $600. We had it on preorder for two or three months, and I think I literally DREAMED about that machine while I waited for it to arrive.

With all of 64k to work with (well, 48k of RAM), and a fully-featured basic, I went nuts. I had a couple of books of programs you could type in directly - very few would fit in the Sinclair (I think I made a total of three work, by stripping out all the comments and simplifying the output). But from these books - Basic Computer Games and More Basic Computer Games, I learned how to program games. (Side note - I still proudly own both of these books.)

These games wouldn't even be recognized as such by many of today's gamers. You didn't use a gamepad to control anything. They were all turn-based games. There were no graphics, unless you count ASCII character art. They were usually more fun to program and modify (for me, anyway) than they were to actually play. But I loved them.

From these examples, I learned the fundamental parts of a computer game:

Game State: All data pertaining to the game and the objects within it. Example parts of a Game State would be the current arrangement of the game board, the player's health level and position, and who's turn it is.
Input: The player's means of communicating and changing the game state
Output: The computer's communication back to the player of the game state.
Game Logic: Everything that dictates how the Game State changes from turn to turn (or moment to moment). If the player pushes the "left" button, his character moves to the left by so much if it's not blocked by certain other objects. A monster colliding with the player's bullet explodes. And so forth.

I also learned a common way to structure computer games, which is still kinda-sorta how I do things now. You have an initialization section, and then you've got your game "Main Loop".

Sometimes (well, almost always for modern games) the main loop can be broken into two loops. The outer loop is where you get the main menu or other global options, and the offer (at the end) to play another game. The inner loop is the actual game-playing loop where the real game occurs. It collected the player's input, performed the game logic to update the game state, and then output the results. You'd get some variation by switching to an event-driven architecture, but that's the fundamental structure for any game, be it tic-tac-toe, Guitar Hero, Bejeweled, Pac-Man, or Grand Theft Auto.

Once I graduated from typing in and modifying other people's games, my next step was creating my own games - usually based loosely on a game that I played and enjoyed. All of those games were pretty simple back then, so it wasn't too hard to emulate my favorites from the arcades --- except trying to make them run fast enough on the C-64's limited processing power. To improve things a bit, I eventually learned to program in Assembly language so I could optimize the slowest parts of games (usually the graphics) so that they'd run faster.

When I finally went off to college and started receiving formal training for computer programming, I created games as my projects whenever I had the option. We had to create program that implemented a stack. I thought of the Towers of Hanoi puzzle (where you stack disks), and created that game using three stacks. For a binary search tree, I created a game where the computer tried to guess what animal you were thinking of by asking a series of yes / no questions (and receiving new questions from you when it failed). Yeah - these little programs I worked on were way more complex than I needed to pass the course, and they weren't exactly sexy, portfolio-building games either. But they made programming FUN for me, kept me in practice making games, and kept me thinking about different ways of representing a game state.

Labels: programming

- posted by The Rampant Coyote @ 10:52 PM (Permalink)