A simple Unity game ready to be published in Google Play in a week… what could go wrong?
This is mostly vent and a cautionary tale to remind myself that one can be an Android developer with decades of experience and a hobbyist Unity game developer for almost a decade, and still make a rookie mistake that costs you long hours of hair pulling and roughly a month of delay before your simple game gets published in Google Play.
Full disclosure: the title is a little bit of a clickbait as development of the game started at the beginning of the year, but given that I could realistically only squeeze in an hour here and there on certain days, it’s fair to say that building the game and getting it ready for Google Play took about a week of actual work in total.
So, the initial idea was simple – to build a dead simple game from start to end that is meant to:
- act as a palate cleanser (and a mental reset) from my main project, which has been dragging on for 4 years now,
- serve as a tech demo for a revamped graphics system that neatly blends low-poly 3D scenes with constant-scale 2D billboard sprites and a low-res UI, all topped off with a pixel-art sauce (with the ultimate plan to reintegrate new version of the whole system into my main project),
- let me have a bit of fun with visual effects using custom hand-written shaders for Unity’s built-in renderer (i.e. fake flat shading, gradient fog, dithered color palette, dithered transparency etc.).
I chose the classic “Octopus” from the Game & Watch series (known as “Ośmiorniczka” from the ЭЛЕКТРОНИКА line where I grew up) as my main inspiration because it sparked my love for video games as a child. And its mechanics seemed fairly simple to reproduce (considering that I managed to flip the score counter from 999 to 0 a couple of times back then).
I called it a de/re-make so I could tell it’s more than a simple remake with 3D graphics. /s
As expected, game logic and mechanics were ready within a couple of hours. I even had a nice pause menu that kicked in during gameplay when the game has lost focus or when the user pressed ESCAPE key. Whipping up a simplistic 3D scene in Blockbench took a bit more time and so did shaders even though I was using some pre-existing versions from the main project (but shaders were actually fun to work-on compared to 3D scene in Blockbench). Getting all the parts (sprites and scene on pixel-perfect camera, UI on canvas, TextMeshPro fonts, etc.) displayed correctly in-sync in a pixel-art-like manner independent of current screen resolution and aspect ratio was the most challenging task of them all and took probably around 40-50% of development time (even though I’ve had it mostly working in the main project, bar UI and fonts).
And finally there it was… in full glory… TENTAKLES.
P.S.: I love playing with typography so the initial title was TΞNTΛKLΞS but don’t go this way – it’s basically unsearchable.
At this point I felt the game was done and ready to be published, so I’ve put it up on Itch, GameJolt and Newgrounds in a HTML5/WebGL format (this showed one additional visual issue related to how pixel-perfect camera works in Unity and the solution caused another additional visual issue with cameras in non-WebGL builds but that’s a different story).
Naturally, the the game flew completely under the radar, but that didn’t matter at all – I wasn’t making it for popularity (and neither do I write this post). As the game seemed done, I figured it would be a good opportunity to brush up on the Google Play publishing process. Even though I work as an Android developer in my day job, releasing apps to the store isn‘t really part of my day-to-day duties (we actually have a dedicated team for that and I haven’t touched Google Play Developer Console in years). I didn’t expect any major hurdles, especially since the game supported keyboard input, gamepads and virtual on-screen buttons right from the start. And given that I did most of my playtesting on an Android phone anyway, I felt like the Google Play release would be a breeze.
Famous last words, eh?
I’ve spent an hour or so on adding sound effects (using Furnace to generate some beeps nicely resembling those from the original electronic version), then another hour setting up Google Play project with all the required descriptions, images, etc. And then another hour building a proper release package… who would have thought that APKs are no longer accepted on Google Play and you need AABs and also the game needs to be built with IL2CPP scripting backend targeted for ARM64 architecture!? I wouldn’t.
Finally the package was ready, uploaded and published on the internal testing track. I’ve sent invites to several friends who reported no issues with the game. Good! Let’s hit that production release button. Done!
Rejected.
Sure, I expected a few bumps in the road during publication. But for the game to be rejected with a comment: “violates Android app quality guidelines, category: Broken Functionality”… I definitely wasn’t expecting that. Truth be told, my immediate reaction was wondering what kind of “broken functionality” could have possibly been detected in such a simplistic game.
And thus began my nearly month-long ordeal of trying to get a straight answer out of the Google Play QA team: what exactly was broken in my game?
At first, I wasn’t too discouraged by the rejection notice. The message was quite lengthy, packed with links to various quality policies and boilerplate statements like: “we do not accept apps that crash or do not function properly”, “fix any issues and upload a corrected version”, and so on. It also included a line that supposedly explained what specifically was wrong with the game:
“For example, your app does not open or load.”
In the attachment there was a screenshot, allegedly proving that the game failed to open or load. Yet, the screenshot clearly showed the game’s title screen. So, it did load and open. However, the virtual touch buttons were missing… Based on this, my working theory was that maybe the QA tests were being run on some sort of emulator device that the game didn’t recognize as mobile, hence it wasn’t displaying the touch controls. A separate question was whether the game was actually running. Sure, it loaded and showed the start screen, but maybe it hang for some reason before it could render the touch UI…? Unfortunately, there was no way to tell that from a static screenshot.
So, I reached out to Google Play developer support asking for clarification on what exactly was broken, along with more details about the environment they were testing the game on. I also explained that the game automatically detects whether it‘s running on a mobile device and only displays touch controls if it is. Otherwise, the controls are hidden, though keyboard input will still work – provided one is connected to the device. I even attached a short video showing the game booting up on a physical Android phone, followed by a brief gameplay session to prove there were no performance or functionality related issues at any stage.
A day later, I got a reply. They sincerely thanked me for my time, for explaining the specifics of the control scheme, and for the gameplay footage. I was assured that all this information was highly relevant to the testing process and was advised to file a formal appeal against the rejection, making sure to include all the materials from the correspondence with the support.
I did exactly that, referencing their reply, and shortly after, I received an email confirming that my appeal had been logged.
A few days later, the verdict on the appeal arrived. The game had been re-tested and, once again, was found to be in violation of the Google Play app quality policy. Cue the exact same block of text with links to privacy policies, boilerplate statements, etc., complete with the clarification: “For example, your app does not open or load”.
Okay, I really didn‘t see that coming, considering the first reply had filled me with optimism, suggesting that my explanations actually mattered.
In response, I re-sent the entire explanation I had previously provided to support, along with the request for more detailed information regarding their test environment.
I’ve also uploaded a new version with hard-coded logic to always display touch controls.
A few days later, a reply came. The game had been re-tested and, once again, was found to be in violation of the Google Play app quality policy. Cue the exact same block of text with links to privacy policies, boilerplate statements, etc., and… “For example, your app does not open or load”…
Tell me you’re replying with template responses without telling me you’re replying with template responses…
At this point, I started firing off emails back and forth with both QA (demanding any extra information that would let me pinpoint the source of the issue) and Support (complaining that QA was ignoring my questions and replying with canned responses). QA kept hitting me with the same canned responses, while Support apologized, asked for patience, and swore they were working tirelessly to resolve my issue.
At some point, in an act of sheer desperation (still convinced the culprit was some exotic device that the game couldn‘t properly classify as mobile or desktop), I went into the Google Play Console and started manually filtering out supported devices by chipset. I blocked the ones used in Android TVs, Chromebooks, Chromecasts, Android Auto, and other such gadgets. There are currently over 1400 chipsets listed in the Google Play Console. I manually filtered out 1068 of them, thereby excluding over 18000 types of Android devices.
I’ve also uploaded a new version with higher min SDK version to filter out even more devices.
It did absolutely jack shit.
The response to my appeal remained exactly the same: the game had been re-tested and, once again, was found to be in violation of the Google Play app quality policy. Cue the exact same block of text with links to privacy policies, boilerplate statements, etc., along with the clarification: “For example, your app does not open or load”.
The breakthrough came when, in yet another email from Support, there was a line stating:
“Broken Functionality policy prohibits applications that crash, freeze, force close, or display other abnormal behaviors. […] The app‘s features must perform exactly as expected, and it is essential to alert users if a button or function might return zero results.”
On the surface, it sounded like the same old spiel, but this time, something clicked regarding “must perform exactly as expected” and “alert users if a button or function might return zero results”.
So, I wrote back to Support again, this time asking if they had a specific button in mind that wasn‘t behaving as expected. Naturally, the reply was generic, but it set the gears in my head turning, and I began looking at the problem from a broader perspective. The investigation concluded just before midnight that same day, when, right before drifting off to sleep, I finally connected two dots:
- Android phones have a native BACK button, whose default behavior is to return to the previous screen and/or exit the app when you‘re on the its main screen,
- Unity intercepts inputs from the Android’s native BACK button and treats them exactly like pressing the ESCAPE key on a keyboard.
In the dark, I fumbled around for my phone, grabbed it, and fired up the game. Squinting against the blinding glare of the screen, I started gameplay and hit the native BACK button. The game – exactly as I had programmed it to handle the ESCAPE key – paused the gameplay and brought up the pause menu. I hit BACK again – the pause menu closed, and gameplay resumed. I went back to the title screen and hit BACK. Nothing happened. There was no way to quit the game and return to the phone‘s home screen (well, technically there was, because the native HOME button also takes you back to the home screen – and that‘s exactly what I had been using during all my playtests… never BACK).
The very next morning, I fired up Unity, opened the code editor, and added exactly one line of code at the very top of the first script on the initial screen:
Input.backButtonLeavesApp = true;
After that, I created a new release build and uploaded it to the Google Play Console. Three days later – with absolutely zero fanfare, and no new emails from QA or Support – I opened the console again and was greeted by a single unread notification:
P.S: Yes, you can download TENTAKLES in Google Play now.