Xerra's Blog

Drunken coder ramblings

Boulderdash update —

I spent a long weekend in Devon visiting Aaron over the last few days where we brain-stormed and decided to have a look at what could be done with the enemy AI in Boulderdash. At present Envahi is progressing steadily so we didn’t really look at that at all as I don’t really need any help with it at present.

One of the longest problems I’ve had with the original game is that it’s been built from scratch to work from tiles. Normally this would be no issue at all but I went the route of making every object a tile without having any kind of information about them which has caused problems from the off when trying to make some kind of working movement pattern when I don’t know where the tile I’m looking at has been previously.

Originally I tried to clone the system documented that showed how the original game worked and I got round the problem of not knowing which way the current tile was moving by changing the tile image number without actually changing the image so it wasn’t noticeable on the screen. Thus, a tile number could be TILE_BUTTERFLY_RIGHT or TILE_BUTTERFLY_LEFT for example, and that way I would know which way I should be looking to move it when I got to it on the next pass.

This wasn’t really working very well as I’ve documented on several previous blog posts so I would work on it a bit and then get frustrated and switch to working on another part of the game until I had another idea. The revelation on how to mostly fix it came recently when I realised that I had super-fast moving enemies in the right and down directions because I was parsing the whole tile map one tile at a time during each frame. For some reason I hadn’t considered that if I moved a tile to the right or down then it would actually then get processed again in the same loop until it couldn’t move in that direction any further. A daft mistake that Aaron kindly spotted. Fixing that by skipping the next tile whenever I moved one right mostly fixed that issue but bodging a skip to move past the next line on the tilemap to fix the down direction wasn’t really the answer so the problem wasn’t really fixed to a satisfactory solution.

Next step led to attempting to use an array system for the enemies that move in the game but this caused issues of it’s own when trying to keep track of everything. So Aaron reminded me for probably the 10th time now that maybe I could switch the game to using objects instead. I’ve written this idea off before out of both being stubborn and also with a feeling of dread because it would mostly mean rewriting the entire core of the game. As you can imagine it’s a huge weight to have a game that close to being complete and only to find that maybe the only way to get it working properly is to implement a major change this late in the day.

I’m pretty sure there are people coding with GMS that can, and do, use Tiles and objects for all their games anyway and could do this pretty quickly but I’m still relatively new to the system so I knew it would take me a lot longer.

Anyway, Aaron and I pulled on our thinking caps over a few hours during my visit and set to work on starting a new build of the game from scratch using the same graphics but weeding out the duped stuff and just writing the core parts of the game from scratch. These being the moving elements such as rocks, diamonds and Rockford himself, using objects and then removing the tiles from screen afterwards. This would work by using the same system of reading the tilemaps that I already have built and then deleting the tiles on the layer once an equivalent object was put in place. We then also put in the default values for all of the objects as the original game did, such as the rounded flag which tells wether that object can have other objects rolling off it. Classic example of that is a rock itself. This was all done using the new setup variables that you can now add into object classes.

We ran out of time before we could actually get to working on the enemies themselves but the diamonds and rocks now work on our revised base game and it’s my job to now strip out all the workable stuff in my project and put into the game while removing all the tile code so I can try and code the AI once again using an object system that remembers where it’s going now, just for starters.

Hopefully this will mean I can finally close that bit off once the rewrite is done. Not to mention have a lot less scripts to work with as a lot of it will be code that goes into the objects themselves.

I’ll update how I get on with that next time. Hopefully it won’t take too long and will let me leave the project in a good state to return to properly as soon as I finish Envahi.

 

 


Categorised as: Boulderdash | Development | Game Studio 2



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.