Postmortem analysis of Drunk Shotgun

It's been nine months since the initial release of Drunk Shotgun for iOS and Android. I realize that I should have made a post-mortem analysis in two weeks after the game launch while my memories were fresh, but the game failed so hard that I was in a very fragile state and just decided to forget about it for a while for the sake of my sanity. Its December, 2020 and I feel like I cannot end this year without getting some kind of closure and the least I can do is to follow up this project with a post-mortem.

What is Drunk Shotgun?

TL;DR

Drunk Shotgun is a top-down mobile game where you control a character with a shotgun, who is constantly spinning and cannot stop because he's just too drunk. You tap the screen to shoot the shotgun to damage goblins coming at you and to move around the arena. Character himself cannot move freely due to his condition, but the shotgun recoil moves him allowing you to dodge attacks, gather power ups and move through the arena to get a tactical advantage. You can also tap&hold to engage bullet time allowing you to time your shot precisely and analyze the situation. Bullet time is not infinite and is replenished by defeating enemies. After defeating 99 goblins you face the final boss.

Idea

The original idea was to create a mobile game that is easy to learn and hard to master. I was fascinated by Archero at the time – I liked how you could play it during a break for several minutes and you could only use one hand, so you could play it while commuting on a bus or subway and having your other hand free to hold your bag or whatever. What I did not like about Archero was that the game was too casual in a sense that you did not really control the aiming of the character, though you could (not directly) prioritize targets.

So that's how the basic requirements for the game came to be, it had to be:

Basically I wanted to create a fast-paced hardcore arena game that would make you feel like you are playing Doom (2016), but on your phone while waiting in a supermarket line for your turn to pay for groceries.

At some point of brainstorming control schemes I've decided to try to make player rotate automatically so you would have some control over aiming. That developed into an idea of a player being too drunk, so he starts seeing things that were probably not there and shoot them and that's how the concept of Drunk Shotgun was born.

5 things that went right

Game engine and renderer

Since I already had experience developing mobile games with Unity I decided to go with the same engine. At the time of the development start (October, 2019) Unity has recently announced the support for 2D lightning in their new Lightweight Rendering Pipeline, or LWRP for short (now known as Universal Rendering Pipeline or URP). I was really impressed by the lighting effects and since the game was set at night I wanted to use them as much as possible to add to the atmosphere of the game. Converting the project between the default Renderer and LWRP was a bit of a pain and the best practice was to choose the renderer from the start of development and stick with it. So I've set up a small project to try the 2D lighting system out, since it looked quite easy to use.

I've immediately ran into some graphical artifacts like "holes" in the emitted lights which were hard to fix. While researching for the solution, I've stumbled upon forum threads about 2D light performance problems on mobile devices and decided that probably the system was not ready for production use.

So I've started the development with an older classic renderer. As it turned out, that was a right thing to do.

In April 2020 I've participated in Ludum Dare Game Jam #46 with my friend, and we were developing a game about a person trying to harvest firewood to keep fire for his camp during the night. We decided to use the 2D Lightning system and ran into several problems (no support for proper shadowcaster shape adjusting for animated objects, no shadow culling, etc.), including performance issues on desktop platforms and WebGL, so I am glad I did not go this way with Drunk Shotgun – I am not sure how long would it take for me to release the game otherwise.

Final game build does not utilize any 2D lightning, but uses transparent gradients for light halos

Game Art

The mobile market at the time of development was plagued (and still is) with tons of hyper casual mobile games that don't look good too good, but rather like something that one person put together during a weekend (which sometimes is how it actually was done), so I wanted the Drunk Shotgun to look different – I had to make it look good, something to be proud of.

Since I decided the game to be a top-down shooter and having a replay value and short sessions lead to the decision of making the game easy to learn and hard to master, I remembered of the old-school games like Crimsonland and decided that the art style has to be somewhat similar.

It took quite a while to find a right person for the job. I think that I've never browsed ArtStation so much in my life trying to find a person whose art style is somewhat similar to the references I gathered for the game

Sketches for the menu art

I've narrowed down the list to just one person. He was eliminated after the interview, though, since he was in the process relocating to another country and was available to start working on a project in several months and I needed an artist to start as soon as possible. I was feeling really down since the guy seemed to be perfect – he had lots of relevant works and experience, and I've already spent several weeks just trying to find someone with the right artstyle.

I almost gave up, but decided to post a job on one of the freelance services anyway, and suddenly Yury applied to my job. We scheduled a call and then magic happened – I showed him my art references and guideline document I wrote for the art direction, we discussed the details and he quickly got to work coming up with lots of art variants that were great.

