Game Programming, The Journey: Part 2

October 08, 2012

The mighty Game Loop

Previous in the series:

Any game should have one, or at least say the experts on the matter. They also say that it's the place to start. But it's really not as simple as that.

A simple implementation of this loop would be as follows:


variable game_is_active of type boolean = True



while game_is_active do

    execute run_game

    execute refresh_display

end



exit

The run_game function is where the logic of the game is processed and the refresh_display function is where the graphical display is updated with the data from the game objects. This is the most broad representation of a game. and the catch is how you will implement each function.

But before anything

One always do a practice run on something else before a big project. So I think I'm going to have a go at a Sudoku clone before tackling the bit RTS project.

Complicating things

"This article by Koonsolo: Game Loop; give much more insight on the matter. He talks about the trade-ins of constant frame rate versus variable one. Also talks about the same issues related to the time allotted to game logic. Concluding with some advice on what to use for different game types."

The first computers were not able to do multitasking like now. This meant the Game Programmer had to devise a way to do many things (Logic, AI, Graphics, Sound), the quickest and still make the user feel enticed in the game-play.

On most of the games you have to consider the proper balance between Game Ticks and FPS. Hardware and Architectural limitations makes it impossible to have the same resource being used at all times by these two aspects of the game. If you devote to many CPU cycles to the processing of the game logic, you will have to compromise on the graphical display of said logic. And vice-verse, obviously.

With the advent of multiple cores to aid in computation, you now can add another degree of difficulty to this, already jam packed, equation: Threads!

With threads you are able to partition some of your number crunching in different loops. Those loops will talk, or synchronize, with each other via messages, locks or even semaphores. While giving a better way to compartmentalize your game it has the downside of complicating things in terms of bug hunting.

Another type of game architecture that has arisen with multiplayer is the server/client approach. The user communicates with a server, where other users are also connected and they all play together.

On online games, this also can mean that your game continues to progress, even if you are not logged in.

What is my present path?

Keeping in mind that I'm mostly interested in an RTS/Simulation game, I've decided that I've got enough experience to tackle Threads head on. This may prove to be a foolish decision, but as I'm just in the beginning, it feels like the proper path to take.

I'm inclined to have a sever/client architecture. The server will have all of the Logic and AI, while the client will display the game and convey the user commands to the server.

I will start my prototyping with the server side on a GUI application that will only display bare stats and unit info. Once I'm pleased with it, I'll pack it on a proper server "enclosure".

I'll detail my mental (as inside my head and not I am mental) model in the next iteration of these series.

Cheers,
Gus

Extracting the Juice Outta Life