How to build your first mobile game? And an indie company…

Rubiks Digital
Creative Strategy Blog
5 min readJun 3, 2015

--

Today we’re releasing our first full-featured mobile game “Jumprs” that we have been working with for more than a year now.

We also created a new indie company called Monday Moustache but working lean, we really believe in delivering & testing first and then building the company. So instead of thinking what should our company look like and what kind of games is it going to build, we have really just been focusing on our first game. Because that’s what really matters — you’ll see how it feels like to build a full mobile game, you get to know the team, you see how it goes and if something doesn’t work out here, it’s also the end of the company.

It all started in January 2014 when my old classmate Marko approached me and said: “I have a really simple game idea…” (we’ve been laughing on it since. It’s actually something that 90% of our regular clients say as well). Marko is our visionary, idea author and designer. He put together a great team which was also the main reason we decided to “invest” in the idea.

The team Marko had invited together included a great designer Kristi, former Nokia employee and life-long sales & business professional— Samuli from Finland. Then from Rubik’s, our developer Rauno and I have been most involved with it, but also the rest of the team has been testing and supporting the whole thing. So we had a nice team, but we had almost no experience in building mobile games (to exclude some of our weekend projects like the FingerFolk App). To fix that, Marko invited to the team his old friend Kaarel from MobiGrow who’s team has developed some pretty successful mobile games like Can you Escape with more than 10 million downloads. Kaarel has been the one to help us solve a lot of questions regarding how to build a killer global game.

So we had the bad-ass team together (the most important factor for any successful game and company) and we started working with this “simple” game in February 2014. And yes, today is June 2015. So the first lesson — if you’re thinking of a simple game, it probably isn’t so simple.

And that’s the thing with mobile games — it’s not really about the idea, it’s about the details and execution. In my mind there is no such thing as an elevator pitch in mobile game industry. You could pitch me some of the most successful games of all times and I wouldn’t care less. Like Clash of Clans — a very typical strategy game, optimized for tablets, lot of crazy monsters. Or Angry Birds — birds flying into a wall. Those games are all about execution and details. Angry Birds is built on some really heavy physics equations and it was a result of the team’s tens and tens of unsuccessful games where every one of them taught them something. Supercell (author of Clash of Clans) has turtles, birds and even butterflies flying around in their heavy war games scenery, so small that you can only see them when zooming in. Those are the details that make people love the game. Not the idea alone.

Those details are the things that take most of the time in building a mobile game. Usually the initial idea can be implemented by our great developer Rauno in a matter of hours — our first prototype of a box falling down from a box was ready in a couple of hours. So the rest of the time has gone on the whistles and bells that really make the game worthy — and no we don’t have butterflies yet… But we do have birds. Tough ones they are.

To be fair — for this almost 1,5 years we didn’t work on this project full time, all of us were working with other projects as well. But at least the work never stopped. Of course we didn’t expect it to take so long — I think our first goal was end of summer 2014. Then in Slush (in November, 2014) we told people about January 2015, then March, April… and now we’re finally live! We obviously didn’t want to work so long with it, but more than finishing on time, we wanted a great game. And we could have actually continued building it much further because a great game is never ready and there is always something more to add. But me and Samuli (the business side) really started to pressure our creative side to finish it because it would’ve gone a bit ridiculous — we can still continue to build the game, but we need to test it now and get some feedback from the market before we continue.

Last couple of months have really gone on testing — we have been putting the game in front of our friends, kids, moms, drunk people, psychologists, log workers and many others. Every time Marko gets some really good feedback, he says: “Erik, we need another month.” So testing is extremely important to really make a great product. Our main confidence has actually come when kids played it in our first months (when it was still very rough) and continued playing it. And wanted more. Being in the process yourself, there is no way to exactly predict what works and what doesn’t. If you want to reach your users, you have to understand them and ask them. It’s also good to have people in your team who has different amount of contact with the game — so some test it every day, others maybe once in a week or in every few weeks because first impression is great but you want your users to stay playing for months.

We have also got some real interest from investors but we didn’t want to make the mistake of raising money too early — we at least need to have our first game out before we even think about it. So yes, as a proper Indie company — we have funded the project ourselves.

It has been a great beginning of the journey, including a lot of learning and mistakes which we can take away in our future games. Today, it’s time to let our first Sugar Glider out to see if it can fly… And if it hits the ground, we’ll learn from it and start again. With a boost.

Download Jumprs for Android here!

by Erik Ehasoo, Innovation Adviser & Futurist

--

--

Rubiks Digital
Creative Strategy Blog

Digital Innovation Group providing training programs and consulting on digital innovation discovery, execution and scaling.