Tankquish Retrospective

Tankquish is an action-racing game for Android where you take command of a tank and chase after a UFO that stole your dog! Development began in January of 2023, when after seeing a PC tank game me and my brother were working on, my friend asked to join our team. We then decided to put the PC project on hold and start working on a “small” mobile game to get used to working together. With the project, we wanted to learn more about developing games and launching them, as well as about all the unique quirks of mobile game development. Our 3-person team consisted of me (the graphics guy), Emil Virolainen (the code guy) and Otto Karinen (the level design and marketing guy). We were assisted greatly by the mentors and peers in our incubator network, LGIN.

The Good

Asset bundle implementation

To fit our 200MB+ game onto the Play Store, we had to split it into several separately downloadable parts, called asset bundles (not to be mixed with app bundles or asset packages). This was a daunting task, as we had no prior experience of asset bundles, a rather confusing and complex system with several different ways of implementation. 

 

After diligent scouring of Google and Unity’s documentations, we found an easy no-code solution. Of course, because it’s unity, it’s a hidden easter-egg checkbox that does all you need with one click! It’s called “split application binary” in the project settings. This splits the application into two asset bundles (provided the build’s size is less than 1GB) which are both downloaded upon installing the game. The only drawback is that this only works for Android apps and only when publishing to Play Store.

Testing was invaluable

Throughout development, we kept iterating on our design. Having people test our game in-person was an inexpensive and crucial part of figuring out what works and what doesn’t. Tests in IGDA’s demo corner and design workshops hosted by our incubator LGIN, where someone would play and comment on the game and we’d take notes were a massive help in finding new people for testing. Testing allowed us, among other things, to resolve two big design issues:

 

There is an enemy UFO on each level of the game that the player can shoot by collecting any ammo (the tank shoots automatically after picking up ammo). The UFO was originally meant as the main focus of the game: if you make it to the finish line before the UFO, you win! Otherwise, you lose. For new players, however, it was very unclear what it was, where it was, why it was there and what it did. This was resolved when one tester made the suggestion to have the UFO always in front of the tank. Now, the goal of the game was just to get to the finish line intact, but killing the UFO was one component in getting 3 stars on a level. With the UFO being always in front, it’s very clear where it is and with its purpose explained in a tutorial level, it no longer confused players with its existence, at least not as much. It also ups the ante of the game quite nicely to try and keep up with a ufo while dodging obstacles and trying to stay in one piece!

 

Another design issue revolved around obstacles – trees and rocks. They originally caused damage to the tank but it only occurred to us after one testing session that trees and rocks are indeed exactly what anyone expects to be able to destroy with a tank! We changed them so that they are harmless and it feels great to destroy them with a tank! You get points based on hitting them, which is a form of positive encouragement: rather than being punished for hitting them, you now merely get less score if you don’t! We still have harmful obstacles in the game in the form of landmines and bomber aliens, but they work well as they’re very clearly “bad” with their red outlines.

 

Level creator

When we first started making lots of levels, I modeled this suite of modular pieces with which levels could be quickly assembled. They were useful, but placing them in unity was a slog. It was so unpleasant that it made us avoid level design and creation and find some less important work to do. Emil then came up with a wonderful editor tool which allowed us to build and test levels much much faster which resulted in some wonderfully lively levels in world 2 (the newer batch, circa 50% of levels). I only wish we had got it sooner, which would have resulted in a lot more levels and higher quality ones also, because we were much more motivated and enthusiastic about making levels at the start whereas towards the end of development we were more about just getting the game done. As such, the editor tool was really only used for about 5 or so levels. This might have been prevented since we knew for so long that making levels was such a chore. All it would have taken was a good look in the mirror and trying to tackle the level design issue when it first arose.

 

Rapid prototyping

Tankquish’s core idea was generated quite early in development. Emil made these grayboxed, really simple webGL builds with different control schemes for driving a tank on mobile. At this stage, we were still making an endless runner (or rather, oscillating between an endless and a level-based game once every week or so). The final inspiration for our controls ended up being Mario Kart Tour, Nintendo’s mobile Mario Kart racer. Throughout development, various game design aspects continued to get honed via quick (and sloppy) testing of new features. This was a thing that contributed greatly to us finding the right game design for Tankquish and in conjunction with our periodical in-person testing, ensured a good user experience. 

 

It should be noted that Emil also ensured a comparatively very smooth implementation of the ever-so intimidating analytics which, apparently, are very important for mobile games. We wanted to implement analytics even if we weren’t going to use it (e.g. via test marketing), for the learning experience. We got some data through analytics from our ~20 test users, but in-person testing still provided us with our greatest insights so far.

