“From a ‘Proper Job’ to Indie” is a series of articles that describe what it was like going from Full Time employment into the world of Indie Development. Last time I talked about the daunting list of Business / Admin tasks you should tackle once you get started. In this article, we’ll focus on more game-related matters that should happen early in your dev-cycle.
You’ve left your job and gone Indie because you have an amazing game idea, with a rock-solid plan to execute it. You’re busy setting up the company, registering domain names and all that stuff I talk about here. Now it’s time to look at tasks that contribute more to the game making process. Here’s what I did on Abandon Ship:
Play Reference Games
If you’re like me, you’ll initially be wracked with guilt for going Indie – any second you’re not contributing to the codebase feels like you’re failing, so stopping to play some reference titles felt like the worst work-avoiding ever.
But you have to get over this, and force yourself to do it so that you learn from other people’s work.
Identify which games are worth your attention and prioritise them in a list. Buy one at a time and play it enough to become familiar. Set a time limit for when you’re going to stop playing, and write a “Game Analysis” document that talks about the strong points, weaknesses and what is applicable to your game. Look at the critical reception; what reviewers commented on, what the User Reviews are like and compile this into the document. It’ll give you a broad picture of the game and any important takeaways.
But don’t stop there. If there are mechanics that are similar to ones you’re planning to implement, reverse engineer them on paper. Write down how they interact, how long visual effects last, whether animations break-out, whatever is applicable and useful. Essentially you should be learning lessons from games that have come before you.
For Abandon Ship, the list of games I played for research was as follows:
– AC: Black Flag (100% completed this before I went Indie)
– FTL (Played 45 hours before I went Indie and a further 5 afterwards)
There is a strong chance you’ll have already played some of the games in your list, as I imagine you’ll be making a game in a genre you’re interested in. Sometimes you’ll be playing games because you feel like you should have knowledge of them rather than taking direct influences from them. For example with Windward, I felt that I should play this because it’s got Age of Sail Ships, Exploration in a Procedural world and had achieved some commercial success. Even though those are quite limited ‘surface-level’ similarities to our game, it was still enough to warrant my attention.
Sometimes analysis doesn’t even have to be of whole games, but snippets of them. I revisited the Kraken boss fight in Shining Force 2; one moment in a vast game because it had relevance. How do ships move in the Total War campaign map? These were all questions that other games had answered, and while you might not be influenced by everything you look at the point is you’re getting a better idea then you had before.
There were more games I wanted to investigate, but that’s as far as I got and I doubt I’ll fit any more in because you get busier as time goes on. But you know what? I should probably find the time, as it’s a very useful exercise.
Consume Associated Material
This is similar to playing competitive titles, but in other forms of media. Identify anything that is suitable for your game and immerse yourself in it. Read Books, watch Films, TV shows, Documentaries, listen to tonally-appropriate music, do web-based research – anything that can inform your games-making process.
I used to work next to Portsmouth Historic Dockyard, so I visited HMS Warrior and HMS Victory to soak up what it was like on those ships. I visited the National Maritime Museum and art galleries around London to look at naval oil paintings that were suitable reference material. I’ve read / am reading a stack of books, not just about Age of Sail ships, but ones that are nautical and tonally appropriate. I’ve had a keen interest in this sort of thing most my life, so it helped to draw on materials I’d experienced before, but can you imagine someone making a game like this and they hadn’t watched Master & Commander?
Write up Designs
You won’t hold every idea in your head, so write them down. This may be to get your head around a complicated feature or just a bullet list for an idea you thought of, but won’t implement till later. Your mind will be jumping around a lot of areas, so in a week, a month, a year you may find that write-up useful.
Refine your Core Pillars
A good early step when you first come up with your game idea is to write down the core pillars, which help establish the most important things about your game. At this point, once you’ve been developing for a while, it’s a good time to revisit these. They will no doubt have changed, and a refinement helps keep them relevant and focusses your mind on what’s important.
Learning Area’s outside your Comfort Zone
Being an Indie Dev is to live within your means, particularly at this early stage. For me, even setting up a simple character was something I’d never done before, but with a wealth of online tutorials available you can push through.
As I was so used to working in larger teams, this was a topic I struggled with in particular. If an asset was needed I could call upon a specialist in that area to create it. But remember at this stage it doesn’t matter if its poor quality, it just needs to work well enough to prove out the idea you’re prototyping.
Research your target audience
As a PC-based game, I spent some time looking into the data available that could help inform relevant decisions. Look at what your competitors estimated sales were on Steam Spy. Look at the latest Steam Hardware Survey to see the most common configurations (having a 16:10 1920 x 1200 monitor I was really surprised to see just how few people have a similar setup). Analyse Steam traffic to get an idea of which countries are good ones to focus future localisation efforts.
And last, but certainly not least; the reason we’re here:
Making the Game!
In other words: Prototyping. You should know what to do here, after all it is the reason you’re an Indie Dev. This is where you find the fun, prove out ideas and riskiest area’s, make failures, learn from your mistakes and iterate while it’s cheap (i.e. all in throwaway greybox assets).
In it’s very first prototype Abandon Ship started out as a completely top-down game. There was a screen divide between the two ships. This was a good starting point for us and proved the core combat would be fun, but there was a weird disconnect when the cannons were fired and the projectiles went across the screen divide. While we were investigating solutions to this problem, we thought we’d try a single camera at a more isometric angle, and tilt it depending on the ship distance. Not only did it solve our particular problem, but it worked with the gameplay and we liked what we saw. So we pushed the game more in that direction. That was a crucial moment in the games development, and ultimately led to the game you see now. Your prototyping should be achieving similar goals; confirming your ideas will make a good game. And if they don’t? Come up with ideas that will.
Now you should be up and running in all aspects – but unless you’re a one-person team, at some point you’ll be looking for others to join you. In the next article, we’ll focus on expanding your team.