You can ask this of a hundred different game devs and likely get a hundred different answers, some will skew more towards the “build it and they will come” mentality – if you want to play it, others will. On the other end of the spectrum you have the Product Management-driven strategists who want to identify a growing or underserved genre and make a game that fills the gap (I once attended a game conference panel where these were the differing points of view of two of the speakers).

Additionally you have different structures and environments of the game dev studios themselves. If you’re a one-woman band you have to worry less about this but as soon as you have two or more people involved the decision making process gets more complex; is your process more hierarchical or distributed? Both have pros and cons.

So I can’t say that this is the process in which you should determine what game you should take into production, all I can tell you is this is how we at Black Salt Games are going about it.

1: Come up with ideas we like

So this probably feels like we’re more towards the “build it and they will come” side of the spectrum, but note the plural — we don’t just come up with one idea for a game we like, we come up with multiple ideas. Our theory is if we’re only choosing from ideas we like, we’re always going to like what we choose!

We summarise the idea, identify the core game loop and point of difference from anything we know about and brainstorm up the next.

2a. Core Game Loop Prototype

Quick and dirty — in this initial prototype we’re not looking at things like art or even technical delivery, we’re just asking ourselves whether the idea put on paper works as an interactive experience and hits the core elements we were hoping for. During prototyping our idea will evolve into a design and things we thought might work turn out not to, and so we iterate and tweak. In scoping the prototype we always try to narrow the idea down to its absolute minimum set of features or narrative to test everything works together to engage our player in the experience. 

Our prototypes usually take between 80-160 hours to make and we aim for 20-40 minutes of playtime.

2b. Playtesting the Prototype

We like to explore our gut feeling but also validate as early as possible and so part of our prototyping pipeline is playtesting. There are multiple benefits of playtesting including usability (does the game communicate well enough so the player knows what to do, and can they do that?), balance and pacing (is the player having the experience I’m intending them to have?) but at this stage we’re really looking at whether the playtesters are engaged in our experience; 

• How long do they feel they’ve been playing vs how long they actually have?
• Would they play more if you didn’t stop the session? 
• What did they find fun about the game? 
• What frustrated them? 
• What would they remove from the experience / What felt unnecessary?

After playtesting the prototypes we might have some clear stand-outs, or we might just need to start back at the beginning. 

For our playtests we try and pick players within the demographic we would target for the game and run between 5-10 people through each prototype.

3a. Market Research

And now we swing to the data-driven side of the spectrum! Say you have three prototypes; all game ideas you love and response from your playtesters was positive across the board. How to choose? Even if you only have one you like, how do you know whether it would be worth your time building it over something else (even if you don’t know what that something else is just yet)?

Our next step is to look at what games are already out or announced that might fit into the same category. In traditional Product Development this is called competitor analysis but in this [like so many other ways] the game development industry differs: people enjoy playing games from the same or similar genres to other games they like so in this case we call it Analog Analysis.

For each of the platforms we’re wanting to target we explore the genres related to our game; 

• How many games in that genre all up? 
• How often are they being released? 
• How many Coming Soon titles are in the pipeline?

Then we narrow in on games that have points of similarity with our own; 

• When was it released?
• How is our game reminiscent of it?
• How does our game differ from it?
• How many hours of content?
• How many reviews does it have?
• In what do the reviewers say the game did well?
• What did the reviewers not like about the game?

You can often find additional information about these games if the developer is awesome and has things like retrospective or post mortem articles on  Gamasutra  or  GDC talks  (after all, as a game developer you’re often the most painfully aware of areas that rub your players the wrong way and a big thank you to those who share the lessons they’ve learned with others!) 

In terms of estimating sales of games this is a tricky one because unfortunately there’s no published reports that detail that sort of thing, a better mind than mine has done the mahi though and you can check out Jake Birkett’s approach  for more details.

3b. Technical project scoping

No matter how awesome the idea is, if it isn’t feasible for us to create it in the time we have available then that one has to go on the shelf for now. At this stage we’re not thinking about writing a massive Game Design Document, detailing each feature and estimating it out, instead we’re looking at the game from a much higher level, e.g.; 

• If the game idea relies on a rich and immersive narrative do we have someone able to write that?
• Would the game need a lot of custom 3D models and animations? How long would each of those take? 
• What would need to go into having a really well-balanced system in a vs multiplayer?

We put a big consideration into what the Testing and QA requirements are going to be, for example building a multiplayer game might immediately require two real life players to test a lot of the aspects, if you’re a small team that might mean other things like art and development slow down to help test.

So once a game idea gets through each of these steps we’re either feeling as confident as we ever will be about greenlighting an idea into production or we feel secure in our decision to not pursue it!

Hei konā mai!

Photos by Tima Miroshnichenko and Startup Stock Photos from Pexels