Starting up a business: Learnings from hunting investments


Juha Vainio, CEO & Founder of Epic Owl

It has been a while since my last blog posting so it’s definitely time to write about something I have been up to. Most of my time in the past six months have gone to finding an investor willing to back us up in the future. Instead of investors I have gained tons of insight and want to share some of my key learnings with you. Here you go…

For background, Epic Owl’s strategy from the start has been to develop a small-scope unique mobile game for hardcore gamers, use it to prove our team’s capabilities and raise money to enable the development of our massive second project. This is what we set out to execute and we have definitely managed the first part, i.e. the development of Starside Arena. It’s a strategic free-to-play multiplayer game set in space and we, a team of 5 developers, made it from scratch to soft-launch in 6 months. Quite successfully: the metrics are good and the target audience loves it. The only thing we failed to do was to get a huge pile of players for it, but it shouldn’t matter since the priority was to use it for raising an investment?

Well, as I said, we haven’t found an investor yet so there must have been something wrong with the strategy. I have talked to about 100 investors and while a good number of them is excited at first, no-one has walked the last mile. Here are my own reflections as to what the reasons are, based on the discussions with lots of investors, mostly from China, Europe and the US.

The team

Our team is relatively young and we don’t have an average of 15+ years of industry experience. This was one of the issues we wanted to tackle by developing a smaller-scope game at first. But even though our track record in the past (at Rovio Entertainment Ltd) is good and the execution of Starside Arena development was outstanding, investors seemed unconvinced still.

The first game – small

Starside Arena is a niche game for specific target audience and while it resonates really well with that audience, some investors couldn’t see the appeal there and thus the decision to invest was made harder. The metrics were good but the number of players we managed to get for the soft launch was so small the investors couldn’t trust the numbers we were giving them. All in all, even though the production was a success, the plan definitely backfired here. For a new game studio such as Epic Owl, it would have been safer to go with something more mainstream, at least IP-wise. Space-themed mobile game is definitely something investors don’t like.

The second game – huge

We thought that a huge game production would be something that, in addition to being something ambitious that we would really like to do, be interesting for the investors. But in retrospect, probably not so interesting.

As you can read from above, our team was very young and our first own game was a small-scope project. Diving into a huge one (I’m talking about production scope 6+ times the size of Starside Arena) does seem foolhardy at best. We had no concrete evidence about our capability to take on such a project so backing it up would be a highly risky move for the investors.

The competition

Something we definitely did not understand when we started the company was how many small game companies there are. We also overestimated the value of being hotshot game developers from Rovio and being located in the mobile game development hub of the world, Helsinki, Finland. The selections as the #1 hottest startup from Finland (April 2015) and #1 hottest gaming startup from Finland (December 2015) by did little to improve the situation.

Most investors interested in gaming had their portfolio full. Mobile gaming companies have been hot potatoes for a while and investors have been enthusiastically investing for them some years now. At the moment they seem to be concentrating more on seeing what comes out of their investments instead of making new ones.

Also, mobile gaming isn’t so hot as it was a year ago. New platforms such as VR and smart watches are coming and some investors want to make quick wins on those.

So for just another mobile gaming company we were left with a limited number of investors and limitless number of just-another-mobile-gaming-companies competing for their attention.

The lack of publisher

From the start our attitude towards publishers has been very negative. There are lots of stories about small companies being screwed by the publishers so we wanted to steer clear of those and concentrate on self-publishing.

If we would be starting up now, our attitude would be different. There are great publishers out there, helping out with QA and especially with marketing and UA, something a small indie company cannot really tackle. The investors know the problems in self-publishing so without a publisher, the investment decision for them is harder still.


If we were starting up now, the things we would probably do differently:

  • We would get a publisher
  • We would start hunting investors earlier and with more attitude
  • We would be more humble about our chances
  • We would be more realistic about our plans

Here you go! I hope you can find some of these experiences useful and as always, I’m very open to all discussions. Thanks for reading! If you want to check out Starside Arena, you can find it HERE for both iOS and Android.


– Juha

Starting up a business: Learnings from hunting investments

Design Journal – Part 7

10846474_10204406722182005_6572617469039303669_nRisto D. Holmstrom, CCO & Founder of Epic Owl


Hey everyone! It’s been some while since my previous post: we’ve had the launch of our first game, Starside Arena, and it’s kept us all quite busy. I’d like to share the experience and future plan with you today.


