Podcast
Mighty Bear Games | Identifying million dollar game concepts

Simon Davis, Co-Founder and CEO at Mighty Bear Games, joins Melissa Zeloof on our "What I wish I knew when" series to talk about his process for identifying and evaluating new game concepts, the learning curve he's experienced, and how to avoid bias.

Listen to the episode here or read the edited highlights below.

Where the idea for Butter Royale came from

It wasn’t something we explicitly set out to do. As a studio we have a whole focus on “accessible multiplayer” - that’s our thing. Mario Kart is a classic example of this - racing games traditionally are not that accessible, and they turned it into a deep experience that anyone can pick up. 

There was one concept the team created that we didn’t go through with called “Calamari Royale”, and it was very hardcore. At that point the seed of the idea for a battle royale game with food themes was planted. 

Then Apple approached us to ask if we had ideas for titles for Apple Arcade - we went back to our idea bank, because we had a very short time frame to make the game for Apple (we built Butter Royale in 6 months), and we were looking at Calamari Royale, and we decided to flesh out the concept and evaluated it against 7 or 8 other concepts, and we realized it was one we could execute within the timeframe - which was essential in the decision making process - as well as being really fun.

How to come up with new ideas

Just start, and get your team into the habit of writing down their ideas. Show them what good looks like, in terms of a high level pitch...we have a format for that - maybe 3 bullet points, a mock up screenshot, a tagline and a name. If you can convey the idea in that format, then you already have something.

Having a key framework is super important. I mentioned “accessible multiplayer” earlier - the team has that framework, which has evolved over time, and they know what the criteria are, what we value, and that already steers things in the right direction. 

Given we’re so small, I’d rather we focus on specific areas of specialisation and become experts on that.

Reinventing the wheel or using familiar mechanics

There’s a case for both. Some companies are design-led, Apple is a fantastic example of that. You look at other companies doing a lot of A/B tests, focus group tests, but that’s not how you build novel products like the iPhone. It’s the same with game studios - some have that capability and approach and it makes sense, but others are much stronger on the data side and iterating and finding something that really works. 

There’s a big risk of doing something completely different or new, especially if you’re publishing your own game. From a marketing and UA side, there’s going to be a lot of unknowns and a lack of expertise from both a product and publishing perspective. 

But if I was playing devil’s advocate, if you look at gaming’s two most successful games on desktop today - League of Legends and Fortnite - they’re essentially iterative. Fortnite builds on other Royale games that came before it, and LoL follows on from what DOTA did. In general the biggest hits in gaming have been improvements on existing formulas, but if you can land on an amazing formula from the off then you have this amazing blue ocean for just yourself - it’s a huge opportunity.

Using market intelligence services to help ideation

I’m not sure this is the best way to start [using app market intelligence tools to generate game ideas]. It’s healthy to have a strong thesis as a studio, sit down and understand what you’re good at doing, the team’s strengths, their interests…

For example, we had this approach for our first game - we looked at the market and said, “MMOs have this amazing long-term retention, monetize really well, and there’s a huge opportunity for a casual MMO”. But that game didn’t really work out - one of the reasons was that the team didn’t have the level of enthusiasm for that genre. 

You have to be really honest about what you can do as a studio and where people’s interest lie, because [when] someone who really loves the concept, like we have with Butter Royale now, the quality of work is very different...you can really feel the love when you pick up the game, and you can see the team is really passionate about it. 

Only at the point where we had a thesis did we begin looking at games and genres on these services to identify spaces where there were opportunities for us to do our own thing.

So for “accessible multiplayer”, there’s a couple concepts we have within the studio that aren’t shooters but do fit the team’s interests, and we have gone in there and looked at metrics like retention, CPI (cost per install), RPI to identify where there are underserved markets and potential opportunities.

Other ways to generate ideas

I’ve been to many hackathons and I’m yet to see one deliver a game that launched. We try to encourage our team to have the hackathon mindset all the time. 

One time the owner of a large franchise came to us and said “hey, would you like to make a game based on this?”, and we went away and dissected it as a group of people, within the Mighty Bear framework, to see what works, what doesn’t work, then we sent some people away to come up with ideas. We let them do that in their own time, giving them the framework and space to help their ideas gestate. 

Evaluating the potential of game concepts

It differs studio to studio. For our framework that we shared on the LevelUp blog, a lot of it was based on postmortems from other games where we analyzed what did and didnt work. 

When we describe Mighty Bear to someone, “a royale game with food where you shoot people with food until they pass out”, people always smile or laugh. So one criteria we have now is, when we describe the game, can we make people laugh? Humor is one of the most important things to determine if we build a game. 

Another critical criteria is time-to-market versus resources - we have a rule that we don’t develop any games that we self-fund that can’t go to beta in 6 months. People say that’s very aggressive, but its a great way to be really focused and ensure you have a very strong MVP without superfluous features.

The dangers of bias

Bias is real. One of the challenges we’ve had as a company is that not everyone is great at being objective about their own ideas. 

When you have a live game and the numbers aren’t conclusive, it’s a very dangerous trap. Studios can die because they spend a year or two trying to turn around a game with below average metrics. When learned to work around this after our first game - we released an MMO and we spent 18 months on it, with 8 guys...if I’m brutally honest we could have killed it slightly earlier. That was a learning experience for the studio - once you’ve greenlit a game and its gone live, you have to be very aggressive with it and know when to cut it. I’ve seen a lot of studios die because they’ve not had the courage to “kill their baby”.

Applying this to Butter Royale

It was pretty straightforward. We had 5 or 6 games that we thought were candidates for the Apple Arcade project, we put them into the framework,  and we sat down to sanity check the numbers [the framework requires giving a score/number to various aspects of the game’s potential].

We have a strong culture of dissent, people will openly challenge things, dig into the scores that were given, until there will be some kind of consensus around what the values would be. By the end of that process, we had two game concepts that we presented to Apple and they really liked both. They had similar scores on our criteria framework, and so we asked the team which they were most excited about. 

Common mistakes and final words of advice

“I like it and therefore it must be good” - there are a lot of assumptions with people not actually backing them up with data. 

(...) Build a framework to try and eliminate bias. When you have everything written with numbers it is very stark. Don't blindly follow the market opportunity and don’t try to build an MMO with 8 people! 

Let's put these tips to good use

Grow your game with ironSource