Games coding

A friend, whom I usually consider well educated in IT, came with a rather unexpected comment the other day. "I would like to know how to write games." What, any programmer can do that - albeit, there are many genres of games and therefore the required arts will depend greatly on the type of game you wish to create. However, if you're looking for a place to begin, here's the basic skeleton:

while(game_is_running){
controls();
physics();
render();
sync();
}

Each of the looped stages above will be greatly different from game to game. From the beginning of time, I can no recall any game that is not a combination of object oriented and map oriented - that is, the method you use to keep track of each element in your game is picked for CPU efficiency. You want to use the least amount of processing power possible.

Typically, the user and aliens are considered objects, though environment may be a map or object oriented. Controls() include receiving user input to manipulate the user object as well as any artificial intelligence you may need for computer generated players. In MUDs (broad sense), this may also include receiving updated data about another player.

Physics() should theoretically be the same in every game, except it's not. Is it a 2D or 3D game? Do we need gravity? Do we need gravity between objects? Object collition detection? Does anyone die? Is there acceleration going on, or are things moving at linear speed?

Render() should really be the same for every game of the same kind. In a 3D world, the world should render the same way at all times. It is common to create a rendering engine that is reused in every game from the same company. Except, of course, the technology changes and the rendering engine must follow suit. And when technology doesn't change, the programmer may still find things to do in a more clever way.

Sync() is possibly the simplest stage: The three previous stages will take different amounts of CPU time for every frame of the game. In order to get a smooth game, one must wait until the next "tick" of the clock - whether it is every 50th of a second, 30th, 20th or 15th of a second. Or even every second.

Within each of the stages above, the details become a science of its own. It's not tough, though, you just need to break it down to bit sized chunks.