Student Postmortem: Skyrates

By Carnegie Mellon ETC students [12.13.07]

 We're a group of graduate students at Carnegie Mellon University's Entertainment Technology Center, and we love games. Playing and building games captures our imagination and thus, our time -- and time is in short supply for graduate students. The 40-hour video games that we enjoyed in the past no longer had a place in our busy schedules.

For other graduate students, losing the luxury of playing video games would have been just a fact of life, but since we were all headed into the game industry, we had to find a way to make games fit into our lives.

Skyrates was intended to be a solution to that problem. The core idea is that a game can be experienced in short sessions, rather than in one larger chunk, much like checking email, which we do a few minutes here and there throughout the day. We call this "sporadic play."

Skyrates set out to be a persistent multiplayer world in the context of a casual Flash game. The game is set in a world of floating lands. Players travel from skyland to skyland in WWII-inspired aircraft. The real-time flights typically last a few hours. By queuing up a sequence of actions, players can keep their characters moving for days without further interaction. Everyone who interacts with the world earns gold and has a chance to upgrade his or her plane.

Development progressed through three major phases. The first semester we made Skyrates 1. Then the team regrouped for a second semester and created Skyrates 2, which expanded on the work of the first semester. The end of Skyrates 2 was marked by our graduations in May 2007. Since then, the game has continued to evolve in our free time into Skyrates 2.5.

What Went Right
1. Meaningful choices, but not all at once. In Skyrates 1, we discovered the concept of sporadic play was novel and appealing. Our players liked the idea of a game that required only a little bit of interaction, embracing the small world we created. Unfortunately, the game's simplicity also proved to be its downfall. Players were reaching the end of the content quickly, and the limited choices were becoming stale, so in Skyrates 2, we added more content: the number and types of aircraft, locations, and commodities.

We didn't expect the addition of more choices to be enough. We wanted to create more nuanced choices, and additional content was a means to that end. By giving ourselves a larger pool of assets, we were able to better tweak small facets of the experience. No longer would players just upgrade their planes to the next in the sequence of fighters. Now they had choices.

However, tossing in more choices blindly is a recipe for self-destruction. Our game is meant to take a small amount of time to play, and if we assaulted our players at each play session with too many options, we would run the risk of overwhelming them. Players who want a casual and sporadic game are less likely to invest their time in learning to navigate a complex interface.

By presenting the decisions in small easy-to-digest chunks and increasing the size of them over time, the player could learn to make complicated decisions quickly. While our game has 12 trade commodities and 38 places to trade them, the beginning player only sees a small subset of that (five commodities and five places). The rest are unveiled over time. As players improve at making decisions, they receive harder and more interesting decisions to make. In the end it remains an experience of just a few minutes at a time.


 2. Build community. In Skyrates 2, we added an in-game chat and web forum. Both were largely intended for occasional questions and bug reports, but quickly turned into something more. Suddenly, we found ourselves building and managing a community instead of simply experimenting with gameplay. Fortunately, we embraced what was happening, and now the community of dedicated players is our most precious and powerful asset.

Many games rely to some extent on a vocal community of players. One thing that distinguishes Skyrates is that we have encouraged them to take part in defining the world itself. Our players contribute to every aspect of the game: mythology and history, balance, and suggestions for new features. The ways in which they do so continue to amaze us. They've built tools to compare and contrast planes and upgrades; maps and distance charts of the world; imaginary sports and leagues complete with standings and results; in-game radio shows to disseminate news and rumors. They've even fleshed out the histories of major characters and events. Without the incredible passion and dedication of a community that was born accidentally, the game wouldn't be here today.

Many of the community members have invested as much creative energy in the game as we developers have. We hope that by providing the community a sense of ownership, they will want the game to succeed as much as we do.

3. Design, implement, and iterate, iterate, iterate! You'll find this message in nearly every video game postmortem you read, but iteration was a crucial factor in our success, so it bears repeating. One of the big risks that we took in our first semester was to have a working version of the game ready for the 2006 Game Developers Conference, which occurred exactly halfway through the semester. We didn't know whether it was possible to accomplish that in such a short schedule, but it also meant that we were able to spend half the semester refining a playable prototype.

