As mentioned in my last post, I’ve been quietly working on a remake of an absolute classic C64 game – Boulderdash. Before I go into what’s been involved in remaking this with Game Maker Studio 2, it’s worth you firing up an emulator – Vice is perfect – and playing the game itself. You’ll learn a lot more about it than I could ever explain here – and it’ll be fun too.

Boulderdash came out around 1984 and was probably one of the most addictive games I ever played. It wasn’t very easy – certainly not for me – and I never got that far into it. The playability of the game, however, was damn-near perfect.

In execution the game was simple enough. Use your extremely well animated main character, Rockford, to move through scrolling maps, collecting gems, avoiding falling objects and sometimes participating in little puzzles built from the game object. These usually consisted of manipulating rocks into magic walls to turn them into gems, and destroying fireflies while converting butterflies into gems, while avoiding them killing you.

There were only 20 caves in the game – four of them being intermission levels that came up every 5th map, but the design of these caves were merciless. A great example was the punishing third cave, which required very careful movement to not block yourself in, and you needed to collect every gem on the map or you couldn’t exit. Not to mention probably my favourite level, eleven, appropriately named Greed. Here the opportunity to collect gems en-mass was so tempting that you mostly ended up either trapping yourself, or getting killed, just because you had already picked up more than enough gems to complete the level, but you just had to push your luck.

A wonderful game and it didn’t take Aaron much effort to persuade me to at least have a crack at doing a remake of it. The idea at the start being to learn about using tiles while our #ParadroidRemake was on hold. More on that at a later date but we will be finishing it soon.

So, in my last post, I did mention that I was mostly there. I was probably around half done at that point, as I’d finally got the main background processing working correctly, which translates to objects all moving correctly based on circumstances around them, such as gravity, and where they are. It’s harder than it sounds – trust me.

Where am I at now?

I can be a bit of a perfectionist with game development, and there’s always the tough decision on deciding just when you actually are done that I struggle with. Luckily I’m not quite at the point where I need to start thinking about that with Boulderdash just yet. I’m currently well into the last 10%, and any game developer will tell you that it’s 90% of the work to get that bit done. This is definitely true for this game so let me go over what I’ve actually done so far.

Firstly, the background engine that’s driving the game is all in and working lovely. I converted all the images for the original game into 16 * 16 tiles, put in a screen resolution of 320 * 216 to match a C64 and then put the window for the maps into a width of 640 * 368. This is consistent across each game screen as the smaller levels use steel squares that are unbreakable to stop Rockford going into places he shouldn’t. From the start of the game I opted to use every moving part as a tile, rather than use sprites, which has been good for some parts but, right near the end of development, caused more than a few problems developing the AI on Fireflies and Butterflies. More on that later on as well.

Cave 1 was then created using an image of the original as an overlay so I could replicate the original design into my own level. After this I got the code in place to put Rockford on the level and move him around so that scrolling and other stuff could be implemented. I did toy with the idea of pixel scrolling as per the original game, but I found it a bit slow, so left it as blocks to make the game pace feel appropriate. I’m still in two-minds as to revisiting that and changing it again.

Now I had Rockford in place so I turned to one of what ended up being the hardest parts of development so far, which was putting in the gems and rocks processing. It was a fantastic feeling when I finally was happy with that, as it took over a month, and I had all sorts of curious bugs along the way. The way the game now works is mostly on a script system which are all executed via the main processing loop that is already handling stuff like variable game speed based on the skill level selection.

I read some great tutorials about using a state machine which seemed to be the best idea of doing Boulderdash, because there’s a lot of the game background stuff that is always happening, regardless of what the player is up to. For example, the rocks and gems carry on doing what they’re doing when Rockford dies and the game is waiting for you to press fire to restart map. So I’ve used different scripts to parse the map for each game object just so different behaviour can be adjusted for each one. As an example the rock and gem movement patterns are almost exactly the same, so once the rocks were working correctly, I could just copy the script and change the identification macro to implement them as well, and just modify their behaviour when they hit a magic wall, compared to how rocks reacted.

Technical types here are probably now mumbling to themselves about processing power and how this isn’t really an optimised way to do it. You’re right, and originally I did have the gigantic wall of code that attempted to do everything. A great wall bigger than China’s, filled with if / else conditions that was both a nightmare to read and format, and more trouble than it was worth. Especially as I never had it working 100% anyway. So, after breaking it all up into seperate object scripts and testing, it didn’t make the slightest difference to the game speed, even though i’m technically reading through the entire map at currently six times each frame.

What people tend to forget when writing games is that modern machines can handle so much more than people realise. Game Maker Studio 2 – which some developers probably wouldn’t even take seriously – can do a shed load more than what I’m currently asking of it. Games throw infinite amounts of polygons, data, textures and processing than my little Boulderdash remake. And this is based on a C64 game which ran in around 54k of machine code on a computer built in 1982, which it was designed specifically for. If I tried to process the game loop on an actual C64, where I run through the map 6 times on each frame, then I’d be running out of scanlines at the very least, I’m sure. But this kind of thing is just something we don’t have to think about any more and I’ve struggled before accepting that, so maybe this is my way of finally getting on-board.

