Saturday, 1 August 2009

Chaos Caverns II - Dev Diary

Updated 21/08/2009

A couple of months ago there was a discussion on Retro Remakes relating to creating platform games. The discussion grew to the point that I got a bit carried away and added an early (very early in fact) version of the source code to Chaos Caverns, as well as writing some pseudo-code to demonstrate how simple it is to make a basic platform game.

The thing is that once I'd written the pseudo code I found myself wondering if it would actually work, and the only way to test this is to bloody well write it. And so, using my pseudo code as a template I wrote a basic platform game engine. It works too. In fact in some respects it works better than the code for the original Chaos Caverns.

So now I'm in a bit of a quandry as I'd already been planning an update of Chaos Caverns and was in the middle of fixing up the old code.

So on the one hand is the original Chaos Caverns, which has already been expanded to allow me to create a flip-screen arcade adventure in a similar style to Jet Set Willy and pretty much only needs the levels completing to make it into a completed game.

On the other is the new code sitting in the Testplatform2 folder. This isn't quite as complete as the other but has some important improvements:

1 - It has been upscaled to 640x480. This is double the resolution of the original and does look a lot nicer.

2 - I've written the new version using Object Oriented methodology, rather than the spaghetti code of the first one. It has taken longer trying to remove things like the level transitions from the old one than it has to write the new one from scratch. Also I've got the benefit of a couple of years experience compared to when I started writing Chaos Caverns.

3 - Even on the short test level I've created it feels rather nice to play.

4 - It should allow me to create a much better game, more in a 16bit retro style than the 8bit style of the first one.

Point 4 is the decider really. Even though I could knock out a quick game using the old code base I wouldn't be as happy with it as I think I could be with the new game engine. So I'm re-implementing the functions that are still missing, which is a slightly frustrating exercise, but the new features (such as animated tiles, and each tile being available in multiple states) already there makes up for this.

So here we are at the birth of what I'm currently calling "Chaos Caverns II".

I'll be updating this post with the development diary as time goes on, so stay tuned!


Level switching code has been added to the game, so now I can start building the game proper. I've put together three screens as a test and it all works rather well. At this point it is starting to feel a bit more like a proper game.

Next step: Items and enemies.


Summer time isn't the most productive time for programming, but have managed to track down and fix some bugs, including an extremely annoying one which caused the player to fall through the floor, but only when existing the screen to the left. Exiting from the right worked fine. Finally managed to fix it by re-arranging the movement code to make sure that the move down / platform checking code ran before the left / right movement and exit code.

I've also spent some time tidying the code up a tad, and starting to add in the code for the enemies.

I'm dealing with the enemies in a different way to how I did in Chaos Caverns. This time all the enemies from all the levels are read into a single array when the game initialises - rather than refreshing the list at each level change. This allows me to "kill" enemies and for them to stay "dead" between screen changes.

I'll be dealing with objects in the same way. Some objects will allow you to destroy enemies, so for example, collecting a pin will allow you to destroy the giant beach balls. More on that later...

To make the game feel a bit more like a game and less like a demo I've added a place-holder title screen.

OK, so that's a long way from brilliant, but at least it makes testing the game a whole lot easier in that once you've lost all your lives you return to the title screen rather than just quitting or jumping straight back to the first screen.

I've also added a music track for the title screen - again this will probably change before the game is finished - but for now I'm using Mozart's Rondo Alla Turca (thank God for classical music in the public domain).

As a side note - if any budding musicians are reading this and feel like donating a music track or two then please get in touch.

As of midnight I've got a moving enemy on screen (at last!) and can move onto the enemy collision detection routines tomorrow. *yawn*


Oh no, Thursday the Thirteenth!

I'm not superstitious about the number thirteen, but today hasn't been a great day, work-wise.

At lunchtime we lost access to the internet, email, our advertising system AND our page transmission system - while we were half-way through transmitting a newspaper that had a 1pm deadline. It was down for a couple of hours due to an alleged power-cut in Oxford.

So we had three hours of dealing with complaints about something that we've got no control over.


Follow that up with me being on call, and getting called back in twice (although as luck would have it I was able to deal with both calls remotely).

On the bright side I've got collisions with the first (and currently only) enemy in the game working. So that's nice.


Motivation is often an issue when writing software for yourself. When things get tricky, I try and add "one feature a day". This at least gives some impression of the game developing rather than just lurking there waiting for me to complete it.

OK, so sometimes you miss a day - but today's feature is one that makes the game a bit more tricky - and that is allowing the player to die if they fall from too great a height. Not a difficult thing to add but something that I had deliberately left out of the original Chaos Caverns.

This time, however, if the level designs that I have in mind are going to work then this is a feature that I need - otherwise there won't really be any challenge.

