Ice Slider update
Something snapped in my mind halfway through the week and my previous programming hot streak has run cold. The code just doesn't seem to flow as well as it did. Consequently I'm only a bit further on from where I was at time of last post.

I've temporarily pruned down the visual look of the previous screenshot to something a bit more functional - I've made the ground a bit more "tile-like" and put some grid lines in. I plan to revert to something more closely resembling the screenshot below once I've got the game up and running. There's a few approaches I can take but I'd need to have the player avatar moving around before I can see which work.

Other than that - I've added depth tests into the graphics pipeline. Previously I relied on rendering everything in the proper order, but that may not work with the player character. However I don't know if just relying on the depth mask will work - it may end up with visual artifacting around the alpha blended edges. If that's the case I'll have to hack in the rendering of the player within the loop that renders the game world.

Concerns about engine architecture
I'm a bit worried that the architecture is getting a bit scrappy. I started off using a hybridation of superpig's Enginuity architecture and my usual "C with classes" approach. The program flow tends to trickle from master classes (such as the "World" class) through function calls down to leaf classes.

However I'm relying more on message passing as a means to communicate between classes. Now instead of calling a "draw" function as part of the update process I send a draw message from the graphics module to objects that need to display info to the screen. I'm also strongly thinking of merging the message passing system with the kernel itself, since all the kernel need to do is send "update" messages to whatever objects want them.

The problem with this is twofold: firstly I'm still experimenting with message passing and as such a lot of my code is very hacky. Secondly since I started off with a different architecture paradigm it's a bit of a mess in places. I'm thinking of doing a clean up after I've got the game working, but sometimes I can't help myself fixing some of the more annoying mistakes.

I'm also a bit concerned I'm too reliant on singletons, but that might be because of the anti-singleton sentiment I read in some of the forums. I'm not going to fix that until after the game is operational, but given I'm moving towards message passing I might be able to do away with some of the singletons I've presently got.

Project Crystal: the next game project?
When I hit a programming block I often start daydreaming about new game ideas - one of the prime reasons I kept scrapping my earlier projects! This time I'm set on finishing Ice Slider but I've been wondering about what project I'll do after this one as I'd like to hit the ground running. The problem isn't so much coming up with a fun game idea - got plenty of those - but figuring out which one is the best fit with my present skills.

Although most of my ideas including Ice Slider plays heavily on the cutesy graphics style I like to draw I wanted to move away from that for one game before I get stuck into a larger cartoony game. My front runner was to resurrect the old shmup game I was making codenamed "Project Nova" that got distracted when I made Pierre and the Fish.

However after enjoying HopeDagger's excellent Membrane Massacre, I wished to see if I could convert Project Nova into a multidirectional shooter game. After a bit of brainstorming and some grafting of some ideas from other games and research projects I've now come up with what I think is a mighty fine idea for my next game - so much so that I've given it a new codename ("Project Crystal") and created the project directory structure to put design documents and preliminary sketches in.

I won't post any more details yet as it's still very preliminary - however I will be spending a bit more time fleshing out the idea while I work on Ice Slider. Hopefully once I've got Ice Slider and a solid game engine finished around the end of January (that's my present estimate) I can start work on Project Crystal.

Revision Control
I've been reading the recent threads on source revision control, and I'm starting to think I should get my act together and start using it myself. My present backup routine consists of keeping everything worth saving off a single directory marked "Projects" and just copying the whole thing to CDs or my USB hard drive. Anything that involves more effort than that I find I tend to avoid doing.

But now I've got a lot of major changes I'd like to make to my code base I think it might be worth using some form of revision control as a method of being able to wind back changes (other than digging up last weeks CD backup archive).

Does anyone have any suggestions for a relatively painless method of revision control suitable for a hobby developer? I'd preferably want something that uses a standard method of archiving that's transferable to other programs if I find it isn't suitable, and if it could be integrated into the Code::Blocks IDE that would be a bonus. Anything that takes too much of an effort to set up and maintain would probably end up being left idle in a month or so. I've used CVS before so I know the basics of how to run it - I just dislike the admin side of things (I always forget how to do the setup and how to create new entries in the repository), so something easy to use would be ideal.

Any pointers would be useful.

In other news...
I heard from my family in Melbourne that my brother managed to successfully get his Wii console through the post (he pre-ordered it a while back from an online games retailer that we both like to buy game related mechandise). On Thursday (the day it was supposed to arrive) he only got the controllers, so I guess he spent a day glumly waving them at his Xbox. On Friday the Wii arrived, but he had to fly out to Sydney shortly after picking it up so unfortunately he hasn't had much of a chance to try it out. My sister though reports it's a heck of a lot of fun. I'll be heading back to Melbourne over the Christmas-New Year stretch, so I'll have a chance to see if the Wii is as good as they say first hand. Given I'm a big fan of Nintendo's games I'm destined to buy one eventually - it's just a question of when.

That's all for now. Except that I've also managed to get the beginnings of a tune working that sounds appropriately piratey for Stompy's BlockyMan game. With a bit more work I think it'll work well.