Sponsored By

Hang Line Postmortem Part 2 - Ten lessons I learnt making my first indie game

Part 2 of a 3 part postmortem of how I made my mountain swinging, goat grappling game Hang Line. This post focusses on the most important lessons that I learnt making the game.

Ed Kay, Blogger

April 14, 2020

10 Min Read

HangLine_AppleID_AppStore-iPhone-iPad-ATV-Legacy_Featuring.png

This is the second part of my Hang Line postmortem. If you landed here out of nowhere, you might want to read part one first about how I made the game:

Hang Line Postmortem - Part 1

Although I've been working for various video game companies for over 18 years, Hang Line is the first game I made entirely by myself. Here I’m going to cover a summary of the top ten most important lessons I learnt making my first game as an indie developer.
 

1. If you want a sustainable business, don’t start with your passion project

KermitExcitedAtDesk.gif

I’m not saying you shouldn’t be passionate about the game you make. But if you want to be able to keep making games then the most important thing is to work on a project that you believe has a solid chance of being profitable. I once said I’d rather sell toilet paper than make a free to play game, but look what happened! (actually selling toilet paper would now be pretty lucrative given the current environment...)

I chose mobile because I saw the quality of games that got featured each week and thought I could make something that would stand out. I chose a relatable and family friendly theme to increase my audience potential on mobile. Everything from the graphical style, the progression system, the one handed control system, the humour - it was all to reach a broad mobile audience. It wasn’t to follow what I’m passionate about.
 

2. Don’t be afraid to ask for advice from people you don’t know

KermitPhone.jpeg

I got in touch with lots of other developers via linkedin, developer forums, twitter etc. There are so many people that jumped on a skype call with me even though they didn’t even know me, and the advice they gave was incredibly valuable. 
 

3. Don’t be afraid to ignore people’s advice

KermitIgnoreAdvice.jpg

There were many times part way through when I was questioning how much longer to spend on the game. There were so many people who gave me the advice “Just get the game out as quickly as possible - it’ll probably fail”. I ignored this time and time again and polished the heck out of Hang Line. This was a huge risk, but it paid off. 

It’s definitely important to listen to people’s advice, but you have to remember you are a different person to them. Don’t be afraid to ignore people sometimes and choose the path that is the most authentic to who you are.
 

4. Don’t pretend your game is more finished than it is

KermitComputerRelaxed.jpg

I had the basics of Hang Line’s gameplay built within a few weeks. I had the core in-level experience built within 6 months. But I didn’t actually ship until a whole year after!!! And that was just soft launch. A lot of people focus on polish early on, and often put a lot of decent art and sound in. Now this definitely makes a game easier to evaluate and easier to impress a publisher with, if you’re going down that route (hence why vertical slices are so popular). 

But if you’re building the game by yourself, this approach can be really misleading to yourself as to just how far along you are. I left a lot of temp assets in the game for a lonnnnng time. I didn’t record or implement a single sound till 3 months before ship. The goats were unity cubes all the way till 2 months before ship. 
 

BlockyGoat.png

Let’s be honest now, hardly a thing of beauty… 

All of this meant I could 100% focus on making the nuts and bolts of the game work properly first, before I started making everything look and sound nice. 

Assuming you’re self publishing, focus on the tasks that actually get your game closer to shipping rather than the tasks that make the game look like it’s closer to shipping. Don’t get me wrong - it can be really helpful to throw things into a prototype to ‘juice it up’ and better evaluate it. But once you know that you’re going to take your prototype to the finish line, you had better get working on those core systems (save system, UI, progression, level structure etc) so you’re not lying to yourself how much actual work is left before you can ship.
 

5. Fix bugs as soon as you see them

KermitComputerBug.jpg