An early mockup for the game’s main menu by Otto

 

Social media marketing

Tasked with finding ways of marketing our game with a 0$ budget, Otto came up with a great way of getting views on TikTok. He made these videos where one half of the screen is gameplay of Tankquish and one half is a clip of some animated show, usually of some topic that relates to Finland. We soon had nearly 200k views on one video.

It’s not all solved yet though, since the views aren’t converting to downloads. TikTok requires you to have 1k followers before you can post any links on your bio. Additionally, 99% of the comments on any of the videos are the same: “Finland mentioned! Torille!”. To combat this, we’re going to try posting videos of Tankquish gameplay only, with the “borrowed” content in the form of some text on top.

The Bad – Or the Not Good

UnityAds and the Gradle Debacle

Trying to get UnityAds to work has been the single biggest thorn in our backs for over 6 months of the tail end of our development. Frankly, the experience has been absolutely horrendous. UnityAds (recently merged(?) with IronSource) and IronSource both have their own documentation on how to integrate ads into a Unity project, but they’re both different from each other and both have references to buttons that no longer exist in current versions of their websites. In addition to this, one has to juggle between the Unity editor, Google’s advertising systems, UnityAds/Ironsource and android builds. It’s a treacherous, misleading mire of unclear, enragingly inarticulate slop of the most random information strewn all over the place. It’s incredibly hard to get a grasp of as a first-timer.

 

Our issue has been that ads display correctly in the unity editor, but the button that activates an ad is always disabled in our builds. We contacted Unity support, but they were only ever interested in whether their system had a bug or not. We told them many times that we had difficulty understanding what exactly to do to get ads working correctly but they would not provide us with any instructions, instead opting to send us a clean Unity project with their own ad implementation that also worked in the editor! It would’ve been too much work to put that project online on our accounts and set up all the ad networks on their web platforms etc. to test if the ads would work on a built version of that project.

The gradle debacle

After our experiences with Tankquish, I have to say that for me, building for Android is a massive pain, at least from Unity (although building from android studio seems like an even bigger hassle). Unity’s tools for Android are very weirdly presented and evenly hidden across every window of the engine. It’s a process of its own to figure out where everything relating to android building is. The dependency resolver has a useful button called “resolve dependencies” which seems to offer no other use than to break your project and prevent any successful building. If your build fails, the culprit is (in our experience) gradle 9 times out of 10. The reason for failing is most times unknown. 

 

To my frustration, I can so far only offer you one reliable way to fix anything android related in Unity, and that is to update your unity version! This, however, only works so long as a new version of the editor has been released. I don’t have good tips on how to avoid all this annoyance, other than to avoid making android projects with Unity for the time being, at least if you are a first-timer like us. It’s already a considerable time investment to do all the problem-solving and reading up that we have done to end up with our current (still lacking) amount of information on all this.

 

Scope (and “Why Mobile?”)

For a game that was supposed to be a quick half-a-year learning project, Tankquish took way too long to make. There are a few things that caused this, more than others. Firstly, we were periodically a bit torn on whether this was a money maker product or just a tool for learning. This caused some confusion on whether to focus on the meta-loop or core-loop of the game. We also encountered a lot of moments in development where we finished a feature and went “now what?”. This was obviously due to some lack of planning, but also due to not adapting our plans to what was going on with the project. Since this was a project we worked on in our free time, our day jobs and responsibilities kept justifiably taking time out of developing Tankquish, sometimes causing phases where none of us were contributing to Tankquish for weeks. 

 

Luckily for us though, LGIN kept making us devise new deadlines every three months. This always helped us get cracking again. In the end, our scope did get too big and we had to scrap the whole garage/metagame aspect of the game. This did allow us to reorient ourselves on making a practice game however, and not a money printer. It was crucial in finally getting the game out. 

 

If we started the project today, we’d be much more aware of the amount of work required for each feature and would plan a much smaller Tankquish with a tighter core loop. It’s useful to stop every now and then to consider if any extra features you’re working on are actually needed and whether the core loop is finished enough that you can afford to be working on extra stuff. This is something that we may have overlooked as newbie game developers, as we wanted to keep as many of the cool features we had planned as we could. We ended up having to cram a lot of different features into a crowded game design, which also slowed us down as we had to constantly make old features accommodate new ones. It was all just a bit much for a 3 person team.

Otto’s hilariously realistic mockup of a garage screen

 

Monetizing Mobile is Tricky

If we’d have wanted to make some real money with Tankquish, we’d have been in some trouble. We had no ideas on how to implement good monetization mechanics and furthermore, good mobile monetization should not be an afterthought, but baked within the game’s core from the start. Monetizing mobile games is generally quite a daunting and resource-intensive task, as ads alone aren’t very good for revenue. You need microtransactions, which themselves are a big job to implement with a 3 person team of noobs. Testing data is surely the key in getting the most out of your monetization.

 