As with any game you’re working on, you should always aim for the launch. As a designer, you’ll never be perfectly satisfied with whatever you’re releasing. There’s always going to be that small detail that ain’t there, a tweak needed in the balance, the polish on that UI panel. The bigger your budget, team and development time, the less you’ll end up having these perceived shortcomings. In Epic Owl’s case we had to prioritize delicately throughout the production to compensate for many practical limitations. The end result is a game that, from my designer’s perspective, has most features on the “good enough” level, but more importantly, is a functional and unique title. It may sound like I’m giving the game a hard time, but it’s quite the opposite. We stayed our course, focused on the core game and shipped on time. That’s a grand feat on its own. Keep this in mind and don’t demand the impossible of yourself. If the core game works, you can build it further later. Just release when you can.

Now for some learnings. When you’re making a game for the mobile, you want to consider the preferences of that particular audience. We knew our title would be less for the typical mobile gamer and more for the invested, experienced one. This is an extremely difficult distinction to make on the design side. As advice to any designer reading this, be very conscious of who you are intending the game for. Based on our metrics and direct feedback, it seems we did actually hit a good spot with this. Of course there are gamers who would’ve liked an even more in-depth, hardcore experience, and there are casual users who find the game too obscure. It’s going to be impossible to please everyone. However the vast majority of our players has gotten along well with the design as shown by good retention figures and feedback. At this point as a designer I have to keep my eyes open and continue studying our player base to determine whether the game should take a more hardcore or casual turn in the future. You cannot decide who discovers your game, but you can decide to tailor the game for those that do.

If you’re making a title for a broad user base, you’ll get a lot of people who are accustomed to the mobile free-to-play micro transaction mindset, and have no issues digesting your version of it. Our targeted gamer demographic is a different thing altogether. Many hardcore gamers eschew the idea of payments in games, and implementing them is a trivial way to throw off your desired audience. The economy was designed with respect to this dilemma: payments are not required to advance or to be competitive, but they can improve your performance (and scratch the itch to play more). Very few users have experienced this design as obtrusive or demanding. Additionally the metrics have remained excellent: perhaps it is indicative of a maturing player base that can appreciate not feeling extorted or pressured.

One of Starside Arena’s central missions was to make a truly unique title. While I would say the game is a great success in terms of both novelty and enjoyment, it has definitely not been an easy target to reach. Novelty becomes a great challenge for several reasons. First of all, you have no idea whether players will enjoy the game or not. There is no live proof of your concept, and everything you design is based on theory and conjecture. Second, you have no way to draw reference from similar titles. This means you have to come up with all the mechanics and interactions from scratch. This applies to the core gameplay loop, the pacing, economy… pretty much everything. It makes a designer’s work arduous at best. In hindsight it would’ve been smart to have more parallels between other games we could’ve referenced, but then again Starside wouldn’t be the snowflake it is. A third major issue is business reliability. Many potential partners are hesitant to jump onboard with something they can’t relate to another success already on the market. For them it’s risk management, for us it’s lost potential. Funny how these kinds of matters also impact design. As a designer and gamer I’d love to just focus on the game, but in the real world it doesn’t work that way. These angles are good for any designer to keep in mind.

The game’s never going to have everything you’d like it to. The backlog always bloats faster than you can empty it. While our players are truly enjoying the game, they’d also like to see options in places that have none, more diversity where things are plain; I understand nothing better than the desire of a gamer who wants more out of their new treat. Probably the biggest lack as of now is a flat meta-game. Things that would flesh it out are such as teamplay, multiple ship live combat, guilds, diverse missions and targets. I’d love to have all of these. But, as a developer, I also need to be realistic. Adding in good quality guild play, for example, takes many months of work. I need to put everything in cost / value order and prioritize based on this. This means the game will have to take smaller steps at this point, but it doesn’t mean those steps can’t be meaningful. Our plan going forward is to maximize the value of the game with the best effort to value ratio possible.

Volume means everything. You could theoretically have the best game in the world on your hands, but if no one knows it exists, it’s worth nothing. The road of an independent developer is a rocky and unforgiving one. The market is staggeringly saturated; this is why we at Epic Owl decided to take a different angle and create something fresh, something that could hit a niche spot that is yet to fill. We succeeded in this target, but it has not brought us enough momentum yet. The cold truth is money begets money. You need hard cash to start up your game and to have any hopes of growing the player base further. There are of course options of teaming up with third parties (such as publishers) but this brings us back to the novelty issues. It’s going to be tricky convincing someone of your title’s worth when there’s no reference point, and to create reliable metrics yourself you’d need money for user acquisition. It’s a chicken-egg problem. Plus of course third parties may want to alter the production, and for us it’s a priority to make the game on the game’s terms. Lessons learned: novelty will be nigh impossible without large initial capital. Familiar design stands a better chance with third parties and suffers less from external input.

