In the last part we looked at how you can analyse your target market through analytics, and the importance of a soft launch. In this part we will look at how to break down your game and time cost the components so you can estimate the time cost of your project, as well as how to effectively manage the development of these components. We will also discuss how to work out your cost per hour of the project, so that you have an idea of the potential profit/loss you stand to face before it happens.
Getting timing right is hard
Effectively time costing the components of a video-game is very tricky. A video-game is made up of so many varied components, it can often be very hard to gauge how long something will take due to everyone’s workload in some form or another depending on another person’s work. I’m a big believer in Agile project management when it comes to managing any size game project, of any size team, and I’ve written about it before in detail at: www.indiegamelaunchpad.io/finding-the-time/
In a nutshell, Agile lets you tackle that behemoth of a project in small chunks, whilst constantly inspecting yourself and making everyone aware of problems and successes. After each chunk is complete, you talk as a team about what went well and what didn’t and plan the next chunk based off the back of the previous chunk. So you’re always adapting and becoming more efficient at planning and time costing your development. And that is what you want, to be at peak performance at the end when it’s all crazy and you’re near launch, rather than still at the same place as you started in terms of motivation, efficiency and progress.
I’m not going to go into too much detail about agile here, but I recommend any indie developer try it. However, what we are going to talk about is the importance of the vertical slice. See, like analytics in the last article, you can’t really gain any benefits from agile until you’re already making your game. But by making a vertical slice first, you can use agile to measure and adapt your performance, test our game mechanics, and best of all get a more efficient start to the real development of the game.
A vertical slice is a demo of the game, that shows every single proposed component in some shape or form, to the minimal level. Essentially a showcase of what the game would be, minus almost all of the content. You might have a single level out of a multi level game, containing all the mechanics found in later levels for demonstration. Or maybe you have a small sandbox showcasing the game’s mechanics and best content to date.
In the end, a vertical slice is a pivotal asset to have both in terms of your design and potential funding of the game. A vertical slice lets you as a developer trial the game’s mechanics and detect what actually works and is fun whilst stripping out or replacing what doesn’t with new mechanics.
On the funding side of the spectrum, a vertical slice is a great tool to have if you wish to pitch to publishers, platform holders and gatekeepers to funding for project or business funding.
Working out the cost per x of the project
It’s always good to understand how much your project will cost you, in total, as well as when broken down into chunks of development.
First, begin by costing up all the outgoing expenses of the project, this could include website running costs, licenses etc.
Next, include any cost of salaries.
If you’re an indie developer and not paying yourself anything currently then this part is less simple for you.
Finally, you need to know how long your project will take. If you haven’t made a vertical slice, whilst employing agile to get more efficient and record everything as you’ve gone, then it’s going to be a rocky start as you won’t really know how to estimate this number and it’s always going to be unreliable. That can be negated somewhat if your team has operated together before, but generally, it’s a bad idea to jump right in and pull numbers out of hats.
If you have employed agile as a project management tool on some kind of project or vertical slice or demo already, then you will have a product backlog containing all the features and content needed to complete the game release, prioritised in terms of importance. You’ll also know how to give time costs to each of those items, as you’ll have past development to look at so you can base your costings on what’s actually been happening, rather than what you hope will happen.
Now work out how much is the minimum you would like to get paid per hour to be considered a human being, this is called your survival rate. You can use the time cost of your project against your survival rate to determine how much the project will cost you when you give some context to your own time spent as a developer.
If you now compare everything you have learnt, you’ll be able to work out how much the project is likely to cost you versus how much you are likely to make. Always bare in mind that there is the potential to make absolutely nothing, prepare for it instead of avoiding it.
Join me next time, where we will discuss many of the various funding opportunities available to indie developers, as well as how to develop and give a pitch for your game to potential investors. I’ll also discuss how to contact funding sources and media, as well as how to make your own press kit.