Time for another update as I’ve mostly slacked since Xmas but have still been beavering away at Boulderdash to try and get it finished. Suspect I’ve taken longer to work on my version than the original game was coded now but I’ve added elements to the project so that’s my excuse for being at the almost-finished line for at least two months now.

Since the last update I’ve put in a couple of the key systems which I’d been dreading due to the way I’d set up my game state system. I’ve gone on about this before but Boulderdash is the first time I’ve ever tried to code a game using this method and I don’t think I’ve done it as well as I could have. Coding is all about working on something, getting it going and then making it better the next time you do it, so I’ll definitely be doing that.

As it currently stands – and I won’t change it for the game as is now or I’ll never get it completed – Boulderdash is built on a huge amount of seperate files. I’m using GameMaker 2 so this is by no means unusual, but I think I’ve taken it to extremes with how I’ve put the project together. I’ll elaborate to make it easier to get an idea of what I mean here.

Firstly I have four main objects in the project. There’s a few others for incidental things, like the stars animating over the title screen and things like that but the main objects are the Game Handler, Title Handler, Game Hud Handler and the Title Hud Handler.

The huds are self explanatory and are used to draw text elements over the screens for both rooms. Both the title screen and the game levels make extensive use of tiles. All the gameplay elements, for example, are tiles, hence the blocky nature of the game and why I’ve not actually put in pixel scrolling as yet. And possibly actually won’t because it’s not working right with how the game works and feels way too slow. Anyway, I digress. Where text elements are needed to be drawn on these screens of tiles, I’m using the gui layer and I’ve found it’s easy for me to have all the text printing stuff in the handler and just have conditions to dictate what elements are drawn and when.

In the title hud handler, as an example, all the code is in the step event to display the high score, score and stuff like “press fire to start”, level, selected map and so on. Naturally it’s not all displayed at once but the code is all in that one big step event for anything and everything that could ever need to be drawn. Like cheat mode active for example. I’ll have a keypress event in the title handler object to process the level has incremented and the step event in the title hud handler already has the code to take that info from it and display the correct level accordingly.

As it’s an object handling all this background text stuff I just have to drag it onto the title screen to have it working.

There’s an argument here that says I could be using the step event in the title handler and setting up the gui overlay within there but I haven’t done that here because I’ve always done it the other way but I can already see that it’s probably easier to use one object so cross-referencing isn’t required. Or even have a global hud that draws all the game text data regardless of wether it’s used on the title room or game room.

The game hud handler does the same thing obviously and all elements of the game are run from the game handler itself. So, due to the game being made up of caves, I decided early on , after a little advice from Aaron, to create a different room for each cave, rather than have the game handler do the cave creation stuff itself. So Boulderdash currently has 20 rooms for the game levels, a room for the title screen and an empty room that’s never seen but runs at the start to create all globals and set up loading/save data and all that other stuff nobody ever thinks about.

I’ve just had to drag the game handler object and the game hud handler object onto each of these rooms as I’ve built the levels with tiles based on the map layouts of the original game. Again, this shows another area where possibly I could have made things easier with one global hud handler object but, even if I’d done that, I would still have had to drag both objects into each room.

The problem I’ve developed – if I can call it a problem – is that I’ve had the idea in the back of my head from when I started that I should seperate as many elements as possible of the gameplay and put in scripts for each one outside of the handlers to make it easy to work with the problem elements. For a game with multiple different enemies and objects (walls, Amoeba , rocks, gems , borders etc) this made sense but as i’ve built more and more into the game, it’s become a few objects and something like 30 scripts – most of which are to do with tiles processing. I did originally try to write one big object handling script which was a disaster, so it’s easy to see how it got this way, but the temptation to throw it all back into one now the elements work seperately is very tempting. It does put me in very good stead if I ever followed this game up with a sequel. The original Boulderdash has had loads over the years. I could literally just pull out the scripting and build a whole new game around these learning from mistakes made this time and incorporate the construction set element that Boulderdash on the C64 finally got in the fourth game. I could do it now but opted not to as I have used seperate rooms for the maps for this game.

I possibly got off track with what I was originally waffling about but to me it does seem that there’s valuable lessons to be learnt at every stage of game development rather than assuming most mistakes would be spotted early. I could go back through the project now and redo the whole thing massively optimising it with my new-found knowledge but it would take me just as long to recreate it much tighter. Nobody would notice any difference either as the game would run at the same speed regardless. And I’d probably break half the stuff that does now work by trying to do it.

Aaron had a similar situation when he was building the decks for our Parardroid remake. Once the work was all done and working well, he had a revelation on how it could be improved in the project to make it much easier to work with but the code was already there and working anyway. So why reinvent the wheel? Just hold the thought for when you maybe make the sequel.

So Boulderdash now has the transition from title screen to starting the first level working. I’ve got to put in the scrolling/tile warping thing that the original did still but I’ve mentioned before how I wanted to change the logo into rocks then drop them off screen when the game is started and that’s what’s now been implemented. Again, it’s knowing where to stop when doing stuff like this. You can keep adding fun stuff forever but in the back of your mind there’s always more important stuff to get done before you should be playing with those bit. Like getting the AI right, in my case.

Ending a level does the bonus countdown now, which can be skipped with fire if it’s a bit slow for people. It’s now more obvious that having the timer on is going to make a nice score boost for the people who want to get better highscores. I put in code to save the config settings and high score / last score now too. Just for those guys.

What I’m looking at now to call this thing done is still the AI fixing, magic walls, Amoeba and the credits page, which I’ve already got drawn ready to slice onto the screen, once I think of how I’m going to do it. Mustn’t forget the level loading in tile/scroll system. Apart from the AI, that’s the bit I’m hating working on the most as it’s not come together yet.

So version 0.23 – as I have it at present – builds, plays and feels almost like a complete game now. If it wasn’t going to have enemies in it then I could throw it out there now and move onto the next game but it’s never that easy.

As I said last update – almost there…

Categorised as: Boulderdash | Development | Game Studio 2