Features remaining to be added (and this isn't a full list):

  • Collectible items
  • Killer items
  • Special items
  • Lifts
  • Conveyor belts

Other things to do:

  • Add more levels
  • Add more enemies
  • Add more graphics and sounds
  • Write a proper front-end to the game
  • Add an end sequence
I'll be expanding this list as time goes on. But so far, so good.


Today's new feature: Lifts. In getting the lifts working I've had a think about how I'm coding the game, and more importantly, how to reduce the amount of routines that I need whilst achieving the features that I require.

The lifts are a case in point. I'd considered making a new game object for the lifts, but then realised the obvious: "a lift is just a platform that moves." So by adding some new parameters to the platform object and creating a "move" method I've got a basic lift working with very little new code required.

I've still got to code the interactions between the player and the moving platform (ie. if the platform is moving left or right then the player's movement follows it). Easy for left to right, slightly more complex for up and down. Especially when I need to find a way of slowing down the lifts a bit as by default they are a bit nippier than I'd like.

I was also going to add another object for "traps" - basically killer objects. Thinking about it what is a killer object? In the terms of this game it is an enemy that doesn't move, so if I just use the existing enemy routines with a static enemy then job done!


Still working on the lifts. As they were running a bit faster than I'd like I've added in some code to create a delay between each move - so the lift will only move every x number of frames. This works well and allows me to have fast and slow lifts as required.

Moving and jumping whilst on the lift works but... sometimes whilst jumping you fall through the lift, and I can't see why. Ah well, tracking down and squashing bugs is all part of the fun.

I've also been re-jigging the player movement code a bit so it should be a wee bit more optimised, as well as a bit smaller. For those interested, at present on a P4 2.8ghz the game uses around 4% of the CPU time.

Update: Bug fixed, so the lifts are now fully working (vertically at least). I've adapted the second screen so that it can only be traversed by using the lift - and it all seems to work nicely so far.


Now that the lifts are working it is time to start expanding on the code to make this less of a demo and more of a game. With that in mind I've started adding a fairly basic score / level / lives display at the bottom of the screen.

The strange thing is that this revealed another bug: if you dropped from a height into water you'd lose two lives instead of just one.

After one hell of a lot of hunting through the code I finally realised that I was forgetting to reset the fall height, so when the water code killed you the fall counter still contained a value, and because you re-spawned on a platform it treated it as if you'd landed after a long fall, which kills you a second time.

An easy one to fix, but a bugger to track down.


Today I've been expanding the code a touch (extra baddie movement types, horizontally moving platforms and some other bits).

I've also put together a short video showing the game in action. Not a lot to see so far, but you can get the general idea of the progress so far.

Tomorrow I'm planning to add the code for collectible objects into the game. Once this has been done then the game engine will be basically complete and it will be time to start adding enemies and designing some proper levels.


Found and eliminated another bug - one that allowed you to pass through a solid block if you hit it precisely on the top corner whilst falling.

I've amended the second screen to add in a horizontally moving platform - which worked first time without problems. Mind you, once you've got the code working for the vertical lifts there really isn't a lot you need to change to get it working for horizontal ones.

I've also posted about this game on the Retro Remakes forum - so a big hello to anyone visiting from there.

Update: Collectible items are now working. Quite simple to add really, providing you remember to use methods rather than functions for your reading / drawing code. Why? Because functions can't access an objects fields (the variables that the object uses). This is a "it's too late at night for this shit" type bug.


Today has been mainly spent "enjoying" a bout of either man-flu or hayfever. Either one gives the same result - my IQ has dropped so far that it now has a negative value, my nose and eyes are taking it in turns to drip, different parts of me are competing in the "most painful" competition (I think that my back is winning so far). Not surprisingly I've not been especially productive on the old programming front.

That said, I've started expanding the baddie routines a bit, so the beach-ball enemy now rotates as it bounces (which looks cool), I've added a balloon as another enemy, which is also semi-transparent. This also looks pretty cool in action.

I've also started tidying up some of the routines, and simplifying the code in a couple of places.

Continued in Part 2


Anonymous said...


Have you considered making some kind of generic engine (as standalone program) which could be used to creating simple old school platform games like jest set willy, manic miner etc.

Such project would need some kind of scripting language (lua maybe? javascript?) and editor i think.

Something like DizzyAge ( but for platform games

DanO said...

With the original Chaos Caverns (available at I'd set it up so that custom levels could (relatively) easily be created.

All the levels were stored in editable text files, with an accompanying file describing how it all fitted together.

There didn't appear to be much interest in it (probably because it involved manually altering text files rather than using a proper editor).

That said, once the new game engine is finished it should be possible to adapt it into something more generic. It is certainly something I can think about once the main game is "feature complete."