Asylum – Dev Diary 17
This week has involved some very complex routines. After last weeks problems with the save game routines I set out to resolve the issue as it would be very important going forward to be able to save the game and then reload it and continue where I was. This is very handy for testing as it’s means I can skip over certain parts of the game and continue where I was currently developing.
So, I downloaded an alternative ‘Save State’ routine from the Game Maker marketplace to try out. Initially everything looked promising but because the code was written in the older v1.4 GML certain aspects didn’t work. For one saving ds_grids failed because the code couldn’t work out the type of variable it was trying to save. For these aspects I had to split out the saving code for various types of objects (ds_grids, arrays and surfaces) and adjust them for v2 GML. Once that was sorted I created a trigger object that I can drop into the room wherever I like (and as many times as I like). When the player steps on to these triggers the game is saved.
This works perfectly and the game state loads OK as well, except for one aspect. At present a sneaky bug means that when the game is loaded the player immediately triggers the savepoint under his feet and that is presently messing up the inventory states. This will take more time than I have this week but it will be the number 1 thing to resolve next week.
And so I moved on to another key aspect of the game: the first locked room. I wanted to make sure I could develop the ‘use inventory object’ system and get it to trigger an item in the game world. It made sense that the first test of this would be a locked door. So, I set about making a key object and for the time being just placed it on the floor outside the locked room. This opened up a few new bugs for me to deal with. Firstly I discovered that when the player had more than 1 inventory item the interaction failed completely meaning that the player could not select any item in the inventory. A quick rewrite of the interaction code resolved the issues.
The next challenge was to have some way of showing that the player was about to use an item. I decided to opt for a simple solution of displaying a small representation of the object under the mouse cursor. Next was for the door (or other interaction items) to detect if the player was holding a usable object and to see if the object was one that can influence the door. Once those checks were in place I could then unlock the door and allow it to open. Another bug said hello. If the player investigates the door (showing the circle interaction icon) and then goes to the inventory to use the key the interaction icon didn’t update to recognise the correct item is selected. This was quite a simple fix. When the player selects an item to use I invalidate and destroy all interaction icons in the game; this allows the engine to recreate them and realises the usable object is being held.
As well as all this coding I’ve also made some headway in creating a few more decorative elements. As you should be able to see from the dark screenshot (normally the player would have the torch by now). I have a computer monitor, keyboard and mouse and telephone system on a reception desk along with an office swivel chair. What you can’t see in the picture is the pot plant next to the chairs.
Slowly and surely the environment is coming alive.