To bring this all together, I’d summarize: Starside Arena is greatly liked, has a core following, is a veritably unique title and we managed this ambitious design and production in record time. The challenges will be finding the visibility and improving the meta-game, both of which are under work at this very moment. The business perspective challenge is daunting, but our mission remains the same. We will keep prioritizing the novelty and quality of our games above all else.

And, to conclude, a TL;DR checklist for all you curious ones out there:


  1. Understand the requirements to realize your design. Cut out everything you don’t need and never stop focusing on the core.
  2. Be mindful of who you are designing the game for. Making the right game for your audience is everything.
  3. Study your economy. Don’t just take a monetization template from another title and slap it on yours. Tie it in with the design, and design it with respect to your players.
  4.  Stay aware of the production schedule. Always work on the highest priority, and prioritize based on the impact-to-effort ratio. Keep moving forward.
  5. Have money. Lot’s of it. If you don’t, think very carefully about how much risk you can take with your production. Your capital defines the safety boundaries of your design. If you ignore this (like we consistently do), be prepared to fight windmills.
  6. Trust in your game. If we all took the path well tread, the world would be a dull place. Don’t be afraid to do something new. That’s how all the best things were discovered.


That’s all for this time. Hope you enjoyed the insights of Starside Arena’s post-launch learnings! And now… I am off to keep working hard on making this the best game it can ever be. If you wan’t to follow the game’s progress and have a blast designing your own future warships, go get it HERE for both iOS and Android.


Keep it cool!


Design Journal – Part 7

Starting Up A Business: Minimum Viable Products


Juha Vainio, CEO & Founder of Epic Owl

This time I would like to write about the concept of Minimum Viable Product and what it means in the context of Epic Owl’s game production. This topic was inspired by my recent debate in Twitter with Game Design Guru Warren Spector who read Risto’s latest design article (Part 6) and commented that he thinks releasing MVPs show contempt for the audience. Needless to say, I had to comment on that and explain why I think MVP is an important tool for any game developer and has nothing to do with contempt.
More than anything, I see MVP as a mindset, a way to recognise what is important in the game and what is not, a way to tighten the focus. If you’re not focused, you are more likely to end up with a game that tries to do too much and face the danger of doing nothing very well.
I can clearly see the Warren’s point on how MVP can be done wrong and Minimum Viable Product is an excuse for the earliest possible mess that can be called a game. I think the biggest difference between the way Warren thinks and the way I think is that I define myself what the MVP means for me. If I respect the player, so will the MVP be respectful. Every release for us at Epic Owl is a complete high-quality package and we define it by the feature set in the scope, not by cutting the quality.
In addition to keeping the scope tighter, I also believe any piece of software, be it a game or something else, should be put into real use as soon as possible to get the real feedback from the real users and have the possibility to revise the design and see what is not working. By getting feedback and iterating we end up with the game the players want. Everybody wins.
How to go about defining your MVP:
As mentioned in one of my earlier articles, at Epic Owl it’s me and Risto (CCO of Epic Owl) who balance the design, the scope and the schedule together. Risto is responsible for the design, I’m responsible for the schedule and we meet at the scope. Our discussion is often around MVP – A version of the game that we can get out as early as possible, fulfilling its purpose as a game, i.e. fun and entertaining, engaging and retaining.
Defining your MVP comes down to prioritization, as always. Identify all of the must-have features you haven’t implemented yet. Then identify the nice-to-have features. The rest – just put them in the backlog, you won’t be having time for them. Prioritize the features within each category and put them in order. Estimate roughly how long each task takes.
Then start fighting with your designer (or producer, depending on which one you are yourself) on where you should draw the line. See yourself as the player playing the game with the features above the line. See also the feasible time-frame you have for the implementation. Try to form a logical package. Use your common sense. Use your common sense again. Tell your designer (or producer, depending on which one you are yourself) to use his/her common sense. Tell him/her you are running out of time and you just need to release it at some point. Take a break. Continue the next day.
At the end, you will have your Minimum (Producer) Viable (Designer) Product (Game) defined.
Let’s take a look at our first game which is at soft launch as we speak:
First version we released was little more than the core game, fun in itself for us and our testers but we needed to see if it was fun also for the general public. Wouldn’t have made any sense developing the game further if the core didn’t work so we soft-launched the Core in Canada and Indonesia. As it happened, our analytics showed that the core was enjoyed very much by the audience and it made total sense to move forward.
After a few weeks we launched the first update. From the initial launch we had identified some pain points and we already fixed the biggest ones here. This version was much better than the first one but wouldn’t have been unless we had launched the first version and gotten the data.
The second update we are about to submit any day now. It is a significant update, adding a couple of major features, half-a-dozen-or-so smaller ones and lots of fixes. The difference between the first version and the third one is huge. But without launching the earlier ones, we couldn’t have identified the holes in the design and couldn’t possibly have made the great version we’re now about to submit.
We still have one update to go before our global launch. Each update is taking us closer to the perfect game. We could have taken all this time without making any soft launch releases, just working the existing feature backlog. We would have a game, yes, but what kind of a game? Possibly a good one. But very less likely a great game that we already can see ours to be.
And hey, it doesn’t end in global launch. We will continue the development, iterating, getting feedback from the players, implementing features that are requested. Update by update, MVP by MVP.
MVP is a useful tool to have in your game development tool case but as always, you need to bear in mind what you want to achieve with it. As a rule, it’s always makes sense to review your processes from time to time and verify they serve their purpose. Otherwise you face the danger of spending your time doing things that take you further from your goal (The Perfect Game) rather than taking you closer to it. MVP is no different – make sure you do it to take you to your goal, not as an excuse to release crap.
I’d like to thank Warren Spector for taking the time to read and respond to our blog and for the inspiration for this piece of writing. It’s always good to be challenged and have the opportunity to see your processes from the eyes of another and reflect upon them. Thanks a lot! And thanks everybody for reading, as always, comments and feedback are very welcome.
– Juha
P.S. If you happen to be in Canada, the game I’m talking about is available HERE for free.
Starting Up A Business: Minimum Viable Products