The art turned out to be very similar to my vision of how the game should look like, although I went over budget with art, so I did not have any funds left for the UI and I had to design most of it myself, but I am quite satisfied on how it came to be.

Final menu art with UI elements

Music and sound

Right from the start I felt like the music for the project should be something heavy with distorted guitars, but not too heavy so it won't scare away more casual players. So, more DukeNukemish, less Doomish.

Since my music production skills are quite low and I am exceptionally bad with guitars, I decided that the only viable option is to license the music.

After the art was ready, I've browsed through a lot of Royalty Free music on SoundCloud and finally found two tracks that fit the mood. There is not really much else too say – people who play Drunk Shotgun generally either praise the music or say nothing about it, so at the very least least it's not annoying and does not feel out of place which is good enough for a game that does not have core mechanics tied in with the music.

There is not so much to say about sound design, too, since there are not a lot of sound effects in the game. I mostly used royalty free sounds from zapsplat, and recorded/synthesized some sounds myself. The most hard ones to choose and produce were the shooting sounds and the sound for appearing dialogue text, since they were quite frequently encountered in the game and you have to make sure they don't sound annoying.

Several shells exploding at the same time

One unexpected thing was something that I stumbled upon when designing and testing a power-up that made shotgun pellets explosive. Whenever pellets hit a wall or enemy at the same time, the explosion sounds multiplied, producing a very annoying sound. As it turned out, Unity has a built-in support or audio mixing with effects and limiters, that helps to mitigate this kind of situations.

Architecture

The previous games that I deigned were relatively small and generally implemented a Singleton class for Game Controller or Level Controller which at some point of development evolved in a big messy God Objects which inevitably become too complex to debug and work with.

I wanted to avoid this problem as much as possible in Drunk Shotgun, since I wanted to be able to quickly make changes to the game right from the start of prototyping, so I relied heavily on Composition and keeping my classes as small as possible.

As with any project any programmer have ever done in their lives, I won't say that it turned out perfectly, but I would say that it was good enough. Whenever I look through the project I can quickly tell what's going on even if I hadn't touched it for months. I've also been reusing a lot of my classes from Drunk Shotgun in my other projects since the release and that says something.

Animation

I went over budget with art, so I had to animate everything myself. Since the game is 2D, I had two options:

The first option is too time consuming and I went with the second one. There are two ways of implementing skeletal 2D animation for Unity: using paid the 3rd-party software like Spine or using the new Unity's package for 2D animation.

I've considered using Spine since it seem to have become an industry standard of animation for 2D games (at least for indie ones), but my research led me to believe that there is no good way of playing Skeletal animation back in Unity other than animating everything in Spine and then exporting frame-by-frame animations. I am not sure if it's true, but I was not able to find any working examples; and exported frame-by-frame animations were not something I was ready to live with, because that means that I could not quickly swap out weapon sprites in character hands and the overall game size would be larger (and that's particularly not good for mobile apps in general, not just games).

The Unity's animation package turned out to be quite good, despite some initial problems with unintuitive UI. It even supports inverse kinematics, so you can easily animate limb movements, which is especially great for attack-related animations.

The animations turned out to be quite simple due to limited time, but I am quite satisfied with the overall look and feel, the only thing that I regret is that goblins lack attack animations as I did not have enough time to animate and implement them properly, but that's more of a game design issue than an actual animation one.

5 things that went wrong

Oh boy, where do I start?..

Iterating and prototype testing

After the idea was born it took me two evenings to put the first prototype together. I was set on doing this project the lean way by iterating simple prototypes on friends and family to tweak the gameplay mechanics until I find the game to be fun and engaging enough.

Prototype of Drunk Shotgun created with free graphic assets

It went as planned only by some degree. I did 4 iterations adjusting the game according to the provided feedback:

However, I realize now that there were three problems with how I've done the prototype testing:

The latter point is the most painful. My friends found the game to be "too hard" and I assumed that it's a good thing, because the game was supposed to be easy to learn and hard to master. The problem is that people that I've tested the game on were not fans of hardcore games, they were simply not the intended game audience and I did not test the game on someone who was supposed to be the right audience.

I could have posted the game online, e.g. in /r/playmygame subreddit, but I was too consumed by the thought of some hypercasual game company copying my game mechanic and putting it out on the store that I decided not to do it. That was a mistake, and I am not sure how exactly did I make it given my startup background and knowing that ideas are worth nothing, only execution is worth something. I guess giving the advice of not caring about keeping an idea in secret to someone one is easy, but it's harder to follow it when it's your idea in question. You should follow it though.

In retrospect, even if some hypercasual game company took this idea and made it in a successful game, it would actually be kind of good, since it could prove that the idea is viable.

Since I did not test the game on the intended audience, I missed a huge opportunity to make the game better or even change it completely before starting the production. I can probably still do it now, but I've already lost a lot of time and resources and it's painful to change something that has so much worked poured into, it's much easier to do so on prototype stage.

Putting the game mechanics aside, why did I even make a game about shooting goblins if people, apparently, like to shoot zombies? Truth is: I did not like shooting zombies, but the audience might like it. I didn't bother to even learn it.

Gameplay progression, difficulty curve and monetization

Only after putting together most of the game I realized that it lacks sense of progression. This is something I could have avoided if I kept iterating the prototype and focused on keeping the player playing the game rather than giving it up after several tries (which I thought was okay since I tested the game on the audience that is not into hard games, but ignored the fact that I didn't try to anything to keep them playing despite the difficulty, let alone finding audience that likes hard games).

There is simply not so much in Drunk Shotgun to keep the player hooked. The only progression elements are:

At the days of arcade cabinets and early flash and mobile games like flappy bird this kind of progression would probably hold up, but not today, when we have brilliant games like Hades that help you to become better and give you a great sense of progression.

There was also a problem that I did not really know if the difficulty curve is actually too steep and the game is too hard for the target audience, because I never tested it on one.

As for monetization, I've decided from the start that I would not make an "advert watching simulator" like a lot hypercasual game developers do and will respect my player at least in this aspect. So I've added an option to get one extra life per run for watching an ad. This option was unlocked after the first ten kills, because if you managed to die before landing 10 kills, you run is probably already spoiled and it's easier to start over.

I quickly realized the problem after launch, as a lot of players didn't even manage to land 10 kills, while people that managed to get to 50-60 kills preferred to start the game over instead of watching ads. I've lowered the threshold for getting an extra life to dying after landing 5 kills to get at least some ad views. I've also added ads that show up every 4 playthroughs if you didn't view choose to view an ad for extra life. That obviously did not help with the disaster of what monetization in this game is.

So, basically, the players who were good at the game and enjoyed it didn't see ads and bring any revenue (apart from the few ones who decided to support me and buy ad-free version) and the ones who were good at the game had their frustration fed with ads.

Pre-launch and launch

People from the game industry always say that the game community has to be built before the game is released. I thought that this does not apply to mobile games given the fast-paced market and the huge amount of hyper casual games that come and go in a matter of days or weeks.

For some reason I ignored the fact that the game I was making is neither a rapidly developed one that you can make in a matter of weeks solo and throw out to the market to see how it reacts, nor a casual one, given the theme and difficulty. Or may be I just chose to ignore this fact, because marketing is boring and design&development is fun (at least for me) and when you are working in a team you have someone to say that you're are probably not prioritizing things correctly, but when you're working alone it's easy to lose focus (the art was commissioned hourly, so I was basically working alone all of the time at the game marketing, design, etc.)

On a launch date I just published the game on App Store and Google Play, posted in a couple of threads on reddit, my facebook page and twitter and, well, as you can predict nothing happened. No traffic, no traction.

Rare people who downloaded the game did not play it a lot, I got a couple of praising feedbacks and that's it.

Post-launch Marketing

Then I tried to set up ad campaigns on Facebook and Instagram and realized an important thing that I didn't realize before: it's very hard to market games that has guns, violence, blood and alcohol references in it on these platforms which is quite bad for me, since these platforms a the main one for getting paid traffic for mobile apps in general.

I did not have a lot of marketing materials, mainly the game logo, cover and several small gameplay trailers. I assumed that gameplay trailers will be enough to hook players. The problem is that facebook straight up rejected all my ads for having either guns or violence in them and I did not want to be the guy who makes those awful clickbait ads with images that has nothing to do with the actual game.

So I decided to try my luck with instagram, because for some reason the process of as approval in it is different from facebook. I ran the campaign with gameplay trailer for several days and then got my account banned for violating the rules in both instagram and facebook.

Gameplay video used for Instagram Ad

My facebook ads account was never unbanned, so I decided to try my luck with google ads, but they never generated enough views and clicks.

I get now why game developers often try to work with publishers: not only because the process of going to market is hard, it's just boring, you generally just want to focus on developing an excellent game experience. Also, the publishers usually know the audience much better, so they might be able to tell you what should be changed.

The reality is that the marketing is what actually defines if our game is successful or not (but your game has to not suck at the very least).

Animation (once again)

While I've told you that I am quite satisfied with how the game animations turned out, there were communication issues with the artist about it. The artist did not have alot of experience with skeletal animations and neither did I. That resulted in me giving him a quite oversimplified requirement of just making the character and monster sprites broken up into separate parts (limbs, torso, head).

Example of character broken up in movable parts from the design requirements document. Character Art by Riley Gombart (opengameart.org)

The artist did as he was instructed and when the work was finished I still had my head in the gameplay programming, so I just accepted all of the art without fully checking how the broken parts are presented in the source files.

Only several weeks later when I started animating, I realized that I had to redo all character sprites so when their limbs or heads are moving the joints won't be visible. I also had to mirror some of the characters limbs so I could make proper walking animations.

Eventually it turned out to be alright but if I knew the nuances of getting the art ready for rigging and skeletal animation when commissioning the art, so I could communicate them to the artist properly, I would have saved a lot of time.

Fun fact: at some point I've realized that I have to make an in-game tutorial and tell some story to justify what's happening in game, so I added a segment with Jack, the protagonist, exiting a bar. He was supposed to be just walking out of the bar without any weapon visible before stopping and realizing that he cannot walk anymore and then start spinning. The problem was that Jack's sprite had arms only in the shotgun-bearing pose and he had no legs, because I thought that legs animation on a spinning character will only confuse the player. So in order to make Jack look like he is walking with his hands in the pockets, I just removed both of his arm sprites, that's why he looks weird in the intro.

Jack coming out of the bar

Bonus: Android Release

There were also two problems revolving around the Android release.

The first one involved the performance. I've tested the game on Pixel 2 and it was running buttery smooth in glorious 60 frames per second. I've also tested it on a bunch of iPhones including an old iPhone SE (released more than 4 years ago, a lifetime in smartphone terms) that I borrowed from a friend - it ran perfectly. When I decided to test the game on my girlfriend's Samsung (released two years ago) the performance was worse, but still playable. I gave the game build to a bunch of different people and some found troubles shooting and feeling that the game lags on more recent Android phones.

I never fully figured out the performance problem on some of the Android phones, but it's clear that for some reason Unity games run on Android slower in general, even on recent devices with good GPUs. I am not sure if it's a problem with lack of low-level GPU access (Vulkan API is probably going to solve the problem if more manufacturers will adapt it).

The other problem was the screenshots. While Apple had no problem with the game screenshots having blood on it, Google Play reviewer told me that the screenshots are not acceptable, so in order to get the game to the store I had to pull the oldest and stupidest trick in the book.

I changed the color of the blood from red to yellow. And Google accepted it.

Original screenshot vs Google Play Store version. I actually start to like the second one better.

I have no idea why the color of virtual ketchup matters, I guess this teenagers that play violent video games won't become psychos. Or at least they won't attempt to become video game developers like I did – if only they changed the color of virtual blood when I was a teen.

Statistics

Worktime

I've started developing the prototype of Drunk Shotgun at the end of 2019. Several weeks after development start, I've joined Listenable as a full-time CTO, so I did not have much time to work on the game, and I primarily worked on it on weekends, evenings and sometimes at night, so it's hard to calculate how many work hours was spent on it, but I tried to roughly approximate it based on my git commit history.

This does not include time spent on game concepts and time working with an artist on the art direction as it's hard to estimate it (artist's time also not included here).

Money spent

I've also used EasyMobile plugin which I bought while working on one of my previous games, so I didn't include it here. The price was around $70 at the time of purchase.

Ads conversion

Some stats based on the ad campaigns that I ran on Instagram with gameplay video as ad creative:

CPI is not so bad, but as you can see, the game fails to convert players to paying customers. The other problem is that CPI does not matter if FB/Instagram will eventually block your ad account due to "violent" gameplay in your ads.

Revenue

There was in fact some revenue, but it was very small:

Key takeaways

Here what I promised myself to do when I start my next game project based on what I've learned:

A lot of things in this list seem obvious and you could've read them somewhere else. I know that I've read some of them, too. But when it happens to you sometimes you think that somehow the rules just do not apply as your situation is unique. Truth is: it's not and you a probably just chose to ignore something that may bite you when you least expect it.

P.S. Drink responsibly.

Intro, tutorial and gameplay video. Actual gameplay starts at 1:42