Getting a prototype working with bare bones versions of all the major features of the game allowed us a full eight weeks of play testing, feature development, and iterative design. This constant iteration was immensely helpful in allowing us to prove, refine, and focus our gameplay ideas. At the beginning of the project, we really had no idea whether sporadic play would be enjoyable at all. Getting something working early showed us that it was fun and helped us to create something stable enough to push out to the general public at the end of the semester.

4. Refine the goals as you go. Our initial goal for Skyrates 1 was to focus on keyhole gameplay. Even with a complex world, and with the player having a complex understanding of that world, the interaction between the player and the world can be narrow. An example is the stock market: While it's shaped by a multitude of factors, the only interactions that a person has with the market are buying and selling, simple transactions that they can be done via almost any medium.

Like the stock market, Skyrates 1 can be accessed in a variety of ways -- Flash client, mobile phone java app, SMS, and instant messaging. During the first semester, we continually surveyed the players about their experiences. Each time, more people asked us to focus on the Flash client. We eventually reprioritized, set the alternatives aside, and shifted our efforts.

Whenever you're focused on a project, it's easy to lose your objectivity. To combat this, we made sure to solicit feedback from people outside the project. By listening to our early testers and taking the time to understand what they loved about the game, we realized the importance of sporadic play. By the end of Skyrates 1, that became the real heart of the game.

5. Find the fun, then make the rest. One of the things that worked extremely well in our favor was the fact that Skyrates 1 was a research project. At the beginning, our goal was merely to prove that sporadic play could be fun. Having measured our success by the fun factor of the prototype and nothing more, we were freed from a myriad of other goals that most other game projects have to achieve. We weren't expecting to actually make any money. The infrastructure did not have to be stable. We didn't need to be able to scale the project, nor did we need more than a play test cycle's worth of content. This allowed us to concentrate on rapidly prototyping and testing gameplay ideas without the pressure of creating a shippable title at the end of the semester.


 What Went Wrong
1. Don't bend the tree to the leaves. Throughout the development of Skyrates 2, we had a lot of ideas about what we wanted to accomplish. We also had a large audience brimming with suggestions for new features and changes to existing ones. At the time, we tended to act on the most vocal player's suggestions, assuming they represented the entire player base.

Eventually, we came to realize that while these players often alerted us to trends early, we needed to take their feedback with a grain of salt -- they held just one perspective and typically were the minority. The majority of our player base, due to the nature of the game, is the type of person who doesn't have time to provide feedback.

As the team came up with several new features to add to the game, we fell into a similar trap. Rather than looking at the trunk of the game and seeing where we could branch off, we were looking at distant leaves and trying to bend the tree to meet them. While Skyrates 1 was characterized by constant iteration and refinement, Skyrates 2 saw the designs get larger and more complex without taking the time necessary to critique and analyze them.

2. Player communication can hurt a game's casual feel. For all that Skyrates 1 lacked, there was a simple casual purity to it that was lost in Skyrates 2.

One of the major differences was that Skyrates 1 was a lonely experience. Each player flew silent and solitary paths across the world, the only competition or interaction existing on the rankings board. In fact, we discovered that the rankings board was about the only thing that really drove people to strive and succeed. It was a pinprick of sound in an otherwise silent experience.

For Skyrates 2, that sound became a din. At release, we added a forum and chat. Suddenly, the world was inhabited with real people, who were talking to one another, comparing their ships and characters. Now, as soon as they logged on, they saw their chat tab blinking with people debating the merits of the various aircrafts and so on. Players now had an entire community judging them, instead of being able to casually stumble through the game at their own speed.

Adding these community features ended up being a crucial part of the game's success, but we should have considered what it might do to the casual intent of the game. Though communication added significantly to the game, it took us a long time to realize what it also took away.

