Having commented back in December 2022 that I was about to start updating one of my old games, Drop Rock, and a few days later about the first changes I made as part of that process… I have completely failed to write further on the topic, even though more changes have been made.
The second post did send me down a different direction, in that I decided to write a little bit about Escape from Exeria, the first game I released, and a more general post about them all. I didn’t finish either of those posts, but very recently realised that because of Exeria’s history, a better time to put up something about it would be next year.
This post, therefore, is a long overdue update to the work I’m doing on Drop Rock, covering what I’ve done in the twenty months (!) since the last one. There are a few things to cover, so I’ll keep them fairly brief for this catch up.
In those early posts, I explained that the map (the area on which play takes place) was eighteen tiles (individual game graphics) across, by twelve deep, and that the size of those individual tiles was 32×32 pixels. I updated the game to run at a 1920×1080 pixel screen resolution, with a tweak that allowed the existing game to play in the middle of the screen. And all of that was in a 256 colour screen.
The plan for the new version was to expand the map size and/or the tile size to allow bigger and better graphics, though I only got as far as discussing possibilities – if I made the tiles this size, the maps could be that size, and so on. I hadn’t made a final decision.
I went on to choose a tile size of 40×40 pixels, and a map size of 40 tiles horizontally by 24 vertically – and without redesigning the graphics at this stage, adapted the game code to cope (but still using the existing graphics).
In order to test the updated game code, I needed some playable screens – and although they didn’t use all of the expanded space, I had forty screens already in the old version of the game, so I wrote a quick program that read the old level data and rebuilt it at the new size, putting the level as was in the middle of the new play area, and filling in the missing space above, below, left, and right of that with wall tiles. Having done that, a typical screen looked like this:
As that screen grab shows, some of the layout leaves a lot to be desired – there’s some extra empty space at the top and right of the screen, the title and level number texts aren’t particularly well positioned, nor is the Drop Rock title graphic, and the same goes for the score and lives in the section at the bottom. The empty space is because it was still using the old graphics at this point – i.e. 32×32 pixels per tile, instead of the intended 40×40 – and the poor positioning of the text/graphics is simply because I didn’t put any thought into their positions; I just moved them so they weren’t plotted over the top of the map.
Layout issues aside, though, the important thing was that I had the game working at the new size.
Well, sort of – the nature of the old maps meant I was still really testing the same real play area, not the expanded one. To test that, I’d need level maps that used the whole area – so my next job was to create a larger level map. This was the result:
I did have to make a few tweaks to the code because I’d failed to update the program in all of the places it was necessary (rocks beyond a certain height weren’t falling, for example) – but that didn’t take long, and the result was that I had a version of the game working with bigger maps, in a higher resolution!
The next task was to think about the new graphics, so I set about designing those. I haven’t completed that task, but I did reach the point of designing enough (that I consider to be first draft versions) to update the game again to make use of them. With those new graphics in place, the game’s appearance changed to this:
Things to note here are:
- The border tile is a temporary one.
- The ‘orange balls’ replace the scrolls of old.
- The side graphic is gone, and there is currently just empty space there.
- The title and other texts are now positioned better along the top and bottom of the screen.
- There’s now a level passcode.
With the border, the code expects to plot a number of tiles to create one – but that’s a set of tiles I forgot to create along with the rest, so I produced that simple grey square very quickly at the last minute and altered the program to use that.
The reason for the orange balls instead of scrolls is that this game is going to be a sequel to Drop Rock, so needs a new story line. I’ve decided what that story is going to be, though haven’t formally written it yet – and within that story (and at the stage I’d reached with that screen grab) they are power spheres. (Spoiler: They’ve since become power cubes!)
I haven’t yet decided what to do about the side graphic. I am thinking about moving the score, lives, and passcode there from the bottom of the screen, possibly along with some other useful information, depending what other changes I make – and that may well be positioned within a new side graphic.
There’s now a level passcode! I decided on that approach while designing a second (and third) map. The old game could be played from the start (level 1) or the highest level the player had reached thus far – but now, provided the passcodes are noted down, it’s possible to play from any level that has been reached.
This version was shown off at the RISC OS Wakefield Show in April 2023, and the RISC OS Southwest Show in February 2024 – with almost no changes between those two dates, and (until recently) nothing since.
As well as the new background story, I had ideas for additional challenges that the player could face. On some levels in the old game, for example, there are up to three monsters to contend with, which I’ve variously referred to as spirits or sprites. These were going to be called energy entities at the stage I’d reached with the map above – though they do now have a new name. As something from the old game the code for those already exists – but I felt there needed to be new monsters as well. I’ve designed some draft graphics for the first of these, but code will need to be written to support them.
With the next RISC OS show fast approaching, I realised I needed to get on with the game and try to further it a bit. With that in mind, I started working on the second draft graphics, and I decided to change the way I draw the walls. The new design will reduce the number of wall tiles but (I hope) simultaneously make them look more varied, albeit subtly – but it also means I’ll need to make supporting changes to the code.
At this stage, I realised that the changes I’m going to have to make to the old version are becoming more and more significant, with changes to one part of the code now affecting other parts, and other parts again.
I realised I had three options:
- Carry on as I was, updating the old code – with the ever growing scope of the changes making this an ever greater effort. The code is likely to get messy (messier!), and bugs will be introduced that I’d have to track down and deal with.
- Rewrite it from scratch using the old code where possible. This would be more effort than #1, but would allow me to plan ahead as I’m writing to put in hooks for the new features. In addition, given that I haven’t written a game of this kind from scratch in around thirty years, this would probably help refresh my mind about how to do it (in a way that just altering existing code wouldn’t).
- Even more effort again would be rewriting it in a different language – C – using the old code as a guide. I normally use C these days, so doing this has merit for that reason alone, and I mentioned that it’s around thirty years since I last wrote a game from scratch. That was Floopy (1993), which I wrote in C. I also have another game planned, to be called Catacombs of the Unforgiven, and I’ve said from the outset that I want to write that in C. So, despite the effort, using C would be beneficial to that.
Faced with that dilemma, I chose to set aside some time to experiment before deciding which direction I would go in.
About a week ago, that time came, and I wrote some quick and dirty C code to do some of the early necessities in a game – loading graphics files and plotting individual sprites, and so on, and the result was to decide that I am going down the C route.
So the new version of Drop Rock is being rewritten from scratch in C.
I’ve since tidied up some of the test code (and written a fair bit more) and formalised it into the beginnings of a library (i.e. so that I can use it for other games – such as Catacombs of the Unforgiven). Sadly, this is something I didn’t do with the original games back in the late 1980s/first half of the 1990s; each game was pretty much written from scratch without reference to the previous games, with no code re-use at all.
There’s still quite a way to go before I have a playable game now that I’m rewriting it from scratch, but at the same time I’m progressing faster than I expected, and I’m pleased with the results so far. On top of which I’m confident that because I’m attacking this in a sensible way (i.e. building a re-usable library), when Drop Rock is out of the way I may be able to get other old games updated/rewritten – and new ones developed – much faster than before.
And that kind of brings things up to date when it comes to the Drop Rock work. The next important date is the RISC OS London Show, towards the end of October. Given that’s just two months away, and allowing for the time I can spare, it’s doubtful that I’ll have a playable version by then – but as I said, progress is better than I expected, so who knows?
Part 4 will probably appear some time after the show (if I don’t forget), and bring things up to that point.