Ok this one is going to sound odd. But I had a zero tolerance bug policy. That meant if I saw a bug, I would fix it immediately. Anything that I felt uncomfortable shipping with would not make it into a build. This probably sounds crazy to you and a ridiculous time sink, and maybe you’re right to some degree, but it has some huge advantages:

  • When you first notice a bug, chances are it was in the code you wrote last. If you fix it right away, you’re likely to be able to fix it quicker because the code is fresher in your mind. Don’t underestimate how terrifying it is to return to code you wrote a year ago and realise that you have no idea whatsoever how it works.

  • The version of the game on my laptop was always demoable, meaning I could also make a build at any point and it would be playable without bugs.

  • When I came to shipping the game, I had no bug fixing period. This is completely different to how I was used to working in AAA. I was adding polish and features right until the end. I rewrote the entire save system 2 weeks before shipping. That may seem like madness, but if you’re constantly testing and fixing bugs all the way through development, there isn’t the need to have some stage at the end where all you do is fix bugs.
     

6. Always have a playable version of the game to show people

As a solo indie developer, you don’t have a QA department. You’re going to find a lot more bugs in the game if other people play it. I had friends playing the game from the beginning of development till the end, young and old. Kids in particular will play your game and break it in all kinds of weird ways. 

So having a recent version of the game that’s always playable is really handy, particularly useful on mobile when you can just have the game always on your phone. And don’t just send it to people - watch them play it, even if it’s over video chat. I asked literally everyone to play my game. Even totally random people I met at events.
 

7. Be super strict when choosing a publisher

KermitMeetsPublisher2.jpg

Partnering with a publisher is like getting married. Seriously. It isn’t something you’re going to walk away from easily, especially once you have your first kid! Choose carefully and get in touch with a developer that is currently partnered with them and ask them about their experience. Also ask yourself what is the publisher bringing to the table that you couldn’t do yourself or by paying a PR company. They have to really be offering tangible benefits (or money) to make it worth signing. 
 

8. Getting noticed is everything

KermitGettingNoticed.jpg

There’s one thing that impacted me more than anything else working on Hang Line - discoverability. The hardest thing about making games in today’s marketplace is getting people’s attention. As a new indie developer, unless you find a way to market your game effectively, you are literally creating something in a void. People’s senses are assaulted by new things every second. The competition is insane. 

People choose a lot of strategies to get their game attention, such as juicy development stories or outside the box methods of growing a community. But to me the most important thing is actually this - WHAT your concept is. Now I won’t even consider working on a game unless I believe it’s something that is remarkable enough that people would feel compelled to share with their friends on social media, forums etc.


9. Play to your strengths

KermitTyping.gif
 

I was a very beginner programmer when I started Hang Line. Whenever I had any complex system I needed to build, instead of doing it myself, I searched online to see if anyone had done something similar before. Github and the asset store were incredibly useful resources for this. 

Also, I wasn’t an artist, I didn’t know how to texture and I had very basic 3D modeling skills, but I’m an experienced photographer and know a lot about composition. Instead of focussing on trying to build amazing environments, I used a low-poly style, found a way to generate that style for the environments procedurally, then used a ton of lighting, camera and post processing techniques to compose the scene as well as possible.

My strength is in creating innovative real time action mechanics from years of working on AAA shooters like Bulletstorm. I built Hang Line around this strength. The heart of what makes the game unique is the smooth simple controls and fun interactions between all the hazards in the game like the goats, rocks, mountain cats etc.
 

10. Become at peace with failure

It can be really hard making your first game as an indie developer, using up your savings  and not having a clue whether you’ll find any success. I had a lot of anxiety and some very dark times during Hang Line’s development. 

But one thing a friend helped me realise is that it doesn’t matter if you fail, because you would have become so much better at what you do. Working by yourself or in a tiny team means you are stretched so much that the amount you learn and grow as a developer is just insane, and that experience is something you’ll have forever. Once I realised that, it made me feel much more at peace with the game potentially being a flop.

 

End Note

This is part 2 of a 3 part article. You can read the next part here:

Hang Line Postmortem - Part 3

If you'd like to be informed when I write a new article or if you are at all curious about what I’m working on next, you can sign up to my newsletter: 

DinoBoss Newsletter

Or if there’s anything you’d like to ask, feel free to reach out to me on twitter @edform.

See you next time!

Ed

Ed Kay is an independent game developer and owner of one man game studio DinoBoss, responsible for goat grappling action game Hang Line.

Read more about:

Blogs

About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like