For future projects, especially ones that have a more free-to-play model, we intend to pay much closer attention to monetization from the start, and how to bind it nicely to the rest of the game so that it works for us and the player.

Wonky Controls

Controlling the tank has always felt a bit weird for first-time users and still does. A big issue we always had in tests was that players tend to bump into a wall when taking turns (due to the iffy controls) and get stuck in a ping-pong loop where they bounce back and forth from wall to wall. Over time, we managed to improve both issues but couldn’t fix the controls entirely. For starters, we removed the walls from many sections so that instead of getting locked into a ping-pong loop, you’d just fall off the map and lose. Not an optimal fix, but at least not game-breaking anymore. We also increased the camera FOV to make it seem like you were going fast when you weren’t. This allowed us to slow down the tank a little without affecting the game pacing. Emil also tweaked the steering mechanics so that steering sensitivity lowers the further you drag your finger when turning the tank. As such, players take quick turns with less effort and have more control of the tank in large, arcing turns. 

 

Emil was working on and off for months on getting the tank to bounce into the right direction after hitting a wall. In the end and after many different solution attempts (and a lot of scrapped code), a system was implemented where we generated checkpoints along each course and used them to compare their forward direction to the tank’s in order to determine what way is “forward”. This enabled us to make the tank bounce towards the right direction when it hit a wall. It didn’t remove the ping-ponging completely though, but improving it further would have required tweaks to Unity’s physics handling. A task which we could ill afford anymore.

Developing on mobile …Without a mobile device

A mobile game should always be tested on mobile while developing. This was true for us too in the start of development. Emil made periodical webGL builds of the game which allowed us to test in browser on any device, but as the game grew in size, webGL stopped being able to handle it and we were left reliant on Otto’s Android phone for testing the game as me and Emil have iPhones. The lack of a mobile testing device for two thirds of the dev team caused, among smaller issues, our weird-feeling steering controls and some levels to be balanced a bit weird for a long time. 

 

We were not constantly reminded of how odd the controls felt on mobile as they were designed and tested on PC with a mouse (which felt good!) so there was a lack of motivation to fix it but we also ran out of ideas on how to improve it further quite early on and just sort of let it be in order to focus on getting the game ready. Levels were also disproportionately difficult or easy on mobile as they had not been tested on mobile. Otto fixed this before we launched through a grueling process of testing each level on the phone, making notes and then editing the levels and building the project again.

 

The Ugly (noteworthy mentions)

Water is Harmless!

Making a good tutorial and onboarding new players had us scratching our heads for a long time. For a good while, we had some useless tooltips in the game such as “water is harmless!” which I feel illustrates quite well how lost we were on how to guide the player and what it was they needed guidance on. In the end I made 3 tutorial levels which do the job of introducing the core aspects of the game to the player adequately but are not foolproof. It would have made all this easier if Tankquish did not end up being such a jumble of different game mechanics all on top of each other.

 

Mobile FPS

FPS IS LOCKED AT 30 IN UNITY MOBILE BUILDS BY DEFAULT. This has to be manually set to another limit via code. Check this before you spend months on optimizing (like we did).

Main Theme

The Main theme is really catchy, sometimes even quite annoyingly so. I’m told some children sometimes hummed it after testing the game, which I take as a great compliment!

 

Design by committee is slow

We did all game design together in separate in-person and remote meetings and although this didn’t lead to disputes, the speed of development would likely have benefited greatly from having one person be solely responsible for game design. This would’ve applied pressure on that individual, who would have had to make some difficult calls on how different systems played together in the game, which might have helped us to stop pondering on what was the best way to do things and get to work sooner during our “what now?” breaks in development. I heartily recommend any teams that have a more collective form of decision making to consider appointing someone as the person who makes the final call.

 

To Wrap Up:

Tankquish absolutely reached its goal of teaching us about development, launching a product on mobile and working together as a team, but due to many reasons took us way too long to finish. The end product is quite different from what was originally envisioned, but we are satisfied in how much fun the core gameplay is. It would undoubtedly have made the game a lot more fun if the meta loop would have been implemented, but we are proud in having been able to finish this project as well as we did. We don’t think we’re going to be making any more mobile projects very soon. Making games with the Unity engine does feel to be somewhat better optimized for PC rather than mobile development, what with all the external systems and platforms involved in mobile, even if it is kind of painful even for PC games. Nonetheless, Tankquish has provided us with a lot of experience and tough lessons on what to pay attention to during our next projects!