Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • Ten Lessons I Learned While Making My First Game

    [05.05.20]
    - Ed Kay
  • 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

    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

    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

    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

    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.

    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

    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.

Comments

comments powered by Disqus