Asylum – Dev Diary 16

I’ve decided to compile a single weekly update rather than one per dev day. Makes life easier and these diary entries should be more meaty.

This week I’ve been concentrating on a few different aspects. Firstly I’ve been putting together some new sprites and tiles to use in various locations on the first floor. There’s a new floor tile for the reception room and an office desk. The chairs from the previous screenshots have also been improved.

There was also a small bug bashing session. It appears that changing the alpha for drawing purposes also sometimes affects some of the objects on the map regardless of whether they are being ‘drawn’ or not. So I’ve had to go through my GUI routines and make sure that the alpha is reset after everything’s set to the screen.

One aspect that also needed to be worked out was the screen resolution. The game is designed for a 1080p resolution but obviously it needs to be able to play on other layouts. So, I’ve started to work out those details. Firstly when the game starts it works out the size of the display and matches the game resolution to that (and makes it full screen). The game then passes to the title page – which at the moment has some very basic options (New Game, Continue, Full Screen Toggle, Exit Game). The full screen toggle is only temporary to allow me to switch to 720p windowed mode for testing. There’s quite a lot of fiddly bits to take care of when changing resolutions. Every aspect of the game window can have a different size so you have to make sure everything matches properly; the game window, the application surface (drawing surface), the GUI layer, the camera and the viewports, otherwise things start to look weird, and in one run I had a tiny GUI and oversized game view.

The next really complex thing to handle is the game saving and loading. I’ve opted to do trigger areas to save the game as this will be very important later when certain situations can result in the player being killed and I will need to be able to rewind the game to a safe point where they could continue and succeed instead. After a couple of hours of going through all the current aspects I’ve hit a problem. I need to remember all the objects that have been removed from the game, and also the state of some objects (such as whether a door is open or not), at the moment the routine I have for handling this is causing a massive performance hit for some reason. It seems that the LoadSave routine is polling too many times even though it should just occur when the player hits a trigger (which is then removed once saved). It’s going to take a bit of a head scratching session to work out.