In this piece, HypeBeard’s Alex Kozachenko discusses how to decide what to build based on your (team’s) strengths and weaknesses.

Written by Alex Kozachenko, CEO at Hyperbeard

Business isn’t always sexy. In fact, it usually isn’t. The common myth in game dev is that creative people get together, build something super cool and new, and then it explodes and makes a ton of money. That’s the outlier. Building anything new is extremely risky because there is no proven market. Most new things, as super cool as they may be, never make it to launch or flop, face-first into financial despair. While some have an aptitude to do that (often with funding from others), repeatedly, most don’t. Nor do most have the financial liberty of going down that path.

Don’t get me wrong. The entire gaming industry is thankful that these outliers exist because they open new areas of financial growth. But as an indie developer looking to make a living from making games, doing something new and super cool is not your best bet. Not only from a product “will users like it and play it” perspective, but also from a marketing “how will users find out about and download it” perspective.

Thankfully, the roadmap is clear enough and it’s based around your strengths and weaknesses as both an individual and a team. It’s fine to start with the following question:

Passion “What do I want to build?”

This is typically how most game projects get started. And it’s an important one because when a team is passionate about something they tend to perform better than if they are not passionate about something. But you also need to ask:

Execution: “Is my team capable of building this type of game?”

There are lots of considerations that go into this.

1. Technical Feasibility

How complicated is this game from a technical perspective? While game engines like Unity have made it substantially easier to build games and the infrastructure that supports them, there are still massive differences in complexity in the types of games that can be built. Building a single player game is infinitely less complex than building a multiplayer game. Does your team have experience working with asynchronous or synchronous multiplayer games? Or are you going to try and figure it out on the fly? Do you have an engineer with enough experience to tackle this task? Is this where you want to be spending a lot of effort? Technical feasibility is a really important factor to think about beforehand as it can have a massive effect on your timeline and polish of delivery.

2. Game Design Considerations

Different games are played differently. Duh. For example, word games are great. Have you built one before? What about a dungeon crawler? Past experiences with different game genres carry over some principles but many are different based on the audience that game attracts and how it carries over into how that audience retains and monetizes. Oftentimes the best way to break into a new genre is to try and copy as many parts of popular games in the genre before you start trying to differentiate your feature set. You’ll only end up copying a maximum of ~75% of the feature set anyway because you can’t peek behind the hood to see what decisions were made or why they were made. So your game is still ‘unique’ but maintains the core parts of the genre that make it work. Win-win.

3. Time Constraints

Oh boy. I can’t tell you how many projects I’ve seen that are over scoped and under delivered. Every project we’ve ever worked on at HyperBeard has taken longer than expected, and we’ve had some pretty tight deadlines. You’ve got a personal life. You need sleep. So do your team members. And you likely don’t want to be working on one game for many years (again, there are outliers). How long is it going to take to build the game you’re planning? Now double it. My general rule of thumb is that if a game’s core loop, for mobile games, cannot be condensed into a 6 month development cycle to the degree that we can put it on Beta and get data, then it’s too complicated. Simplify your plan. You’ll thank me later.

You don’t have to have a 100% match on passion and execution. Inevitably there will be parts of every game project that are a grind and not super fun. But you want to try and limit those in your planning. The last thing you want to do is spend 10% of your time building the game that you wanted to build and 90% of your time figuring out all the problems that you didn’t think about before you started the project. This often leads to burnout and projects getting shut down. What started as something fun has become a grind in the worst way possible. Now that doesn’t sound like fun at all!

Game dev should be fun! And if you’re trying to make a living out of it, it needs to be profitable. Build something you’re passionate about but stay conservative in your plans. Under-scope and overdeliver. You’re not trying to win the lottery with every game you make. Be smart, set creative constraints that make sense for you and your team, and you’ll end up enjoying the experience a lot more along the way.