Development log
by Ivan Kravarščan
TL;DR bugs happen, please send me the save.
Last weekend I checked the Play Console app (for Play Store publishing stuff), as I do from time to time, to see if the Play Store has any news for me regarding the Ancient Star. First screen, with a stats page, showed no game crashes and there was a new entry in the review list. It read “game crashes”, one star. For a moment I panicked but calmed myself with realisation I can’t do anything without opening the Console on the PC.
Sure enough there was a crash report, 10 or so from the single user, but nothing useful about where the error was: a generic NullReferenceException when resuming a coroutine. If you don’t know what a coroutine is, it’s a mechanism for packing a piece of code for a later execution, potentially on another thread. It’s one of the standard tools provided and managed by the platform running the app. So without any indicators of where my code came into play it was impossible to figure out what caused the crash. Since it was the first crash I’ve seen on Android 14, I figured I should try the game on that version of emulator and maybe I just needed to update some dependencies to fix the issue. It was a bit bizarre that a crash would originate from the system code so I was priming myself for making blind shots.
Next morning, I opened the Android Studio and it turned out it was already set up to emulate Android 14. The game runs perfectly fine there. I went back to the crash report to dig for more clues and fortunately (under the circumstances) there was a new crash report but for an earlier Android version and with more data. Resuming a coroutine attempted to run the game’s turn processing logic and that’s where NullReferenceException happened. For security reasons some information is not included in crash reports. Usually the error message is stripped but it’s possible that on the newest Android they decided to strip even more information or that they don’t handle certain cases properly and the info gets lost. So I assumed that the new crash report was the same issue as Android 14 crashes but with more complete data.
It pointed to the piece of code that was sending newly built ships to their rally points. When a ship eligible for a rally point is built it’s added to a special “to rally” list and that list is processed near the end of turn processing. The crash happens when “to rally” contains a ship that is not there anymore. I assumed such discrepancy could only happen in case of a battle but that case is covered by both logic that removes “to rally” ships at battle fields and by an automated test case.
In any case I added the logic to not rally nonexistent ships. And the fix is still waiting in Google’s review queue. Is it because the game was not updated for a few months or because they required me to declare if the game has any health features. It’s a bit embarrassing to wait almost a week for a trivial fix to land and to only be able to talk to the player by editing app review and dev’s response to review.
I’d like for the player in question to send me the offending save. I have a theory about what else could make the “to rally” list bigger than real ship count. It’s unlikely, marginally but still possible, to build a colony ship or a troop ship and have it reinforce the system it was built in. Having the actual save would clear any doubt though.
tags: