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: