What follows is the notes I took on Osma Ahvenlampi’s talk at LOGIN 2010 about the last two years of running Habbo Hotel. Any mistakes are my own!
Most people know us from Habbo which is an international community, 32 countries in the world. We’ve been around for 10 years and gotten a lot of traffic. 172M registered characters, 16M unique browsers/month, 2M visits/day, 45M hours of play/month.
I’m going to talk about a combo of: basics on why we’ve focused on one single product for 10 years, a technical transition we made converting between platforms, and measuring player economics and secondary markets. Mostly will be talking about years 8 and 9 of Habbo.
Habbo is an environment where teens create their own environments and meet there to play with each other. Centered around “social play” which we coined before the big social game rush. It’s something other than goal-oriented gaming.
Two years ago I was talking about how we converted the company to do Agile development. Continuous reinvention on tech, design, and business. There was one major problem: we required Shockwave Player at the time, so we had to switch technologies. Exactly two years ago we started the project to switch platforms. We evaluated platforms based on easy-access, easy-play, had to browser based. We also looked at developer productivity and labor available. Finally we did care about performance of the platform on modest computers.
We considered Java (which is our serverside), Unity, and others, but in the end we went with Flash because of its install base and penetration. Certainly two years ago Flash was the only really viable platform.
Then we asked: are we going to do something else or are we going to continue with Habbo? We decided to replicate Habbo Hotel with new tech and convert our userbase. But aren’t we just risking our entire business by switching away from something people are already happy with? At the end of the day we figured that improving what we already have will be a much bigger payoff even though it would take a while to develop. In the first year, sticking with Habbo has the best results since we don’t start with 0 users and high risk.
We measure conversion rate, retention rate, and monetization rate. Conversion rate is “new returning users / new traffic.” Typical conversion for a new user to becoming returning traffic is 10%-40%. This metric is simple to measure.
Retention rate is a complex metric to measure because it’s not a ratio or a rate, it’s a flow metric. Superficially speaking it’s “of the people that visited your service in the last month, how many visit this month as well?” This helps you determine how many new users you have to get every month to replace who churned out last month. If the retention rate changes in a good or bad direction even a little bit it will make huge changes in your revenue. We expected to see a higher retention rate with Flash.
Monetization. We have ARPU which is average revenue per player, or per paying player (ARPPU). The bad thing about ARPU is that it reduces a number to an average, which hides the shape of your bell curve. In a free to play game your median player spends $0. Average revenue is higher than $0 since some people are paying. Anyway, changing the tech platform did not change our revenue distribution, but we didn’t expect it to.
Simple math: new traffic x conversion rate x (retention rate / months) x monetization rate = revenue. This is our forecasting tool for how much we need to spend on traffic acquisition. 2009 was a better year than 2008 for us in terms of a 21% traffic increase year-on-year. Our blog on sulake.com will have some numbers on revenue but 2009 was worse for us until we introduced some new monetization-focused features.
Transition to new tech was difficult. We had about 10 man-years on the client only, so we estimated about 6 man-years to write the new client. We usually only planned for a few months out so it was difficult to estimate for a year-long project. We had to do a new core client with a basic architecture in place, but it wasn’t so bad since we could copy the architecture from our old client. We had to write every feature again, create new tools for testing, a new asset pipeline that was compatible with our old assets, and a new deployment pipeline with new tools there. We expected to gain significant production efficiencies down the line from tool development.
We had a very small team for the core client, 3-6 people. Then we transitioned people out of the shockwave teams into developing more features in Flash. We left a small maintenance team for Shockwave during the transition period of a few months.
We decided to use the same server and protocol for both clients, which meant that we needed to rewrite part of the old Shockwave client. This wasn’t obvious at the beginning. There was seemingly a lot of waste in having to rewrite both clients just to ditch one, but the payoff was in testing. We had players in house testing on both clients playing on the same server, and we could verify that both groups of players could play with each other and that the clients looked the same and it didn’t make a difference which client was being used. We were able to test the Flash client against the live server as well.
Finally we decided to make no new features during the transition. Only UI improvements and some performance improvements (rendering scaled in high resolution). But no new game features.
Schedule-wise we were expecting 8-10 months of dev and launch in Q109. We shipped in 13 months launching in May 2009 on an invite-only beta launch. Open beta in June/July. At the end of October 2009 we shut down the old client. 18 month transition. At the end of the day it was the new features for the Flash client that sold things to the customers. We still do get complaints that people want the old version back. But they’re still playing and complaining, so that’s not all bad!
The final evaluation is that even though it took longer than planned it was a resounding success. This was due to deciding to do it iteratively and not planning it via waterfall, which allowed for many reprioritizations during development. We pulled devs off the Flash project onto Shockwave several times for needed work. Also, parallel development was very helpful. Of course, we had a skilled team as well.
We did another platform shift in addition to our tech platform shift.
What’s a social game in the FB context? People don’t spend a lot of time on Facebook — even if you have 100 friends logging onto Facebook every day you’re still likely to miss them. Successful social game on facebook is the parallel single player experience. You never see friends playing or play with them, you see the results of their play.
Habbo is a social structure with games created by the users. Showed us this Habbo room. Our users come up with the weirdest stuff. The cinema thing is extremely popular in Brazil and nowhere else.
Habbo was a walled garden, so we started taking steps to connect Habbo to the social graph. We have a Habbo FB application, but what we are doing on FB right now is really primitive. Most of the game companies succeeding on FB are way more sophisticated than we are. We’ve been focused on merging our international communities together into common language services so we haven’t had enough focus on the FB application. It does seem that FB is reaching a saturation point. We have about 400k-500k MAUs which makes us mid-sized, and even the big games aren’t growing much anymore. Also, if you’ve been following the news it seems like tying your game to someone else’s platform is not the best idea.
The real question is not how you host your game on FB but how you use the web to support your interactive experience? The most important thing to me is that you no longer need to register to play a game and play with your friends and have an identity. Games that use SNS identity responsibly are going to be better than games that don’t.
Economics of Player to Player Markets
In the early years we allowed people to transfer items between accounts. At first it was via premium SMS. Then we introduced Habbo Coins, but it wasn’t possible to move Coins from one account to another. What happened was people would invent their own currency. Some common item would become the currency of the world. We had a subscription feature that gives gifts to members where you’d get a sofa every month if you were a member. Players started trading for stuff using our subscription club sofas. It happened early on — google “habbo furni values” for some player economic analysis of furniture markets!
We introduced a marketplace where you can post for-sale notices and allow for unattended trades, so we’re training people to run shops. I hope that at some point we can publish enough data to even train commodities traders among our users.
There are business implications of a secondary market. The player-to-player trading volume is several times larger than our direct sales to players. We estimate that US$0.5B in goods are exchanged between players of Habbo yearly, internationally. Items stay in active inventory even after an owner quits Habbo. If traffic growth slows down, then the world “fills up” with old abandoned items that people can use instead of buying new items. This means we need to do some design tricks to account for this.
Three ways to deal with this: 1) don’t allow trading. But then there’s no economy. No collectible value for items, makes items less interesting. We do use this in very selective cases. 2) Make items wear out after use. Essentially renting items to players, destroys trade value. We use this a bit, we basically rent clothes to players. 3) For most of our items they are durable and ageless. We created a system that gets tiny fees out of the secondary trading. It could be a cost on a for-sale notice on the marketplace, could be a comission for secure trading. We take 1% of the value out of the system on every trade, and also manage inflation which is the really important bit. Now there’s friction moving items from account to account so we stop the “filling up” that happens.
We’ve found that your high-spending customers spend the most amount of time in game by far. A very small percentage of your player base does most of EVERYTHING in your game, not just spending but any activity you look at. Again, this is why averages are not good to look at.
Conclusions
If you’re doing big changes on your tech base, do parallel deployment and iterate.
If you’re doing a service model game, focus on conversion/retention/monetization.
If you have a secondary market in the system, try to model it and understand the economics of who your big spenders are. Look for emergent behavior you didn’t think of when you designed the system. Invest in analysis resources!
Q: Is there a correlation between number of friends and amount of money spent?
A: Not a strong correlation, but there is an interesting correlation between number of friends and a person’s influence on what their friends purchase.
Comments on this entry are closed.