Design Journal – Part 6

10846474_10204406722182005_6572617469039303669_nRisto D. Holmstrom, CCO & Founder of Epic Owl


Hey all! Today I’m breaking the radio silence with a look into designing the next step for your game. We’ve had a busy time getting the MVP version of our game done, which means that we’re at an enticing spot. The core game is there, but beyond that we’re talking mostly about a bare bones product. Now is the time to improve what we’ve got and build what we need.

Now as a designer it’s my nature to view the game and see a whole world of stuff that could be better. We’re all trying to make a perfect title here, but now’s not the time to slave over the fine detail (too much). As discussed before, our mission is to make a deep, diverse game, and while polish does play an important part in this, it’s more important to step back a little and have a look at the bigger picture.

Now I’m standing back and looking at it. Yeah, it’s a fine game. Got loads of awesome stuff, some rough edges – nothing we couldn’t iron out. But should we dedicate all our efforts to tweaking and smoothing it out? Let’s forget about that for now. We need to identify the largest, most brutally gaping hole this game has. And, sure enough, after a thorough session of contemplation we find a culprit.

Using Celestium (our Hard Currency) allows players to buy stuff in the game they don’t have Credits for (our Soft Currency). A typical scheme and very straightforward. Battles reward you with ample amounts of Credits. While a perfectly functional setup in most cases, we realized that with some users who hoard piles of Celestium, Credits become obsolete. This inadvertently discourages the core loop as you retain little to no benefit from battles.

It’s quite clear now that we need to have alternate methods of spending Credits. The big question is how to go about this. In situations like these you, as a designer, are typically faced with two options: make a fix to the mechanics, or create a new feature. Both resolutions have their own pros and cons. Fixes in core mechanics tend to have repercussions on other unintended parts of the game, tilting the game from another corner, but if designed well they can be unobtrusive and clean solutions. New features bring about a lot of excitement and possibilities, but tend to bloat the game and harbor danger of diverting focus from the proven and functional core game. A fix is inherently less painful to create when you factor in the workload on your team, so that is naturally what I’ll be looking into first.

After theorizing with multiple fixes, ranging from limiting Celestium purchases to removing Credits altogether, I concluded that none of these ideas are enjoyable or feasible. Then it is time to approach the option of a new feature, and giddily did I this task approach. Since we were going to plug in a new feature, I might as well swat another issue while at it. The plan was to make a Credit sink that would further diversify the gaming experience for our players.

