[Editor's note: In the article below, Wooga product lead Stephanie Kaiser provides an in-depth look at her team's development of successful Facebook game Monster World. Kaiser has also been speaking about her experience at Casual Connect in Seattle this week and in Hamburg earlier this year (you can find slides and video from that presentation here). This article is also being published in the latest edition of the Casual Connect magazine.]
Some games don’t become instant hits right after launch. Such was the case with Monster World, a farming game developed by wooga and launched in April 2010. wooga is the 2nd largest developer of social games on Facebook. And Monster World is wooga’s most successful title today, growing virally and monetizing well with over 1.6 million daily active users.
With this in mind, I will describe some lessons learned during the development of the game, structured along the four topics: engagement, virality, monetization and non-metric related factors. But be forewarned: As you gain insights into relevant key performance indicators, you will more than likely fall in love with at least one of wooga’s monster characters.
Engagement
After launching the game in April 2010, Monster World was not an immediate success, but we were able to enhance the game step by step. Looking at the post-launch growth chart, our release cycles become very visible. Every Tuesday we are launching a new version of the game. And each Tuesday’s enhancements can be seen in the growth curve of the game.
We began by improving features related to engagement, reasoning that without high user engagement, any enhancement to virality and monetization would be useless.
The KPIs related to engagement are one-, three-, and seven-day retention and a game’s sticky factor (monthly active users divided by daily active users). Besides that, we dissected each step of the beginner’s tutorial and observed how many users reached steps one, two, three, and finished the tutorial. By undertaking A/B tests, we enhanced specific steps of the tutorial to help as many users as possible enter progressively higher levels within the first session.
In an A/B test, we send a percentage of our users to one version of the game including a feature we intend to test and the others enter a version of the game excluding this feature (the control group). By analyzing the relevant performance indicators afterwards, we are deciding to continue developing one of the tested versions. These tests need to be undertaken simultaneously in order to keep outside factors (such as weather or Facebook downtimes) from influencing the results.
For example, we tested a version of the tutorial that forced the user to perform exactly the action the tutorial character Mr. Tentacle suggests. Meanwhile, other users saw a version that left the decision to follow directions open to them. In the latter, Mr. Tentacle is still visible and giving tips, but any action was voluntary.
The result was pretty surprising. We had always thought that users would prefer freedom of choice. But looking through the results, we had to accept that users wanted to be guided. A lot more users got to the end of the tutorial when they were guided through it, so we selected that version for all users.
Features don’t get into the game simply because someone thinks they’re cool’; they get in only if they are proven by metrics. A very good example is the “Monster Choose,” which was initially the first screen in the game. Looking back at it today, I still think the screen looks quite nice. But after analyzing the numbers we had to acknowledge that we were losing too many users at this step. Surprisingly, there was no effect on user retention if users were not offered the opportunity to choose their monster anymore. So we cut the feature.
Because we had built quite a large user base (already around 300.000 daily active users at the time), we gained highly reliable data from A/B tests. Consequently, those tests became one of our favorite optimization instruments.
Along with cutting and enhancing existing features, we added new ones aimed at raising our users’ engagement like adding in a missions system. By giving users tasks to complete, they started to return to the game more often to fulfill the quests that were assigned to them.
After working on the tutorial and the missions week after week, the game began to grow virally. The users’ engagement was much higher than it was at the launch of the game and we could move on by enhancing and developing virality features.
Virality
Viral channels on Facebook change frequently. They are not what they were a year ago, and a superficial look could lead you to the conclusions that developers are suffering from the changes Facebook has made. But if you look at these changes in more detail, you’ll see that the changes were good from a user’s perspective. And since Facebook and social game developers are both trying to engage and retain users, you would have to acknowledge that ultimately the changes were good for developers also.
More than a year ago, users were able to send out unlimited feedposts from the games they were playing. Many users considered the feedposts spam, which in turn created a negative image for social games. And unhappy users are not sticky.
Feedposts today are only shown to those users that have registered with a game. This change ensures that the content in the users’ stream stays relevant. Relevance as the selection criteria in an always overloaded stream of news. With this change feedposts turned from a viral to a retention feature. As a new viral channel, Facebook has changed the way requests are shown and implemented in the platform. User to user requests are now counted and shown as a red number over the globe icon in the top Facebook menu bar. Requests can be sent to a user’s entire friends list, including those that do not play the game yet. With these functionality changes requests are a strong viral channel today.
Every viral feature needs to be socially acceptable. Therefore, any interaction between users in a game needs to be “share-worthy” and “click-worthy.” If a feedpost is share-worthy, the user is more likely to share it amongst their social circle. It needs to include a relevant message for the sender.
A good example is the Robert feedpost in Monster World. Robert is the customer robot standing at the gate to a user’s garden, asking the user to sell a specific set of plants to him. He pays well. This creates the incentive for users to post a help inquiry to their friends. Any friend clicking this post is sending a plant to the user, who can now finish the deal with Robert faster, gain points and level up earlier. This post is, in that sense, share-worthy.
The counterpart of being shareworthy is being click-worthy which relates to the receiver. Any clickable post that appears in a user’s stream with the intention of being clicked by them should be click-worthy. To generate this click-worthiness we changed all of our posts to include an in-game reward for the receiver. Whenever the receiver clicks a feedpost, he gets a gift, such as coins, some XP, etc. With this change, our response rate on feedposts jumped up.
In addition to these changes, we introduced new features that were intended to impact the game’s virality of the game. One very successful example was the introduction of the monster baby. Users become more engaged with a game once they start to have a strong emotional attachment to the characters in the game. The sad, lost monster baby caused people to feel a certain need to help.
The baby would cry constantly until the user would agree to build the toy the baby was demanding. To build the toy the user needed a certain quantity of varied materials. Those materials could either be found by harvesting plants (this is quite rare), by asking friends for help (through a feedpost) or by purchasing them. In that sense the baby added a social barrier to the game. The number of feedposts being sent increased rapidly when the baby feature was launched. No one could stand to watch the crying thing.
After completing the first toy, the baby would move into a user’s garden and start living there. From then on, it would ask for food and love at least once a day. And if it didn’t get what it wanted, it would start crying again. If users treat their baby well, however, they earn a daily bonus.
Recently we had a visitor at our wooga office in Berlin for a usability test. He was an avid player of Monster World and told us the game was part of his life. He had heard rumors that the baby would die if weren’t fed or hugged once a day. I personally love this rumor, although we would never let the baby die. Our Monster World is a very friendly one.
When Facebook changed the rules of their virality channels we switched from using feedposts to sending requests in order to use the full viral potential. Requests can be sent to all friends, not just the ones playing the game already and therefore invite new possible game users.
Monetization
After optimizing Monster World for maximum engagement and virality, we started to look further into the topic of monetization. By analyzing the number of buyers and their actual purchases, we discovered the obvious: consumables are monetizing much better than purely decorative items. They create a constant purchase cycle because consumables are used up as they are traded for game advantages.
In Monster World one type of consumables is the magic wand. Magic wands can be used in the game to either revive plants or to skip-over their growth time and harvest them immediately. In the real world our magic wands would equal fertilizer. Today wooga is the biggest seller of virtual magic wands in the world.
After understanding the importance of consumables, we added another one to the game: woogoo. Just recently have a series of new features that relate to woogoo been added into the game. We introduced Roberta, a character who has a constant demand for various products that cannot be manufactured without woogoo. Users can gain woogoo by selling to Robert, by harvesting, by asking their friends (via requests) or by buying it.
The game’s inherent woogoo supply is balanced to be below sufficient, but still the user has a chance to get woogoo without paying for it. It is just never enough. To fulfill all of Roberta’s demands or for example to use the auto-harvester the user needs more woogoo, than he finds by harvesting. He will always be able to sell some products to Roberta, but if he wants to sell more, he needs to either be viral or pay..
Consumables in that sense either help the user to progress faster in the game or allow him to prolong the playing sessions.
The Report Guy
As stated above, to enhance a game like Monster World you really need to know your metrics and need to analyze them on a daily basis. We are in the privileged position to look into the KPIs of over 1.2 million users daily and we do. An in-house reporting tool, built by wooga, is offering us a valuable insight into our games. Our “report guy” sends out automated report mails on defined KPIs, that we are interested in tracking daily.
Aside from all the metrics, there is a whole universe of non-metric related factors that have helped us to make Monster World a successful game.
Usability testing
From the very beginning of the development we invite people outside of our project teams to participate in usability tests at wooga. My first test on Monster World was done on a paper prototype, with a pen, which served as a mouse. I showed the prototype to possible users and asked them to use the pen and “click” as if it were a computer screen. The page behind the click would be the next step in the user flow and was also prepared as a paper prototype. By testing early and often, we tried to avoid conceptual mistakes at a very early stage, before we even began development.
During the development of click-prototypes, we started to test with real computers. Most of the time, we would just watch our test users. Not answering their questions or directing them would help us a lot in understanding the current iteration’s design flaws. The well known: “We listen to our users!” is changed to ”We look at our users.”
We test our games every two weeks. Product staff is always in attendance. Right after a test the “watchers” immediately discuss their findings and decide upon priorities for the next development cycle. We regularly invite everyone from the team to join a test. For developers and graphic people in particular, those sessions give a very deep insight into the world of user behavior.
Release Cycles
We work in weekly release cycles using a mixture (or, as we say: the best) of Kanban and Scrum. Every Tuesday we release a new version of the game on Facebook. The next development cycle begins on Tuesday and continues until that Friday. Over the weekend we refresh our minds and prepare to fix the bugs found in the new version that Monday.
These short release cycles are tough, and every team member must work in a very disciplined manner to avoid delays caused by inter-team dependencies.. But it pays off. We move fast, but we are still flexible enough to change priorities on a daily basis. Once a feature is finished, we usually release it while still maintaining the weekly cycle on top of that. Therefore, if someone in the team has an idea (or a finding of a usability test) today, it can be included in the next version—if its priority is high enough. In my experience, this direct impact on a game really motivates everyone on the team.
Localization
We localize our games in seven languages: English, Spanish, Italian, French, Portuguese, Turkish and German. From the early days of development onwards, we support different languages in the game via XML. Supporting accents is as important as the solution to the problem that some languages just need more space than others. Consequently, no text is embedded in images. wooga offers localized customer support, localized fan pages and virtual goods localized within the game. For example, during the soccer world championship last year, we had French, Italian and Spanish tricots hanging on washing lines in the game.
Emotions
As stated previously, users will be more engaged more in a game if they build a relationship with its characters. We focus a lot on all the little details in the game that make Monster World very loveable. The robot in Monster World is called Robert. Robert stands in the users’ garden waiting to make a deal. While he is waiting, he jumps rope, plays on his PSP, and flirts with Roberta. Users can visit their friends’ gardens and invite Robert to enjoy a bottle of oil. If Robert has too much oil, he gets drunk and will pay the user’s friend more coins in their next deal.
There are a variety of monsters in the Monster family, including the monster baby mentioned previously. Whenever we tested the baby with women in usability tests, they just went crazy when the baby appeared. Who can resist the happiness that comes after building a brand new rocking horse for a baby?
The Team
wooga is organized into dedicated game teams, with one product lead. All team members—developers, graphic designers, project managers and additional product managers—are dedicated resources that work on just one game. Each team has an individual office room which establishes a concentrated working environment with very short communication distances.
wooga was lucky enough to find a group of people wherein every single person is committed to building the best products they can imagine. With the love and dedication of every single monster on our team, we were able to work through the still ongoing optimization process of our game and transform it into a real Monster World.
Stephanie Kaiser is the Product Lead of Monster World at wooga (world of gaming), a top 15 social game on Facebook with over a 1,6 million daily users and over 8 million monthly active users. She is responsible for the design and development of Monster World, leading a team of 15. Prior to joining wooga, Stephanie worked as a Product Manager at Jamba/Jamster and as Manager of Product Development at MTV Networks where she was responsible for the development of clubnick.de, a subscription-based learning platform for children. Stephanie attended the Humboldt University Berlin (French Philologies and Information Science). She has a passion for dance and robots.
If you’re in Seattle this week, come join Inside Network and our community of social and mobile developers at The W Hotel for cocktails and some great networking!
The 
