I’ve been working on the multiplayer code to allow 2 people to update the board, and the mechanism is in place, the only 2 bugs left now should be sorted tonight or soon after!

After that, i just need to do some tidy-up, spend some time testing it, and add some sound and i think its ready

I don’t know when this will be, and i don’t claim to be an expert, but what i have so far works, and if i can keep it free of confusing additional elements, maybe it can help others.

The upshot of my latest efforts, as i suggested previously, is that i have a nice dual analogue joypad routine for AstroLiger

There’s more, but its dull, even to me.

Actually, I’ll probably abandon my timer when it proves to be as shit as I suspect, but I’ll forge along and try it in the game anyway because;

A. it actually does what I intended it to, and
B. the alternative in SDL_gfx is actually fairly straightforward to implement and I think its important to see why mine is a bad idea before abandoning it first.

Why do I think I did a bad job? Well, what I understand of timing is after all the game logic is called, you call the timer, this takes the framerate you desire, works out the fractions of a second this splits into then halts the loop till it hits the next interval this corresponds to.

Looking back, I guess that’s fine, people use this method for a reason and its not like games are a new technology that’s full of unproven concepts, but without a clear understanding of what it was all about, it seemed a waste of computing power. Instead, I came up with this fantastic idea where the computer just runs the game as fast as is possible, and only updates when that fractional timing trigger is fired. This I was sure was the winner and so I set off to implement it. And in fairness, it works exactly as I intended, except obviously its using awe inspiring quantities of cpu time.

I’m in the process of turning my prototype into a class which I can use, one of the nice things about it is that I’ll be able to have multiple timers with different framerates within the code without any real complexity, I’m not sure if there’s any benefit to that at all, its why I’m going to carry on and see what a real-world implementation does.

One thing it did teach me, which makes the whole exercise worthwhile, is how timing in C++ and game programming works, this more than any tutorial I could find was very useful.

These are important to games, but haven’t been show stoppers for Atoms, so I’ve been able to use work-arounds for the moment, but really, I’d rather just get them sorted and do it properly.  The Atoms codebase is too crowded for me to be introducing fairly major and completely new code concepts at this point, so I’m starting with a blank editor and beginning with line 1, why not make it the basis for the start of the AstroLiger project?

I’ve created a second googlecode project for my SVN repo, but nothing else just yet, I’d like to get something compiling before i setup a page for it here, but as with Atoms, it will be free and Open Source and cross-platform.

When i make progress, I’ll update here as usual.

A friend (Goldbuick,) advised enet, i’ll certainly take a look, but does anyone know of a really basic networking lib for C++ thats not going to bloat my game and make my head explode?  Good tutorials or examples would be a must.

Thanks

I spent some time last night looking at adding a user interface, i added a class for handling the front-end, developer splash and other user interface gubbins and the first thing i tried to implement was a straightforward pause mechanism.  Turns out i needed keyboard input code for that, and after a failed attempt at adding one as a new class, i realised i had to merge it into my mouse class and make a generic input object instead.  Seeing as I’d gotten a little better with C++ since i originally wrote the mouse input, i took the time to rewrite the whole class and make it more consistent, all i need to do for it now is add joypad support for future projects, but I’ll do that when the time comes.

After adding the new control code, i got the pause mechanism working, this pleased me, and so i committed what i had to my codebase and went to bed.

I should point out if i haven’t already, I’m a firm believer that when working on something, you should commit it to your code repository as soon as you have it working, then, if you toss it up later, you can come back to it later, and not have to also re-write a bunch of other stuff you didn’t commit till you had to.

I’ve learned this the hard way, its not much fun.

Later tonight I’m going to do some more work on adding the mechanisms for a front-end and a splash screen, my goal is to get a functional menu system up and running.

I’ve updated the “Atoms” page in the links above; over the next few days, i hope to make a few more improvements around here, if you look to the right of the news, you’ll now see i’ve got my links sorted out!

Part 4 - “Oh my god.”

Sitting down to write this article I’m blown away by the passage of time since the last one.  October 7th, 2007 was the date and I’m slightly embarrassed because I left my last article at the point where I was to actually get on and make my game, or at least a prototype.  So much has changed since then, not least my opinion and attitude towards game programming.

Recently I’ve setup some web hosting, started a blog and have been updating on a fairly infrequent basis on the progression of my game.  I thought it would be a good idea to add the articles I’d written for the TIGS forum so I dug them out and dropped them into the editor and through the process of cleaning them up (markup changes only ,) read through them again.  I guess, looking back, the first thing I should say is “You told me so.” more specifically, I was wrong.  Coming from a programming background with reasonable complexity, I’d assumed learning the language would be the major obstacle to learning to make games.  Many of the guys on TIGS were quick to tell me I was being too ambitious and games were not as straight forward as I’d assumed and frankly I didn’t pay attention.

I think looking back on my efforts now, and the advice I’ve been given, I really have to say that conceptually, game programming is massively different from application programming, when starting out you really need to listen to people when they say “Start with a Tetris/Match 3/Puzzle game”,  They know what they’re talking about.  Its not even the scale of the project, which would surprise you even for a small game like that, but the fact is a more complex project will draw upon concepts and code reliance that will assume you have knowledge in areas you wont.  I’m sure the guys that have helped me on numerous occasions are frequently frustrated when explaining things to me, that they have to explain the explanations!

As you can probably already guess, I quickly abandoned my dream project, the RPG -though its not been scrapped! The reality was that I’d hit the wall, as discussed in Part 2, and because everything was so daunting, I’d lost the will to code.  So, I decided to remake a simple puzzle game from the days when I had an Amiga 500 which was a lot simpler.  Atoms 2008 was born.

Perhaps the most frustrating thing when starting out is that there is a lot of code and planning required to get the simplest of things to show on the screen, even a small puzzle game has elements such as asset loading and handling, control code, graphic code, sound code, game mechanics, collision detection (or boundary checking in my case,) menu systems and more.  Each sounds reasonable enough, but they’re certainly not just a few lines of code each!

Anyway, before this becomes a post on my progress with Atoms 2008, I’ll stop.  The post-mortem on that will go up shortly after I release it to the public, source code and all.  For people who found this article outside of my website, my blog is http://games.leighashton.com and my Atoms 2008 codebase is hosted on googlecode where anyone can grab a copy of the SVN at http://atoms2008.googlecode.com

For those who might look through my code, you’ll see there’s a long way to go, I tell my friends that its close to release, and in my mind it is, all I need is to add sound, multiple players, a win/lose mechanism and some menus, then there’s a load of testing, that’ll be fun! (not)

Choosing a puzzle game is infact very good advice, something I’d urge anyone reading this  to do if they haven’t decided yet, it allows you to ignore many parts of normal game mechanics such as scripted events, ai, collision detection and more while allowing you to make something that can resemble a game, people looking through my code may notice some liberal misuse of code as I haven’t wanted to actually tackle certain stuff yet.

I’ll leave it at that for this instalment, hopefully this should be the last one before I release Atoms 2008, and the next will be a post-mortem of that followed by an article discussing where I go from there.

Well, i’ve posted them here, and i’m going to start them up again, continuing the articles here and on the TIGS forums where they originally appeared.