While in earlier stages of development I find it good practice to approach design in an analytical and scientific manner, I do not believe this mindset is the best one for a new feature at this phase. So I play the game vigorously and gradually transform my perspective from game designer to fanatic player, and once the transition is complete, I think of what the feature that I, as a player, would love to have. The answer comes surprisingly naturally.

The new design has to enable massive Credit spending, and it has to tie in beautifully with the nature of the game. The core game is built around competition and battles, so that’s what I’ll design around. The battles are normally one-on-one spaceship duels against another player, but I’ve long wanted to have larger scraps involving more players. Technical limitations made it impossible to run such a mode in a similar, high detail format on the mobile, but now we have an opportunity to create that mode in a different manner.

The design of what I call the FFA Arena (free-for-all) was born. Players buy entire fleets of ships with Credits, and once their setup is ready, they send them off into large scale melees where there could be up to 50 ships involved. The battle is simulated on the server and the result is sent back to the players who can subsequently inspect the battle report. Ships destroyed in the FFA mode are permanently destroyed, so both the risks and rewards are higher. The mode does not reward new Credits (lest it counter its purpose), but instead grants large amounts of Experience, and even small surprises of Celestium.

The end result is a feature that allows big spenders and risk-takers to earn well deserved boosts to their progression speed, that enables players to engage in massive battles against their peers and is hassle-free and neat. But, above all else, it serves its primary function as a Credit sink incredibly well.

So, let’s glance through this in summary. The foundation of your game is done, and now you need to build and improve on what you have.

1. Identify your game’s most pressing problem.

2. Does addressing the issue require a fix or a new feature?

3. Understand what the Player wants.

4. Design the fix or feature with respect to the Core Game.

5. Implement with passion.


That’s all for this time! Perhaps the next blog will explore the unforseen hazards of shoving in new features…


P.S. If you happen to be in Canada, the game I’m talking about is available HERE for free.

Design Journal – Part 6

Starting up a business: The first game production

Juha Vainio, CEO & Founder of Epic Owl

