Asylum Dev Diary 80

This weekend saw a slightly shorter development cycle because I needed a bit of a rest from the previous full week of development.

However, several improvements have been made.

The water in the basement has been improved so that it isn’t so blue. It’s a more natural hue now.

One development bug that has been annoying me from the start has been resolved. As mentioned in Day 77 GameMaker will alter sprite index numbers as and when it likes as more and more sprites are added to the game. This meant that as I was testing different areas the sprite numbers assigned to inventory objects would differ from the number they had when the game was last saved. What this meant is that I could load up a game and find that my sledgehammer now looked like a key, or a key would look like something else. Although this would never happen in the final product it was irritating to me because it would make taking screengrabs difficult and playing through sections with incorrectly displayed inventory objects is confusing. Well, I did some reading up in the manual for some ideas to correct it and found a simple way to save the sprite index name (sSledgehammer) instead of the sprite index number (167), and then tweak my inventory display code to convert the index name back to the sprite number (at this point the sprite number would be correct). Hey presto the inventory displays correctly all the time.

Finally, as mentioned last time, I made the decision that the screen was getting a bit cramped with the objectives display. So I wanted to look into creating a pause system like a lot of games have. This screen would display all the objectives, which I could also separate out into main and optional objectives, and even display more details about them, kind of like a journal.

This new screen would also serve for quitting the game.

The tricky part here is that to pause the game all objects need to be deactivated, and by doing this they are no longer drawn to the screen. and so the screen would be blank. I wanted to be able to have a freeze frame of the game and draw over the top. The go-to way of doing this is to grab the current application_surface as a sprite (the application_surface is the image buffer of the game with everything drawn on it), however, because Asylum uses a lot of surfaces for the lighting and shadows the application surface was not suitable. So, instead I have to save a screenshot and create a new sprite from that. This introduced another issue. By grabbing the currently displayed screen I get the mouse cursor saved to the image as well – this is not what I want because the mouse cursor needs to keep going on the pause screen.

In a rather complex workaround I had to use 2 events to quickly hide the mouse, take the screen, then enable the pause screen. This is done by having the pause state check in the Step event which also disables the mouse, and then in the Begin Step (which would be for the next game frame) I could grab the screenshot and reactivate the mouse.

This worked very nicely and although it’s very early I have a working pause process that is currently just displaying the usual objectives display.