Welcome to the HotchPotch Indie Game Dev Blog – every week (or so) I will post updates on my current project: Holey Suit, to the escape pod! Holey Suit is an upcoming physic-ish space survival action game, which I’ll try to release to itch.io for free pretty soon. The previous posts in this series can be found here, here and there.
In this week game dev blog I thought I’d share some detective work I performed with Holey Suit. Optimisation for games can sometime feel like running an investigation, trying to gather clues and figure out where inefficiencies are hiding! I’ll also quickly touch base on the Android port which I work on in parallel for a very specific reason – more on this below!
The graphics in Holey Suit are rather minimalist, not to call it basic! Certainly the game won’t have any issue running on current computers. But this is still no excuse for inefficiency, especially since I’m considering an Android port! So as part of the development process, I have been bench-marking the game to make sure things would run smoothly, even on a modest CPU.
Luckily, Game Maker’s real_fps variable provides exactly the information I was after when chasing for inefficient loops & code. This quickly help identify a few bugs:
– Destroyed items were pushed out of screen, but their life was never reset to original value and remained zero. Consequently, they would enter an infinite loop of destruction. To make matter worse, this would also create explosion objects to further reduce fps!!
– The HUD displays energy/oxygen bars as doughnuts; the code I used (salvaged from the internet) turned out pretty inefficient. Although my PC was able to cope with it, this was a very different story on my Android device which plummeted around 40fps. I redesigned that piece by using a sprite instead (filling up the doughnut gradually in each sub frame). This worked a treat: from 40 the game jumped to 140fps on Android. Great success!
When chasing inefficiencies, spreadsheets can be a real big help. Not only you can figure out averages in a few clicks, but you can also use graphs to visualise bottlenecks – as shown below.
This was paramount when troubleshooting the poor performance on Android. When running tests, I was trying to have a healthy balance of gameplay, with and without aliens chasing, and death screen. Quickly, I noticed the death screen ran significantly faster than the rest of the game. There was no apparent reason: debris still drifted around, aliens still patrolling in the background etc..
I petted with a few ideas and tried a few optimisations. One of these was the addition of an option to remove background debris. Another the ability to change resolution. Although this was great overall in terms of polishing the game, this only partially fixed the issue. The game still felt slow when playing.
The solution became obvious when working on the tutorial. I wanted to hide the HUD display in the first part of the tutorial, which turned out to run smoothly on Android. As soon as the HUD was displayed, the game would go back to crawling speed. Finally putting one and one together, I went on to replace the entire code displaying the oxygen & health bars. The game now runs fine on both PC and Android!
Besides optimisation, I also spent some time making sure the player experience was good on Android. Whilst I am not considering a port immediately, there’s a reason I’m doing this early on in the process. It is simple: make sure the game is “mobile-friendly” from the onset!
I had one prior bad experience when it came to mobile. A previous project of mine was a little rogue lite, which I was planning for Android. After weeks of work (on my spare time of course, I’m a hobbyist!) and having a strong base for the game, I decided it was time to test it on my Android phone. The game was a rogue lite, and I wanted the dungeons to be minimalist and have a similar feel as the Binding of Isaac. This meant the obvious choice was to split the dungeons into individual rooms, with the player seeing the totality of each room on a static the screen. As it turned out, I had overlooked one very important thing: the player’s thumbs! My idea was to have virtual joystick; as it turns out this would mean blocking the bottom right & left corner. Since I had designed the entire game on room per room exploration, trying to move away from this (screen following the player, redesigning the dungeons etc) didn’t feel good and I eventually abandoned the project.
Rich from that experience, and determined to avoid the same fate for Holey Suit, I designed the game from the onset with a camera following the player. Testing on Android early on actually had benefits for the PC version too: it meant reassessing the game screen size, display and even menu. The Android port felt like the camera was too wide and the characters too small. I eventually opted to add multiple resolution to chose from in the option menu. This was also in conjunction with the optimisation process, as the closer the view the less items I would have to display.
Did you enjoy this Indie Game Dev Blog? Interested in Holey Suit and its development? Follow me on Twitter 😉