As my fifth Epic Owl blog posting I decided to write about something that is very topical for us at this very moment [July 2015]. Our very first game has now been submitted to soft launch in specific markets and while we wait for the metrics, I’m going to describe how we did it, production wise.
Here goes, enjoy!
The Premise
When we started, we knew that we had money to operate for about a year, including the possible public funding we were going to apply for. This meant that our first game couldn’t be a behemoth of 2+ years of development time, we needed to start with something that can be produced from scratch into a full-fledged product within the timeframe of about 9 months. With the planned soft launch period of 3 months, that left us with 6 months of development time for our Minimum Viable Product.
In January 2015 we had the quick prototype ready and the preliminary playtesting suggested that it’s a winner. We needed to start the planning of the production.
Production Phases
The first thing we did was we divided the project to a set of phases, planned their content and their length:
Phase 1: First Playable, 5 weeks
Building of the production environment and developing the first playable version of the game in the production environment.
Phase 2: Pre-Alpha, 4 weeks
We divided the full feature set of the game in two parts. In Pre-Alpha, roughly half of the feature set was to be implemented.
Phase 3: Alpha, 6 weeks
In Alpha the full feature set was to be completed.
Phase 4: Beta, 6 weeks
In Beta we were to develop the rest of the content for the game.
Phase 5: Soft launch preparation, 2 weeks
Final phase before soft launch, in which we were to polish the game for soft launch.
In retrospect it’s easy to see how well the production went. Even though we did have our share of setbacks and changes in the scope and we iterated on many aspects of the game, our soft launch submission date was only 4 days later than what we planned 6 months earlier for it to be.
When talking about Scrum, one of the questions to be answered is the question about the length of the Sprint. Usually we’re talking about something between 1 and 4 weeks. Balancing is the key; the longer the sprint, the more you sacrifice the agility. Shorter the sprint, the more you have overhead. But the most important thing is to consider what suits the team and the project.
Initially, what we decided to do was to start with weekly sprints for maximum agility and then move to 2-week sprints when the project got more robust after the First Playable and we would be able to plan for 2 weeks ahead.
After reaching the First Playable milestone, however, our way of working was so established around the weekly cycle and we still felt we needed the agility provided by the 1-week sprint, we decided to continue using it. So in fact, we are still working with 1-week sprints and it works, there’s no real pressure to be changing it.
I have used Scrum with about 10 development teams and one of the most difficult things there is is scheduling the Daily Scrum. This project was no exception.
Usually I would like the Daily to take place early in the morning, for everybody to start their day by planning what they are going to do and also let others in on it. Therein lies the problem. Working with game teams especially, everybody’s got their own rhythm. As a leader, I’m all for allowing people to work when it suits them the best. As a manager, it gives me nightmares!
In a perfect world all people would wake up early, be at the office at 8am and we’d have the Daily at 8:15am. At some point with one team I was able to have the Daily at 9am, which is already a very good accomplishment. Usually with game teams, we’d have the Daily at 10am, which is OK. At Epic Owl, we scheduled the Daily to start at 11am.
Not too bad, right? Still in the morning but late enough for everybody to get to the office in time? Well… After a few months of fighting windmills and several mental breakdowns by me, we finally moved the the Daily to start at 12pm. Not the ideal time, no, but it is crucial to have everybody participating in the Dailies consistently. If that means that our dailies start at noon, so be it. And to be honest, it’s not too bad. Some people come to the office by 9am but everybody is at the office by 12pm so things are flowing smoothly and the Dailies fulfill their purpose.
Day by Day
After planning the production and setting up the needed processes, it was time to execute. Sprint by sprint, phase by phase. We implemented, iterated, tested and re-did.
As you may be aware, we are working with the two-headed eagle management structure: I’m responsible of the game production and Risto [Holmström] is responsible of the game design and creative department. This works perfectly and we are getting the best results by me pushing for keeping the schedule and Risto pushing for higher quality. It’s a perfect match, neither is ever happy but the balance and the friction will result in the best possible product in the best possible time.
All in all, everything went as smoothly as in any production and slightly surprisingly, I can’t find anything insightful to say. We executed the plan and suddenly we had the product in our hands. Almost.
The Last Mile
The Last Mile. The Release Candidate. We’ve now built something that can be called our Release Candidate. This is always the most difficult phase of the production. We already have everything we need for the launch. Except for a few small features and some bug fixes. The stress can be seen on everybody, we’re so close we can touch the goal but we’re not there yet.
There are some bugs. Nothing is crashing the build but it would be great if we could just fix these. And, one of our play testers suggested that there is this feature that would make all the difference for her. Easy to implement.
Yes, I’ve seen this all before. And it’s always the same. I get to be the one who tells everybody that we’re not making this or that easy fix or feature. Even though we all know the game would be better with them. This is one of the most difficult phase of the production and here are some reasons why it’s absolutely crucial to keep your head calm with any changes:
  • Vainio’s Law #1: After RC, the smaller the bug you are fixing, the higher the probability to introduce a Critical Bug
  • Vainio’s Law #2: After RC, adding a small feature will result in at least two subsequent RCs trying to fix it
  • Vainio’s Law #3: The Release Candidate cycle of death: After RC, if you add/fix something, the time it takes to fix the subsequent RC will be used by one of your coders to fix something else, which subsequently breaks the following RC and it will take time to fix, which one of your coders will use to fix something else, which in turn will break the subsequent RC, which… Ok, you get the point.
Of course, sometimes the feature is actually worth doing and the bug worth fixing, even after RC. To help myself put it into perspective, with every additional RC build fix, I add at least a week of production time (in addition to the actual implementation time) and prepare for it. If the fix is seen to be worth the extra production time, then it will be done.
The Soft Launch
“Ship it!” – And we did!
Thanks for reading, I hope you enjoyed this! As always, I’m happy to discuss these things with you and answer any questions you might have.
– Juha
Starting up a business: The first game production

Design Journal – Part 5

10846474_10204406722182005_6572617469039303669_nRisto D. Holmstrom, CCO & Founder of Epic Owl

Hey again! Today we go back to some broad basics for a change. Successful mobile game design involves more components than I’d even care to list, especially in the free-to-play environment which this blog will discuss. While most of your active design work will revolve around tweaking how your game communicates, keeping features consistent and clear, you’ll still want to be sure the underlying design philosophy deserves an entire production’s worth of toil.

In previous blogs we’ve gone through many ideas on how to design that awesome game. This time we’ll have a closer look at what a F2P mobile game’s success ultimately boils down to and how to maximize your chances of getting there. Here’s the thing. It’s all about Retention.

In all its simplicity, retention is a fancy word for describing people coming back to your game. Good retention means you’ve got people playing, talking about the game and eventually paying for the ride. You need this for your success and for the likelihood of your studio affording its next production.

So, let’s get down to it. Retention is determined mainly by two factors:

  • Does your game appeal to the player?
  • Do playing sessions feel meaningful?

Let’s go through these in detail.