What I will say is that I’ve got four difficulty levels built into my game, as it stands, and even the hardcore mode doesn’t let it run at the fastest speed it can, because it would be almost impossible to play. The way the game has been written is so much easier to debug now as a result of being looser with the code. Before I would compare debugging that great wall of code to actually getting a toothbrush and going to China to clean the real thing.

So, I digress. Rockford was finally now digging his way through the map, rocks falling when they should and gems were being collected. That’s almost the whole gameplay built in at that point, if I had the enemies in as well, but none of them feature in the first cave so I worked on the exiting level conditions, putting in systems to handle the scoring, extra lives and some kind of display of the game information for the player.

I took a bit of creative licence with the game timer and made it configurable at this point. Although most of the levels don’t really get that affected by the timer in the original game, I’ve always felt you could play it two different ways – if the facility was there to make it optional. Strategy players that just want to get through all the levels and don’t like being rushed into making mistakes can turn it off. And the guys who like it a bit more challenging can leave it in and then race through the levels as quick as they dare, because they know that there is a timer bonus applied every time they hit the exit, if it’s switched on.

By this point I had put a basic front-end on the game as I had the level selection and timer toggle as flags already so wanted to get them built in the game with some other options, such as cave selection. At present I let the player choose any of the 20 caves to start in but I will probably flip that to make it run like the original game, where you can start after each intermission screen instead. So Cave A, F, K and P will likely be the only selectable ones. I did mention that K (number 11) was my favourite, so I’m glad that makes the cut.

After this it was time to put the rest of the caves in. This was another couple of days of work and I’m still finding little bugs of the data-entered-incorrect variety even now, in play testing. I’m pretty sure they are mostly debugged now, however.

Entering and exiting levels has been implemented now, which really was the final part to do to actually have it as a working game, even though I did have my hidden level skip cheats to use until that point. This is probably the main area I still need to do some more work on, as I’m hoping to emulate the scrolling, random tile cycling effect that the original did for transitions between caves.

Next up was the smaller bits which I had listed as I worked, such as high score recording, the animation of Rockford, such as the delightful animation he does when you don’t move for more than five seconds, and other little bits in the background.

I went to the title sequence then to start trying to improve my coder art as well as emulate the scrolling background characters that the original had behind the logo. This took a lot longer than expected due to trying so many different background graphics. I’ve also got it in my head to switch the tiles of the logo out to rocks and collapse them all when the game starts – another reason why I kept the rocks processing script separate. I’m still unhappy with the whole title screen look as it stands so this is another part of that last 10% which needs addressing. I don’t have a credits or instructions screen in yet, which were always on the cards to put into the game at the original design plan I had.

Another major part was then approached and I spent a creative afternoon playing with BFXR coming up with some suitable sound effects within the game. I’m a bit unsure about some of these, as is Aaron, so I may have to revisit here when I do the final polish on the game. I did have an mp3 of the original theme tune but with no author details so I’ve opted to use a little alternative tune instead, which does have author permission to use elsewhere – just in case.

So, after all that, what do I realistically still have to do? I’ve mentioned some of it but there’s still further work to be done to get to a state where I’m happy to put the game out there.

Enemy AI:

I have the butterflies moving by looking at information researched on the internet. They are not working correctly, though, and tend to cheat a bit, so I’ve got more work to do there. The Fireflies movement is almost the same, so it will be a copy of this code with some small changes to have them running too.

Magic wall:

This is used in a few of the maps – especially the level 20 intermission screen – where you have a puzzle based on one of these. A magic wall basically converts rocks into gems and vice versa, so there’s strategy involved in using them. Especially when they only activate for a short time. I have the walls in place on all the maps but no code yet to get them working.

Amoeba:

These are also only present in a few levels and are the pulsing green goo that expands to a certain point and then converts into rocks. The gameplay element of this was that fireflies or butterflies touching it would turn into diamonds, so the level had to be opened up enough by Rockford so that the enemies could reach it. That way he could get enough diamonds to complete the level. I still have this to code into the game.

Start/End level sequence:

At present game just jumps between levels instantly. As I mentioned before, I need some kind of decent transition between caves, which I need to implement with the state machine in the game.

Credits/Instructions screens:

I’ll be putting these into the game near the end as I’ve got some friends testing the game, and I also don’t know if I’ll change anything regarding the AI, so don’t want to write an instructions screen until the gameplay is all finalised. It will probably be good to wind down with these tasks as the last bit of the game before final polish.

It doesn’t seem like a lot’s left to be done but remember what I said about the last 10%. I’m not putting a timetable on this but progress is steady so I’m optimistic I can give it away pretty soon.

Categorised as: Boulderdash | Development | Game Studio 2