3. Not planning for remote work means work won't happen. When we were not in school, the project had a tendency to stagnate, and we never discussed the game's long-term future in detail. Certainly, that lack of planning was predictable due to the very unpredictability of our lives after graduation. Nevertheless, we lacked a clear goal. Once we were thrown into the chaos of searching for jobs and homes, Skyrates took a backseat.

When the team members were no longer geographically near one another, we didn't know what we should be working on, what the process for work should be, or what the others were even doing. Work stopped. It was especially damaging to our community, who had come to value the developer presence. Many of our players quit, and we weren't even around to see it.

Gradually, we reclaimed a bit of our step, conducting weekly meetings and staying connected through email. Regardless, it was a struggle getting people back into a productive mindset. Once a project hits inertia, it's exceedingly difficult to reverse it.

4.Plan for the short term and only achieve short things. As a project that existed on a semester-to-semester basis, we were only really able to plan our progress three months at a time. We were forced to limit ourselves to the bare essentials necessary to make the experience work. This became especially apparent as new ideas and new ways of expanding existing ideas came up during development that would be impossible to implement within the current semester. We were thus unable to accomplish them because we could not count on any more time beyond the existing semester.

5. Don't let the players run out of things to do. In the game's first iteration, there was a small archipelago to traverse, a few craft to try out, goods to trade, and that was about it. We wanted to provide a persistent game, but after a point, that game left players with little meaningful things to do. The problem was mitigated by biweekly resets, which returned all the players to empty coffers and a starter plane. This setup couldn't sustain a meaningful game for the long term. We needed something that players could do perpetually. It's a problem we still haven't solved.

Our strongest lead on an actual solution right now is the "influence game," a way for players to accept missions in order to increase their reputations and contribute to the "influence" of their factions. The faction with the most influence gets to plant a flag with their color on the skyland. Modest though it may be, this simple "king of the hill" aspect has been enough to unify teams and give them something to do at the end -- but it's really just a stopgap and will not suffice for long.

Figuring out how to give casual players a perpetual end game experience remains our most critical design challenge. Our team simply doesn't have the manpower to be out laying out the tracks in front of the train. However, we do think there is a more sustainable solution to be found.


Onward and Upward
We've learned tremendously from the Skyrates projects. We improved our own skills while learning a lot about design that we never expected. We had set out to experiment with multiple windows into the same game world and tripped over the idea of sporadic play on the way. We grew fond of the idea, as did the players, and we ended up focusing on that instead.

There's definitely an audience for this type of game, although much work needs to be done to truly fulfill that niche. The most challenging part is balancing the experience to be easy and simple to engage, yet sufficiently deep. That way, the experience can be as rich and interesting as a typical MMOG, but casual to play. It's a tightrope act that we know is difficult for every designer, and while we've fallen off many times, we know a lot more about it now.

Skyrates is certainly not finished, and it will see major changes over time, as we continue the iterative process with the feedback and comments from our community. Curiously, we're starting to get some questions about whether there's a phone client, bringing us full circle to the keyhole gameplay idea.

To play Skyrates, which is still in a free beta phase, visit Skyrates.net.


Team Members
Howard Braham programmed the economy and the flight system. He currently designs and prototypes interactive rides and games at Walt Disney Imagineering.

Bryan Cash, chief morale officer and programmer of the crew, skills, and tutorial, is now a programmer at Schell Games.

Henry Clay, architect of the client side and system admin, currently works at Disney's VR Studio.
Chris Daniel, artist of characters and skill images, is an interface designer and programmer at High Voltage Software.

Jeremy Gibson wrote the combat and most of the prototypes for Skyrates. He is currently an associate producer and game designer at Electronic Arts' Pogo.com.

Chuck Hoover, producer and artist for the aircraft, sky-lands, and environments, currently works as a producer at Schell Games.

Phil Light worked on stats and community affairs. He co-founded his own company after graduation, Electric Owl Studios.

Seth Shain was the producer on Skyrates 1 and part-time programmer. He is now a designer at Midway Austin.

Sam Spiro, architect of the server side and economy co-designer, is a game programmer at CCP.





Return to the web version of this article
Copyright © UBM TechWeb