1. Game Appeal

Revelation of the year: a good game has appeal. But you already knew that. You wouldn’t be making a bad game, that’d be stupid. While people have different ideas of what makes a game good, they do agree on several matters. The general topics you should be thinking about when trying to design for maximized appeal are:

Communication. Fluid, responsive and intuitive design of the user interface. Players have short attention spans and little patience for walls of text. They fired up your game for enjoyment, not a lecture. Design for intuition. Make your controls and navigation such that they won’t keep people guessing how it works. Every pointless tap or interaction or any interaction that requires pointless precision (such as closing a window only through that tiny X in the corner) is bad. The smaller number of physical interactions you can reduce your operation to, the better it feels.

Preferences. Players enjoy different things and it’s important to recognize and respect this in your design. While your core game is likely designed with a particular focus in mind, try not to utterly dismiss the players falling outside your main audience. Some people like beating other players, others prefer sharing their expertise. All in all you’ll probably connect with most desires if your game offers possibilities to Compete, Learn, Achieve and Share. There are other ways beyond the “share on facebook” methods to achieve this. Use your creativity and make those features support your core game – not dilute it.

Cleanliness. Everyone enjoys a polished product. Sometimes if the game is extremely good and has a devoted fan base, imperfections can be forgiven. But more often this is not the case, and even if it was, you’ll want to make sure your game is as neat and bug-free as humanly possible within a reasonable development time frame.

2. Meaningful Sessions

Players enjoy the feeling of their time being well spent. Two separate factors dictate this impression. Can the player complete a core game loop during one reasonable session, and does completing this loop build towards anything.

When your single core loop is rewarding it’s usually enough to make the game worth firing up now and then. The logic is simple: your game offers easy to chew bites of entertainment leading to some measure of instant gratification. This emotional reward cycle should be tied closely with the soul of your game. Perhaps it’s collecting resources from your town, passing a daily challenge level or, as in our case, claming victory over another player with your superior space ship. Bottom line being if the player enjoyed their break with your game, the single session was meaningful.

Even so, repeating the same loop for no real end purpose grows tiring. This is where Progression comes in. Progression can take many forms, all of them equally important in dishing out reasons to return to your game. The three most common forms are Power Development, Exploration and Learning. A well designed game can offer progression on all these fronts.

Growing in Power is simple: usually this means something like leveling up, gearing a character or building a base of sorts. This allows you feel the development in your capabilities very concretely from session to the next. Then, Exploration is a form of progression that requires raw content to make possible. This can mean having exciting new areas to discover, technologies to unlock or game lore to immerse in. For a certain personality understanding and knowing the world is a priority. And Learning is just what the word entails: the player getting better at the game with practice. A lot of contemporary games have short learning curves and low mastery ceilings compared to games like Chess or Go. Pushing the ceiling higher yields players a longer (or even infinite) path towards excellence. The feeling of gradually attained mastery over any topic is a very powerful motivator.

To summarize these ideas, your players will come back to the game if they have a good reason to. That reason varies individually, but you’ll have pretty good chances if you make sure your game offers:

  • Great Usability
  • Player Interaction
  • Long Term Goals
  • Constant Progression
  • Enjoyable Single Sessions
  • Vast Content
  • A Polished Experience

And that’s it for retention this time. Stay tuned and stay awesome!


Design Journal – Part 5

Starting up a business: Starting up a business in Finland

Juha Vainio, CEO & Founder of Epic Owl

