Lessons In Facebook Game Design: Mike Sellers on Online Alchemy's Holiday Village

[Editor's note: We've been covering the latest discussion around possibilities in social game design this week. What's the place of synchronous gaming on the Facebook platform? What about races, tournaments, deception, tolls, and all sorts of other mechanics? Below, Mike Sellers of game developer Online Alchemy shares his experiences building a game that featured a shared virtual space -- and the trouble he and his team encountered given the current mindsets of Facebook gamers. For context on the topic of social game design innovation, see this recent presentation by Playdom's Raph Koster and follow-up commentary by guest columnist Tadhg Kelly.] Holiday Village is a social game developed by Online Alchemy and launched on Facebook in late 2010. It allows multiple players to create a small “Christmas village” together. The game, in my view, is notable for several reasons: First, it’s a game that is actually social – you play collaboratively with your friends in the same space at the same time. Second, it embodied several successful design concepts that do not derive from the current design tropes commonly seen in Facebook games. And third, we were able to develop it as an original IP with a small team in a very short amount of time – about 7 weeks from first concept doc to launch. In some ways this effort was highly successful, in other ways it didn’t match what we hoped for. As you might expect, we learned a lot along the way. Holiday Village started out as an idea by Samantha LeCraft, a designer at Online Alchemy. We had one of those “wouldn’t it be cool if…” conversations during the holiday season in 2009 about people building little Christmas towns together – putting online the kind of experience many have at the holidays when they arrange little buildings into a sort of small fantasy town. I thought she had a great idea for a holiday app, and told her to remind me of it the next summer, when we might have time to actually do something with it. By summer 2010 we were working hard on another project, and so we weren’t really able to get started on our “holiday game” as we loosely thought of it until the autumn. By then we knew we had a very short amount of time until the holidays and few resources to put toward the game. But we had looked at the market and it seemed viable, we had a technology stack that would support a collaborative social app, and we wanted to have this little game see the light of day. In the first part of October we wrote up the first iteration of the design, and by late November we launched Holiday Village on Facebook. I should note that not only was the backend technology terrific, but we were fortunate to have amazing Flash/Flex programmers creating the client, a great art director who quickly understood how important the feel of the app was to it, and a fast, flexible, and professional group of contract artists. This team while small and geographically distributed (and working on other projects), was able to develop and iterate quickly and effectively. The primary design goal for Holiday Village was to evoke an emotional response unlike those typically found in current social games: since this was a game built around holidays, we wanted people to feel a sense of family, warmth, comfort, and nostalgia – even nostalgia for a time and place they may have never seen. We chose an abstract 1930s/40s American style for the art, evoking classics such as It’s a Wonderful Life without being directly derivative or too specific with the era. We also chose the UI, sound effects and music very carefully: we wanted mellow nostalgia, the warm feeling for friends and family not present that people often feel at the holidays – but not tilting over into feelings of sadness or loss. Our primary experiential goal was for family and friends who are far apart to be able to gather together around building their own iconic, ideal holiday villages. We complemented the main initial activities of building the village with quietly falling snow, the ability to see the village in daylight or night, and the ability to turn on a “music box” mode where the village scrolls slowly by as the snow falls and the quiet music plays. Based on the player reports we received, we believe we hit this emotional goal well. Our players (mostly women) definitely resonated with the emotional tone the game presented. They enjoyed being able to see their village in the day or night (and especially with the holiday lights on), playing with the falling snow, and actually playing the game too. Comments like “now I want a mug of hot chocolate!” were common. In addition to the emotion-related design goal, another important goal for us was to try out having players on Facebook create and build their own shared spaces. Each village is a “space” defined by the players and private to them and their friends. Unlike many games on Facebook today where each player has their own space (e.g. farm, city, etc.), these villages are shared fully between players. One person starts a village and can invite others. Anyone who is a “member” of a village can edit it with equal authority (though the person who started it can always kick others out). Players do not share their personal inventory of buildings or in-game coins, but they can gift building to others -- and the village itself acts as a form of shared inventory, since any member can move, add, or delete items there. While shared spaces are nothing new in MMOGs and similar games, they are not yet common on Facebook. In fact, many of our players seemed to not understand the concept at first, or did not believe that they could actually be in the same village with another person and both be interacting with it at the same time. Facebook users seem to have been well-trained that games are single-player with carefully limited avenues for socialization (usually consisting of asking someone else for help – a form of “begging as gameplay” that we wanted to avoid). The expectations set up in current players of Facebook games took us by surprise in another way as well. When we first released Holiday Village we did so as an “app” rather than a “game.” We knew that many people buy small holiday buildings at prices of $50 to $100 each to build villages in their homes (there are literally thousands of YouTube videos made by people proudly showing off their town displays). The question was, would people be willing to buy a virtual building for a dollar or two, or a set of trees for fifty cents? In part, the answer was yes: Our initial monetization was good (as was our viral spread – we did a little advertising, but by far most of our users came in via word-of-mouth from other players), but it was paralleled by questions and complaints about the open-ended app-like rather than directed game-like experience we provided: “What’s my goal?” “How can I earn coins?” “How do I play the game?” “Why should I have to spend money?” Clearly, the free-to-play mindset has taken hold in the players we were seeing, and the idea of an app that did not provide gameplay-that-makes-coins, did not lead the player somewhat by the nose, and did not provide non-monetary options for gaining rewards was not popular. This may seem obvious, but it was worth the experiment. While some are still wondering whether the free-to-play model will really work, our experience indicates that with the mass market, it has become the de facto expectation. As a result we quickly added in gameplay to create a more game-like directed experience. The challenge was to make the gameplay thematically consistent with the idea of building your holiday village. Within a few days we designed and launched an integrated matching game based on which buildings you chose to put in your village: each day, each building in your village generates one or more “value” tokens that contribute to the well-being of a community – happiness, prosperity, and unity. A home tends to create more happiness tokens for example, while a store provides more prosperity and a church or post office creates more unity. These tokens were then used to fill in matching spaces (randomly determined) in bars of increasing length. Abstractly, the bars represented “what your village needs to thrive,” with the value tokens supplied by your buildings. The more buildings of different types you had, the more bars you could fill, and the more coins you received. Overall, this gameplay was very well received: players played and enjoyed it, and used the rewards to purchase more buildings. This of course dampened our direct monetary sales, but also appeared to increase player satisfaction overall. Unfortunately, this also confirmed to us what we knew we were missing: while the gameplay and monetization connection worked well, we had insufficient “consumable” goods (speed-ups or other one-time-use items) that could be bought, and we lacked a secondary currency loop for purchasing premium goods. While we were aware of these shortcomings, at the time we lacked the resources to act on them. This leads us into the “what went wrong” category, or perhaps, how our limitations constrained us. The gameplay we had was well-received by the players, but was clearly not sufficient. This is an example of how we were exploring the “M” in MVP (Minimum Viable Product): because we were highly time-and resource-bound from the very start, we kept extremely tight control on the scope for this game. Our programmers and artists were able to put in a few extras, but overall we kept a firm, even ruthless clamp on the design scope for the game. Keeping to this enabled us to develop and launch the game at all – but there is a minimum below which a product is no longer commercially viable. If you cannot start above that line or get above it quickly post-launch, even a game that is loved by its players and is nicely viral will die. We did not have the time during the holiday push nor the resources to devote to adding in the features that we believed were needed to keep the game’s popularity going once it has first flared up. Overall, we learned a lot with Holiday Village as most companies do with their first Facebook game. Just putting a game up on Facebook these days is an exercise in learning and frustration -- in part because the Facebook API is so poorly documented and changes so rapidly (without any versioning or way to tell what will work or not work, since older games are not required to match to new changes). We learned to trust our design instincts and research in terms of addressing the mass-market female demographic, as well as how this market has had its expectations set by current games. We also saw how readily they took to the more social aspects of villages as shared private spaces, and believe these will be a differentiator for games in the coming year. Finally, we learned quite a bit about the importance of recognizing what features can be removed from an MVP candidate and which must be present to maintain the “viable” part of MVP. By now everyone knows that launching the game is only the first big milestone, not the last; as we experienced, being resource-constrained at and after launch can strangle even a game that otherwise hits its design and technical goals. Mike Sellers is the Chief Alchemist of Online Alchemy, a social games developer and designer artificial intelligence engines.

Social Pro Daily

Lessons In Facebook Game Design: Mike Sellers on Online Alchemy's Holiday Village

Guest

About

Subscriptions

Events

Publications

WORK SMARTER - LEARN, GROW AND BE INSPIRED.

Subscribe today!

Guest