Asylum – Dev Diary 18 – Bug Bash

Sneaky little bugs that appear out of nowhere and cause endless problems. The bane of the developer.

This week I concentrated on fixing a few of the issues that had arisen over the last couple of weeks.

First up was the Load Save issue whereby, it appeared, that when the game continues from a save point it would load and save at the exact same time and corrupt the inventory. It actually turns out this wasn’t the case. However, to be on the safe side I decided to adjust the save triggers so that the player would not start immediately in a collision state when the game was loaded. The actual reason for the inventory getting corrupted was due to some out-dated code in the SaveLoad system I got from the GameMaker marketplace. Because it was using GML v1.4 and not the newer 2.0 the functions for reading in an array (like the inventory) wasn’t detecting the value type correctly. What happen was that the routine checks the save value to see if it is a number and if it is store it as such. This all sounds correct but the function in v2 actually returns the number zero if the value included nothing but letters and therefore stores the string as a number instead. This made sense as when the game was loaded the inventory name was displaying as 0. So, I recoded the way arrays are handled so that they are always assumed to be a string and then once loaded convert the ones I know are integers (or real values). And hey-presto the game now loads and saves correctly.

The second aspect I wanted to change with the save game was the way I was handling destroyed objects. These are objects that have been removed from the game during the play session, such as collectibles and trigger points, previously I created an array with 500 slots that would make up what I believed enough spaces for all the destroyed objects the game could contain. But, I didn’t like this idea as it would mean saving and loading 500 elements every time even at the start of the game. So, I reworked it to use a dynamic array that starts with zero elements and increases each time a new object needs to be stored.

This was also true with the more problematic object state saving. It’s not something you ever think about when playing this sort of game but any object that can be displayed in different states such as doors (is it locked? Is it open? What angle is it open at?) all need to be stored and recalled when the game is continued from a save point. And in the case of Asylum there is likely to be a lot. My first attempt at this last week was not successful and resulted in way too many values being stored. So, this was reworked to also use a dynamic array and a delimited string that would store the objects instance id (such as the door), its angle, its locked state and its actual state (closed or open). On loading the game I could bring in the array and update all the objects on the players current floor (level).

Last week as part of the save system I also introduced a temporary main menu and a function to let me switch to windowed mode (useful when debugging). A few updates were needed to ensure the game stayed in windowed mode between displays (which it did not previously do); and also to save those settings so the game could start automatically in full screen or window mode. Of course this is currently just for my benefit.

The biggest and most annoying bug this week was trying to get the camera to start in the correct place when a new game begins. Previously the camera would start miles off to the left and pan across as the player started – not ideal. It took way too long to work out what was going on and I won’t go into the technical details here as they’re equally annoying. At the end it turned out that the oCamera object was overriding the actual viewports position regardless of what I set it to, and I just couldn’t see it. Once I’d finally realised the issue I just had to set the position of oCamera to the correct x,y coordinates as the level started.

With those bugs out of the way I should be able to get back to building the rest of the floor now. I know of one more potential item I want to address and that is the line of sight to a pickup object. At the moment there isn’t any and that means that if an object is close enough to the player but on the other side of a wall he can still pick it up – opps.