As my first blog posting I wrote about decision making in the context of founding Epic Owl. As my second blog posting I wrote about getting public funding for the company. The events depicted in my fourth blog posting (this one right here) take place somewhere in between those two events. Indeed, this is again in the series of a newbie CEO finding out how the world operates.
Now, the decision has been made to start the company and applying for the public funding looms somewhere in the very distant future. What should one do? Answer: Seek help.
Seeking help
In Finland, there are several instances you can contact for support when you’ve decided to found a company. Me and Risto went to meet EnterpriseEspoo where we bounced around our business plan and got confirmation on many things we already suspected. Pretty much everything can be found on the web anyways but it always makes it easier if you can talk to someone who has the core expertise readily at hand.
After the meeting and a brief training seminar arranged by EnterpriseEspoo, I knew all the theory there was to know. Next step, registering the company.
Registering the company
My non-competition clause from my former employer ended on 28th December, 2014 so naturally 29th December, 2014 is the day Epic Owl came into existence. In Finland, you can found a company by following this five-step plan:


  1. Register the company in PRH (Finnish Patent and Registration Office) using YritysTietoJärjestelmä ( with the minutes of the founders’ meeting, corporate by-laws and electronic signatures of each founder (29th Dec, 2014)
  2. Establish a bank account for the company (2nd Jan, 2015)
  3. Pay the initial stock capital (min 2.500€) to the bank account and get a stamped confirmation about it from the bank (2nd Jan, 2015)
  4. Finalise the registration of the company in YritysTietoJärjestelmä (2nd Jan, 2015)
  5. Get the approved papers from PRH (14th Jan, 2015)
With careful planning and taking into account the New Year, we had everything finalised by 2nd January, 2015. Now we officially had the company, we had a great plan and strategy to execute, now we needed the means for it.
Already in November 2014 there were a couple of insider people who knew we were entertaining the idea of founding a company. Naturally, with the talent such as the Epic Owl core team, it wasn’t a big secret for long and we were contacted by some very interested seed investors. We started negotiations with one that seemed to suit us the best and actually turned out to be a very solid seed investor for new gaming companies with the greatest of people involved. With our strategy and our game idea, they were pretty easily convinced we are the team to invest to. In addition, three of us founders put some money in and we got the rest from the FFF sector (Family, Friends, Fools).
So, now we had the company and at least on paper, we also had the money. The money itself we wanted to put to the reserve of invested non-restricted equity (sijoitetun vapaan oman pääoman rahasto) instead of the stock capital of the company. But how to actually get it to our bank account? Answer: Issue new shares.
Issuing new shares
In the pages of PRH you can find information on how to organise and register your new shares. The pages describe a two-phase process but we learned it makes more sense to handle both phases simultaneously, at the end of the process. We actually lost several weeks in bureaucracy and ended up scrapping our original registration and starting from scratch with the both-phases-at-once process.
Step 1: Shareholders’ Meeting about issuing new shares
The first thing to do when issuing new shares is to have a shareholders’ meeting and decide upon it. With PRH it is recommended that the new shares are registered (i.e. the process is finished) within one month of the date of the meeting.
Remember to write down as many details as possible into the minutes to prevent complications with PRH. Some key things we needed to have in the minutes were:
  • The participants along with the share numbers they represent
  • What is the immediate economy-based need for issuing new stock
  • The amount of money to be raised with the new shares
  • The number of shares to be issued along with their price
  • The names of the investors purchasing the new shares
Important Note: Do not write down the final four digits of people’s social security numbers in the minutes, PRH won’t accept it as an attachment if you do.
Step 2: Better Call Saul, i.e. Lawyer Up
After fiddling with the share issuing and PRH for a while, it was suggested by our investors that we might want to get a lawyer to handle the bureaucracy involved. It obviously costs a lot but it might prevent some considerable losses and hassle later on.
Not wanting to miss the learning opportunity, we set up a hybrid process where we did as much as we could ourselves and hired a lawyer to point out caveats, offer insight and proof-read the documents. This worked well. Still cost a lot, though, but not as much as it could have.
Step 3: Shareholder Agreement
The most critical and time-consuming phase and the most important document involved, the Shareholder Agreement. It’s a good idea to start iterating this with the new shareholders as early as possible. We ended up using a template from here:, with quite many changes, pointed out by ourselves, our lawyer and our investors. After about 10 iterations, we got a version that suited everybody and could proceed.
Step 4: Stock markup lists, Cap Table and paying up
After getting the Shareholder Agreement done it’s all downhill from there. Next up, you need to write a document called markup list, where you state the price of your shares, the number of shares to-be-purchased by each shareholder and your bank account details.
The shareholders then sign the lists and pay the shares to your bank account.
You also need to update your Cap Table and company shareholder lists, here are a couple of examples:
Step 5: Final registration
Now it’s finally time to register your new shares to PRH with their proper form (Y4). If you marked the new shares into the reserve of invested non-restricted equity, remember that the stock capital increase is 0€. Here are the attachments we managed to pull this through with:
  • Minutes of the Shareholders’ Meeting
  • Board members’ and CEO’s signed confirmations that the share issuing was done according to the relevant legislation
  • Receipts of the payments made by the investors
  • Receipt of the registration payment for PRH
Now you have your company and your initial seed money to operate it. Time to execute your strategy. And find more money, for instance some public funding that is described in more detail in my earlier article (
Thanks for reading, I hope you enjoyed this!
– Juha
Starting up a business: Starting up a business in Finland