Golem.de is a tech news source for Germany. Recently they did an interview with me regarding my GDC Europe Presentation “The Art of Killing Games”.
For the original content (In full german) : http://www.golem.de/news/wooga-die-kunst-ein-spiel-zu-killen-1408-108425.html
Here is the english version :
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 