Game Programming, The Journey: Part 2

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


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.



Game Programming, The Journey: Part 1

Previous in the series: A new long term challenge: Game Programming

When ever I've started a new endeavour I always do some heavy research.

If only for future reference, I'll leave some links to Wikis, Tutorials and other important stuff regarding game programming.

For beginners and up:

Since I'm mostly interested in RTS/Simulation type of games, here are some more specific to the subject:

More specifically for Real Time Strategy:

(I will be updating both these lists as I progress on my reading.)

Feelings after some reading

Coming from a database centric type of programming, once you begin to look at the vast field that is "Game Programming", you can feel pretty overwhelmed!

The subjects are from all the ranges of the Computer Science subjects and you even add some nice two/three dimensional math!

My past track on research for a new thing to do, has to be put aside and rethought. "One cannot simply enter the realm of Game Programming!", as someone would say. It's something that you have to take in with the understanding that it's going to require more than a few week-ends of reading and prototyping to get any good at.

So, in my case, this is going to be a slow rise of knowledge with loads of reading involved. Coding will have to be postponed to a time when I'll feel comfortable enough with the terminology, concepts and lingo, to finally begin to drop some code.



A new long term challenge: Game Programmer

I've been pondering on the possibility of doing a game for quite a while. Nothing solid or earth moving came out of it, but it's been on the back burner for a while.

I've been playing 2 games lately:

The Settlers Online
The Settlers Online
Forge of Empires
Forge of Empires

Both are of the type RTS (Real Time Strategy) games. The type of game that really interests me. And this is the path I'm going to take on my journey towards a fully playable game.

I've started to do some work on a concept I read about somewhere (I'll update this with a link when I find the article). This concept was about having a system that you could just throw hardware at it to scale, with out the shortcomings of current solutions.

I called it Kullonia.

I really didn't code much of it and I'm quite ashamed of it, since I've let a very dear friend down in the process. I hyped him up with a really good sales pitch and then just didn't deliver. Until this day I'm still pretty ashamed of my actions and don't even try and re-establish contact. Deep inside I know he hates me :(

Probably it was this guilt that made me pursue my current objective. The concept is really great to implement the engine behind the games shown above. And the fact that it's coded in Free Pascal makes it a double whammy of awesome: It's compiled and can be made to suit multiple platforms.

So for the next few postings I'll be ranting about the journey of starting a "One Man Team" Game Programming.

See you in the near future.



CEO Companion Application

So I've been playing this little game: The Settlers Online - Castle Empire

It's a game of patience and it won't appeal to all the strategy genre lovers, but it's a dream come through to me. I've been hooked on the "The Settlers" saga for quite a long time, ever since I've had a go at the very first one, in the 90's. So when I stumbled upon this on the Chrome App Shop, I couldn't resist!!

But just playing the game wasn't enough. I had to give something back, to both the people that made the game and the ones that have the same love for it as me. So I decided to create a companion application with some content and the ever useful calculators for the various in-game strategies.

So "CEO Companion" was born!

The application is open source and is still in the early development stage.

You can find,
  • the project page: here.
  • the download page: here.
  • the bug report page: here.

Give it a go and tell me what you think on the comments below.



'Twas my birthday yesterday...

So, it was my birthday yesterday... No biggy... Well, apart from the Smashingly Delish cake my wife made:

Delish cake by my baking wonder of a wife!!

Well, got that out of my chest :)