This year at GDC I spoke about soft launching games. A deep dive into how Wooga looks at soft launches, and specifically what you can expect in terms of Cost, Learning and Growth.
Soft Launching in 2011 was much easier — especially because of the free traffic through facebook virality
Soft Launches are more important than ever
Wooga learned this the hard way with Agent Alice. You have to validate your LTV & CPI before launching if you want to launch with an effective marketing budget.
Soft Launches aren’t cheap
Futurama and Max Ammo’s costs were around $250,000 for 5 months of soft launch. This is user acquisition costs only.
Wooga Soft launches now typically take 4-6 months, this is mainly to give time for both Validation (ensure LTV > CPI) and Growth (attempt to improve metrics before launch).
You can use Low CPI Countries, but only to test, not to validate
Don’t use the KPIs ( LTV, Retention ) in your Low CPI test markets to validate your game. Wooga has found that these KPIs change unpredictably from country to country. You can only predict a hit in your key markets (usually Sweden and Canada)
Retention is more influenced by Marketing User Quality than Features
Don’t just look at your day-to-day or week-to-week retention to see the impact of your changes. It’s very easy to inflate or deflate your retention profile by adjusting your marketing mix (what % of your users come from which acquisition source).
The only way to see real impact of your changes in Soft Launch is to A/B test
If you NEED to see the real impact of features you need to A/B test. But because Soft Launches have such low DAU, the time needed to get real results from this will drag your soft launch timeline out.
Growth of Retention is SLOW
We at Wooga typically see an average growth of our retention numbers by 0.5 to 1.5 percentage points per month (1d/3d/7d). So if your retention numbers are far off your target, its going to take a long time to get them up.
Large Retention Jumps are usually improved with: Funnel Optimization, Tutorials and Difficulty Adjustments
Large Retention jumps don’t typically happen, unless your game is fundamentally broken.
The largest bumps in retention that Wooga has seen have come from 3 things:
Funnel Optimization: looking for where users drop out
Tutorials: optimizing and paring down the tutorial
Difficulty Adjustments: looking for frustrations and smoothening progression
Growth of Monetization can be done
We at Wooga have seen that monetization can grow, especially during post-launch.
So if you’re LTV CPI equation is not working only because of monetization, you can still grow monetization during post-launch
Overall: Soft Launches will not save your game.
If you don’t see strong metrics during Soft Launch, then don’t expect the Soft Launch to give you the clear learnings of how to fix and grow your game to be a hit. Costs are high, Learnings are difficult, and Growth is slow.
In August I spoke at GDC Europe in Köln about the independent team structure at Wooga. Not everyone knows this, but at Wooga, each team has the final say on all decisions regarding their project. The CEO & Management cannot tell the team what to work on. The team decides on everything including what technology to use, what genre to go after, and how to execute on it.
This talk is about the challenges and benefits of working with this structure for the last 3 years. Its a structure that gives full creative control to teams, but also the full burden of responsibility.
My topic is “Saying No to the CEO: A Deep Look at Independent Teams”. I’m looking at the management practice of fully autonomous teams in a large studio. From my experience at Wooga, I’ll be discussing both the benefits and drawbacks to working with an independent structure.
Specifically:
– How to construct an independent team culture that works
– What benefits you can expect from an independent culture
– What the limitations are of this culture, and what problems to expect
– What requirements there are to company culture and employee personalities
Looking forward to the event! Contact me on twitter or email if you’d like to meet up while I’m there.
Every project that I’ve seen fail, the team always says one thing in their Post-Mortem: “We should’ve done more Pre-Production!”
It is the tell-all excuse. Teams always place the blame on the Pre-Production phase.
Why didn’t we figure this out before we went to Production? Why did we rush into production when there was so much left to solve? How did we not see the monster this game would become?
How do we solve this? How do we get to the point that we avoid projects going into Production that are just going to explode in scope or the design falls apart?
Mark Cerny’s “Method”
Back in 2002 during a DICE Summit, Mark Cerny, a Producer on various Naughty Dog projects, presented “Method”. Mark Cerny offered a solution to the problem that faces complex game development: a better approach to Pre-Production.
Mark argues that most games fail solely because they haven’t done Pre-Production properly. Production is not the time for teams to be discovering what will make them successful.
This was presented in 2002. Game Development has changed drastically since then. For instance, developers now can release at the press of a button. We now use soft launches and analytics to test games while live. We don’t have the weight that comes with having to launch a physical product. However, despite the benefits of modern game development, much of what Mark speaks about still applies. Many projects fail, pointing back to a failed Pre-Production.
So what can we apply from this talk to modern game development?
“You will spend a million dollars before you know what your game is…”
There remains two distinct phases in Game Development: Pre-Production and Production. Pre-Production is for when you are “capturing lightning in a bottle” a.k.a. identifying what makes you different, what will make your game a hit game. Production is for when you know you have a hit, you just need to deliver it.
The goal of Pre-Production is to reach a state which you are confident that your game will be a hit.
Pre-Production is also about defining key variables, economies, mechanics enough such that you can start producing final content for your game. Yet to reach this ideal point is extremely difficult.
The Journey to Production
Pre-Production phase can last a long time, and can’t really be tracked. Finding how to pull all the pieces of a working game together into a publishable package is a very elusive process that can take months or even years. Free-to-Play games in comparison to traditional PC games I would argue have more moving parts. Session design, economy design, social mechanics, elder game design must all come together on top of having your core gameplay completely nailed down.
My rule of thumb is Pre-Production for free-to-play games should last anywhere from 3 months to a year. It will take you at least that long to properly prototype & iterate your metagame and economies. If you aren’t taking this much time, then you’re either cloning a game (in which you don’t need Pre-Production nor a conscience), or you aren’t spending enough time nailing down your game’s design. How long you need in Pre-Production is dependant on the team’s experience level. If you are creating a game within a genre you know, this can take 3 months. If you are exploring genres you have never created in this can take at least a year, if not more.
Pre-Production for free-to-play games should last anywhere from 3 months to a year.
A whole year on Pre-Production? That seems ridiculous! Yet in reality, spending this much time in Pre-Production pays dividends during production. If you reach this ideal — having a clear definition of what makes your game unique, all game variables are defined and your metagame is nailed down, Production becomes near trivial. When you scale up your team, you will spend far less time in Production. So instead of Production taking years on a game with 20-30 people, it takes just 6 months. You will avoid many pivots that happen in production, when the cost of change is very high.
So be prepared to spend a million dollars in Pre-Production. It will be worth it come time for production.
“A Publishable Prototype”
The goal of Pre-Production is to define what makes your game great. Prove to yourself, your team, and all stakeholders that this game will become a success. The best way to do this is to produce a complete prototype which proves your game is great.
What does a complete prototype look like? It is an ugly, cheap version of your game that is playable on device. But it has the full game loop: all the economy systems, all the gameplay mechanics, and everything that you think is absolutely required to prove that your game will become a success. All in one prototype. It should feel as close to the final game as possible, while being as cheap as possible to produce. Art can help, but should not be the focus.
I choose a complete prototype over a bunch of small prototypes because game design is extremely interconnected. To truly prove how your game will ultimately feel, you have to put it all together. The effects of a design decision are not always apparent until you play with the systems interacting with each other. This can take more time than necessary, but this has proven time and time again to identify unseen problems in my own game design.
Complete prototypes identify problems that separate prototypes can’t.
The team’s role during Pre-Production is to produce this complete prototype. Build the experience of the final game as quickly as possible. You will find that through many iterations, what you initially felt was going to make the game successful changes with each release. This is natural and necessary. When you build a complete prototype that feels as close to the final version as possible, many issues arise that you typically wouldn’t find out about until close to launch. The key with prototypes is to build your game into the monster it will become as quickly as possible.
But when is this prototype done? When are we ready for Production?
To define how to reach Production, I create a checklist. This checklist provides a vision about what we must prove before we enter production.
To create this checklist :
Conduct a Pre-Post-Mortem, imagine how your Project could fail. Define what the biggest risks are for your project:
Define what must be amazing in order for your game to be successful.
Define what can kill the project you if you get wrong.
Define what assumptions must be confirmed before you start producing final content.
When you feel confident that you’ve done all you reasonably can to hit each of these points, then it is time to move to Production.
Just keep in mind:
“Your Product will not miraculously get better in Production”
If there are core design problems in Pre-Production, don’t expect them to go away with simply adding more content in Production.
“A cancelled product is not a reflection of the team’s ability.”
The goal of Pre-Production is to do everything possible to kill your game — not to protect your game from any chance of failure. As a team you must eliminate risk and spot when the risk is just too high. Killing a game in Pre-Production needs to be accepted. Killing a game saves money, time and years of emotional strain on any team member involved. A failed prototype is a celebration.
Summary
The keys of a strong Pre-Production are:
Make time for exploration and defining what makes your game great. Give at least 3 months to 1 year depending on the experience of the team.
The team must be focused on delivering a complete prototype which reduces as much design risk as possible.
To enter Production, you must define your design risks. Create a checklist of these risks and ensure they are fixed before entering production.
As massive scale 3D productions become the norm, a strong Pre-Production process will become far more important.
Last week I attend Quo Vadis in Berlin and gave a talk on the title above. The slides are below.
My main take away was that companies need to set themselves smart constraints within which to be creative.
The four ideas I gave for setting yourself smart constraints were:
1. Know your strengths
Whatever your strengths are, be that an existing audience, particular technical expertise, or genre knowledge, you have to build on that. The market is tough enough without you giving yourself the best chance.
2. Find your pond
Incumbent games have too much market presence and content and too many systems and players to go head to head with. Define your market as a niche that is small enough for you to dominate (though big enough to pay the bills).
3. Manage the Risk
All game production is risk management – no one knows for sure if a game will be a success or not before it launches. Make sure that you manage the risk in production as well as possible. Do a risk assessment as you start out a project to get an objective feel for the number and scale of risks involved, and an idea of when they can be addressed (sooner is better!). This will also help you tackle the biggest risks first wherever possible.
4. Stick to the plan
It’s very easy half way through production, when things aren’t going well, to convince yourself that you just need a couple more months to fix things. Set yourself some fixed targets at the start of the project that trigger a full scale review of the project if they are missed. That way you will waste the least amount of time on projects that are doomed.
Starting a new game is a daunting task. You operate in a design vacuum. The possibilities are nearly endless. The chance of failure incredibly high. Logic and reason of what games make it to the top is alchemy, and mostly just biased observations. Coming up with what the next hit game will be is a bit like throwing darts while blind.
From years of starting projects from square one, I’ve found a process that works for me. A process that helps me get off the ground quickly and moving on an idea that can work in the market. The process is mostly adapted from “The new business model canvas” as well as many Lean and Agile Product Vision processes.
Creating a new game is about firstly identifying a potential market, then building empathy for that target audience, using the empathy to design a concrete definition of your product, and then testing this vision as quickly as possible with real end customers. This vision will drive the development of your game.
To even begin, you have to start from some inspiration.
Step 1: Find your Blue Ocean
Natural Motion’s “My Horse”. A game that is targetted towards fans of horse fans of all ages. A blue ocean for the App Store.
My strategy is to find a blue ocean. Find a market, a niche, a genre, a player type that is currently under-serviced by the top grossing games.
Natural Motion has spoken multiple times about this approach to their games. My Horse, CSR Racing and Clumsy Ninja are all masterful games that were targeted at blue oceans. When My Horse was released, many of the games that were targeted towards horse fans on mobile were unpolished, 2D, and a terrible experience. Natural Motion came out with a product that really hit what this market wanted: realistic 3D horses. Players can pet them and watch the horse react realistically. They could care for them, and even pick up their shit. Exactly what fans of horses wanted!
When working out of XMG Studio in Toronto we were a very small, indie developer. We knew that we couldn’t fight for market share against the larger developers in crowded genres. Instead, we chose to focus on niches that we felt we could hold on to : Car fanatics and Fashion. We created Drag Racer which held the mobile racing market very well from 2009 – 2012 as well as Fashion Star Boutique which remains one of XMG’s top grossing hits. They were hits because we operated in spaces that many of the bigger developers wouldn’t. We could sit on these games and carve a large market share for the small niche with ease. Aiming for these blue oceans is a viable strategy, especially for indie developers.
Magazine racks are excellent spots to do research. What niches are here that current games aren’t targetting?
Blue Oceans can be found everywhere. Even in this crowded mobile space, looking down at the Top Grossing try to identify genres, themes and playing styles that are currently not serviced by these games. Can you create a mobile game that services this genre?
Step 2: Build Empathy
After you’ve selected a genre, It’s about getting into the mindset of the customer. Understand why certain games in the genre failed, and why others succeeded. Play a ton of games. Write everything down. Plot points of reference on a graph and truly understand what defines this genre. Define what base feature set customers need in order for the game to be successful. Research how some games have exceeded player expectation and some games that failed to meet it.
The Kano plot is excellent for plotting features and figuring out the minimum requirements for a genre. As well as brainstorming how you can exceed their expectations.
Most likely, this genre isn’t your personal first choice. Some independent or successful game designers can design games that are essentially for themselves. They use their own experience and knowledge of the genre to design the game. This isn’t possible for all developers. When the target audience is not yourself, you need to do effective market research to truly know how to design for them.
In the early days of Zynga, it was customary that new hires would work in the customer care area of the company. For their first weeks, they would be answering phone calls from disgruntled customers. Whether intentional or not, this gave many designers a stronger backbone in designing games for this audience. Listening and hearing the wants and desires of their players allowed them to build empathy and step into the mindset of the players they would be designing for.
That is why it is important to have a conversations with your target players. Understand why they play the way they play. Understand what they enjoy about the genre, but more importantly — discover why they don’t play. Why do they churn from games. What would it take for these players to leave the top grossing games? Even the most popular ones — whats the reasons why players leave this game? Identifying the chinks the armour — the areas which players hate about that game is your first order.
In the beginnings of Style Studio and Fashion Star Boutique, two games in the Fashion Design genre, it was important that we went out and talk to actual players/fans. In the case of Fashion Star Boutique, we even hired a full time Fashion Designer to help with designing the gameplay, designing the UI, and picking out all the items that players could customize. In the end the product really showed its authenticity.
Step 3: Define Your Pillars
After many, many conversations with players of your game you’ll start to notice patterns. Players of the genre will be demanding certain things about their next game. They will have annoyances, certain aspects that they don’t like, or just general fatigue in the way things have always been done.
To start creating pillars, take some of this feedback and focus on a few points you feel the audience would really be excited about. What if Clash of Clans had more depth in the battle? What if Candy Crush had alternate methods so you could get past those levels when you were stuck?
Endless Runner genre is full of design decisions that player’s don’t like.
For example, after interviewing a ton of fans of the Endless Runner genre (Temple Run, Subway Surfers), we started to see patterns about why many players dropped out. Many players complained because the beginning of the round always felt slow and the same. Advanced players would have to wait until the game got fast enough before they were challenged. Other players complained of seeing the same level over and over again. Players that left the genre complained that the game was too punishing: hitting one obstacle and getting knocked out was exciting, but felt like they got knocked out before they could understand the game.
Taking these 3 points of feedback, and playing a lot of OutRun 2, we decided that maybe we could take a different approach to the Endless Runner market. We transformed the game into an endless racer instead of a endless platformer. We focused on speed, not on avoidance. The game became about optimizing your speed to get to the next checkpoint (like OutRun 2) instead of just staying alive for as long as you can. We added mechanics like a close call system, which gave advanced users reasons to push their luck throughout the whole round. The beginnings were no longer boring, players no longer felt as punished, and we cycled new backgrounds in as the player upgraded to show progress and ensure players felt like the game was always new.
Our racer game came from focusing on addressing 3 key pain points players had from Endless Runners.
These innovations were created as pillars right from the beginning. We developed the game specifically to hit this points of feedback. This drove us through production and kept everyone on the same alignment.
Hearthstone is the great example of excellent pillar creation. In this GDC Vault talk by Eric Dodds, he articulates the importance of Pillars in Hearthstone’s creation. Specifically, he mentions certain pillars that you can really see came across in the design :
“Immediate fun for the new player”
“Allow non-competitive players to thrive”
“Simple Cards, Complex Interactions”
Hearthstone created pillars that focused on players that left the TCG genre. Aiming for simple cards with deep interactions pushed Hearthstone & TCGs to a whole new audience.
Hearthstone serviced a need of Trading Card Game (TCG) fans. They focused on “fringe” card game players that love playing TCG, but could never handle the complexity of Magic. With this focus, they managed to captivate a crowd that has always been turned away by games like Magic. These pillars defined what exactly the final game must feel like in order to be successful. They succeeded, and according to Eric, it had a lot to do with sticking with these guiding pillars throughout production.
Step 4: Fake it ’til you make it
When you have pillars, you have a strong vision for the game. Now you need to create a working prototype as quickly as possible.
You can start on developing a prototype, but this takes too long. Instead, focus on creating simple sketch mockups of key screens in your game as quickly as possible. Do whatever you can to articulate the exact vision you have for hitting those pillars.
How will the game look on device?
Can you articulate the unique aspects of the game in just a few screens?
Are the changes you are making exciting enough to your target audience?
If People aren’t excited when they’ve seen your sketches and discussed the product, they never will be. So iterate on the sketches, brainstorm about more innovations and get more feedback. Many times this will take weeks before an idea really fleshes out, and more often then not, your first idea sucks. That’s fine!
In Summary
The key to building a hit game is very similar to building an app or a business. It comes down to identifying a market need and servicing that need with a new game design. Even in games players have needs (or maybe wants) about what a new game they would be willing to play would be. Identifying large or small blue oceans is the first step. Making sure that there’s a market gap wide enough that by the time you get the game finished — the competition won’t be already swallowing up all of the market share. From here its about truly empathizing with this audience — recognizing what needs this audience currently does not have serviced. I
s it that the current genre options are polished or aesthetically pleasing like CSR or My Horse’s path to success?
Is it that the game design is just too complex for mobile gamers to get into like Hearthstone’s path?
Or maybe its as simple as the current offering just doesn’t have systems that draw players in for the long run, like Endless Runners.
Recognizing these needs, then solidifying them into pillars is the best way to start a new project.
I talk about my experience prototyping and designing new games at Wooga. Specifically how we evaluate new game ideas and ultimately decide whether a game is good enough to launch or not.
My Big 3 Takeaways :
– Never be afraid of stopping a game. Build a culture that embraces that failure is expected when coming up with new game designs.
– For F2P to work, you need to develop a prototype as quickly as possible that proves that it can be fun for up to a month. This is really when the “minigames” are separated from the games that actually have a chance to become a long term hit.
– You can use hard KPI goals during soft launch to quickly evaluate a games potential. You can use this method to make objective decisions about whether a game has potential to become a hit (rather than endlessly discussing subjective opinions about whether a game is good enough or not)
1) How do you and your team typically get the impression that it’s time to “kill” a project? Do you have an example of that?
This depends on the stage of a project.
During the early (concept) phases, the team will usually collect feedback from the target audience and other Product Managers around Wooga. If the excitement level is low, if there’s no signs of success in the market, then they will most likely stop.
During the prototype phase, if user testers aren’t understanding the concept, if they aren’t engaged with the prototype, if they feel like the game is the same thing over and over again, then the team will most likely stop it at this phase.
As the game then gets built into its full form, we continually test our assumptions : Are our defining and differentiating features actually working? In many cases, what was initially designed and thought of during the prototyping phase ends up breaking apart by the time the game gets to its full form. The original design just shows signs that it won’t last as long as we originally thought, its not nearly as fun as it sounded on paper. At this time we don’t just immediately kill the project — we then set goals on a month to month basis to fix these issues and get it to the point we need to. After enough attempts, the Product Lead has to make the choice — do we keep moving with this idea, or try something new?
2) Also, do you have an example of reasons that lead to killing a project? Are there other reasons beneath game design, game quality (like: direct competition,…)
The most common reason in recent game cancellations has been lack of long term potential. We have to ask : do we see players playing this game for a year? If not now (because its still an early prototype) what features do we see will pull players in for a year? Pearl’s Peril and Jelly Splash are excellent examples of how we’ve created a game that can last for a very long time, so we expect nothing but better out of our new games.
Direct Competition does come into play when we discuss and decide the fate of our projects. As the products are built we also start to understand much more about our target audience and the market. In some cases after a few months of development we realise that the risks of developing this project (the amount of time needed, the expertise required to hire) is just too high in comparison to chances of success and subsequent reward. A direct competitor could be dominating in the space, and we might believe that our differentiating features just aren’t enough. We’ve made this call in the past and its always a very tough pill to swallow. But we stop and start looking into new ways to attack the market. In the end, we may never launch the product, but we save so much frustration, so much time and so much money by not spreading ourselves thin across projects that we just don’t have full faith in.
3) Who is finally making the decision, are there lots of discussions and/or even arguments within the team?
The Product Lead is the decision maker, who takes the opinions of the CEO, their Head of Studio, and their team. The Product Lead has to listen to the feedback, but ultimately can make the final call, even if that final call goes against the CEO.
This is important because it gives teams the ownership of the idea and execution. They hear the feedback, they know what’s wrong, but even when the feedback is negative, they know they can make the call. In some cases the team has been correct and proven the feedback wrong. In some cases the team wanted one more shot to see if they could prove us wrong. In both cases we have great learnings and the teams have come out with a positive attitude knowing they did everything they could.
4) Is there sometimes a certain part of killed games you could use otherwise (some assets in another game)?
Typically no.
There are some bits of code that could potentially be moved between games, each game we work on is usually substantially different from the other. Also technology has been moving so quickly in the mobile space its good that we stay flexible and not commit to one technology or have to maintain a cumbersome internal tech. We’ve currently got a mix of teams working with Unity and Cocos2D, because each engine has its advantages and disadvantages for mobile development. In the end I feel like we’re much faster and that developers aren’t stuck with legacy code that is impossible to maintain.
Art and Design are always substantially different so they cannot be shifted from one game to another. However, after a project is cancelled we ask the team to share as many of their learnings as possible. Making sure to share knowledge of new tools and new processes to try on other teams.
In my last game team that was cancelled, we worked with Unity. Many of our team members after the cancellation were moved to other promising projects within the company to make sure they had the knowledge to develop projects with the new engine.
5) Maybe you have one example on a game where you personally now wish you hadn’t killed it – or at least are not sure -, and could elaborate on the reasons?
No, not really.
Rarely the decision comes as a shock to the team. The team is small and close to the design. They see the flaws, they know the feedback coming from users and the company, and in many cases the cancellation has come as a relief — the concept was too restrictive, lets relax and come up with something new.
In some cases people have really put their heart and soul into the game, in that case its very difficult to say no, or to accept it. There’s usually whispers of “what if” or “why don’t we just quickly get it out?” which are valid.
However, In the early years of the app store many free to play titles launched on mobile were mediocre and supported shallow free to play design. These games could still be profitable because it was easy to market and easy to be discovered. But the current marketplace is not a place for mediocre games. The requirements to be a successful free to play title today are long and daunting — if a team is struggling to get long term retention, to get strong monetization or to make their core mechanic accessible enough, then it really has no shot at competing in the top of the market.
Regardless, there will always be “what if” moments when you stop projects, but I’d rather have those than work on a multi-year project that has no chance of success.
adamtelfer.com 