The Upgrade Game

by Shannon Appelcline

April 11, 2002 - A long, long time ago in a galaxy far, far away, game design was about figuring out how you were going to build a product, building that product, then moving on. Today releasing a single game — or really any piece of software — is more of a career than a milestone along the way, and if you're not aware of that, you're going to get flattened when you try and put out your first online game.

It all started subtly enough with innocuous little patches. There was a bug in your release of Wordstar, so you'd fire up your 1200 baud modem, connect to the Wordstar BBS and spent a few hours downloading the 50k file. Big, big software programs like Microsoft Windows or MS-DOS would even get new releases every couple of years, but they were really big deals and included genuinely new and expanded abilities.

Somewhere along the line, though, someone had a brainstorm. They realized that this whole idea of continuous releases could help them cement a user base, allowing them to continue to appeal to the same customers because they were always releasing the same types of software. And so one day someone released a Zork II (1981) or an Ultima II (1982), or a Wizardry II (1982) or an Archon II (1984) and they saved a lot of programming time and writing time — because the code and background was already there — and they had a built-in audience; on top of all of that they got to charge just as much for the second, cheaper-to-make product as they did for the first. In the last ten or so years, manufacturers have learned how to cut corners even more by releasing "supplements" to existing games that usually offer minor additions — for about half the price. It's Henry Ford's assembly line for the late 20th century.

Now, in the 21st century, continuous software release is becoming a fact of life. As usual it's Microsoft who's carrying it to the terrifying extreme. With Windows XP they're hoping to create a subscription-based model for software delivery where you pay your $9.95 a month or $99.95 a month, or whatever, and get bubbly Windows goodness delivered down your cable modem line every month.

And that brings us to online games.

With an online game you're facing three important realities:

1. Players are used to their software being upgraded every year or two, thanks to the evolution of non-networked software marketing over the last two decades.
2. Individual players will explore your entire world within a fairly short time period — between a few months and a year.
3. Your most valuable commodity will always be, not your software, but your community, and if you have large churn rate from people leaving because they've "seen it all" you'll eventually fail.

And that's why you too must join The Upgrade Game.

Administration: An Interlude

Before I get into upgrading games, I want to take a brief pause and speak about administration. You see, it all fits in with my main point this week: running an online game is a continuing task. When you release your first version of the product, you're not even halfway done.

The biggest chunk of your time after release, even if you decide never to build another system, is going to be keeping the game running. Like every software release ever your game is going to have bugs in it, and fixing those is definitely part of administration. If anything it's even more important than fixing bugs in a single-person piece of software. Because, if a bug benefits one person to the deficit of another, you're going to hear complaints. No matter how cooperative your game is supposed to be, there's going to be an edge of competition underlying everything.

Closely connected to bugs are human UI issues. If something's non-intuitive, you're going to hear about it constantly, just by the mere fact that your administrators are easily accessible. And you're going to need to eventually fix those UI problems for your own mental well-being if nothing else.

And that's just the tip of the administrative iceberg. There will be many more administrative requirements, but the exact shape of them will be determined by the sort of game you're building. At Skotos we classify all of these other functions as StoryTelling. It can include:

• In Castle Marrach: helping out newbies, resolving interpersonal conflicts, and telling stories.
• In The Eternal City: dealing with exploits, scripting, and other cheating; helping out newbies; and telling stories.
• In Galactic Emperor: Hegemony: finetuning web pages and systems to resolve user problems like no-shows; nudging web pages and the user interface to make it more accessible to newbies; and, in our roleplay game, telling stories.

No doubt you've noted the repeated themes here.

Again, the main point is that post-release administration is a big deal. Make sure you're thinking about it when you're building. Take a look at my administrative topical index for some of the things I've written about administration in the past, here in this column.

Our Upgrades at Skotos

And that brings us back to upgrades. Upgrading your game — expanding it in ways larger than just fixing bugs — is going to be a necessity once you actually release it. To put that in perspective I'd like to offer some information on what we've done to change our games since we've released them.

Castle Marrach has been around for a year and a half now — exactly as long as this column. When we released it, on September 21, 2000, it really wasn't done. We'd built the Outer Bailey — a third of the Castle as we intended it. We'd populated it with people and groups. We'd gotten our core systems to a pretty good state — things like consent and our verb system which are so fundamental that you might almost forget about them today. But there wasn't a lot more...

In the year and a half since first we, and later the external StoryPlotters and StoryCoders, have built in bursts and dribbles. Some of it was clearly required and always intended, like the dueling system, which was finished up a week after release. Remarkably we've found that some "required" systems like favour and reputation really weren't needed because they were taken care of in other ways — in these cases by roleplaying.

Much of the Inner Bailey was built for the first Winter Ball in December 2000, and it largely followed our original specs, but other expanded areas have been primarily the result of player desire. Who would have imagined we'd need to set aside so many areas in the Castle for player groups? Not we, but we've happily expanded in those ways as players have directed.

Along the way we've also learned on occasion where we were flat-out wrong. For example, we'd originally thought that we didn't need game systems in Castle Marrach, with the exception of dueling, but time and time again we heard that players wanted systems that allowed growth and improvement for their characters. Something to do with their characters beside just roleplay. Even as The Eternal City was coming on line it was becoming clear that simply suggesting people play a different game which did include that type of gameplay wasn't enough — because some of those players had become enchanted by the story we were telling in Marrach — and by the other people who inhabited it.

So, in the middle of 2001 we introduced skills and training. Gameplay elements like this will never be a big part of Marrach, and we've tried to orient them toward the social milieu as much as possible, but they were requested, so we included them.

Galactic Emperor: Succession, though now on indefinite hiatus due to two failed gameplay models, as discussed in Trials, Triumphs & Trivialities #62, Galactic Empires, Part One: Failing at Succession, offered us many of the same lessons as Castle Marrach.

Twice we put the game out and twice we pulled it back because players just weren't having fun. We learned that our gameplay models might be totally irrelevant when faced with player feedback. That player feedback — or at least player interest — was an important tool to use when considering what to upgrade and how to do so.

Galactic Emperor: Hegemony hasn't been around nearly as long as our other games, but it has already been upgraded in a number of minor, but important ways. I've added a system to build maps out of geometric shapes. I've built a neat new display to show standing orders for stars. I've done any number of minor player UI upgrades. Lastly I've opened up Abode, a totally new venue to roleplay Hegemony characters in.

Some of the upgrades have been based on feedback, some on where I want the game to go. I'm pretty sure that the players have been happy with what's been done so far — at least with the more visible things that have been added.

Making Specifics General

So, what can we learn from what we've done here at Skotos so far? I've personally discovered a number of general rules which I think will be useful for anyone entering The Upgrade Game:

Take Player Input Seriously. After all, the day you release your game, it becomes theirs, not yours. They might not know all the reasons why things are done the way they're done, and thus they won't always have the best solutions for how to expand things... but they'll have a lot of good ideas. They'll also tell you what you're doing that just doesn't work.

Take Your Own Input Seriously. You're always going to know the obscure reasons for decisions, and you're always going to be able to have a purer perspective about what type of game the game should be. Keep those in mind.

Small Changes are a Big Deal. My addition of a standing orders display to Hegemony, which is probably the coolest and most visible thing I've done since getting the game, took about 30 minutes to program. On the other hand, my system of Hegemony Nicknames took maybe 8 hours of initial programming and may take another 8 hours to do them right now that I understand more how they need to be used. That small change was a big deal for the users, while the big change was not.

Balance the Visible and the Invisible. A close corollary to the above. Although all of your upgrades will probably benefit the users, the more visible ones will seem like a much bigger deal to them, even if the less visible ones have a larger long-tem effect. So, balance them. After all, keeping your players happy is much of the purpose of continuous upgrades.

It Doesn't Have to All Be Engineering. One of our most acclaimed and anticipated upgrades to Castle Marrach was the opening of the Inner Bailey. That was pure development work, using existing systems and little more. So, don't feel like you have to constantly reinvent the wheel with new systems; just producing different types of wheels is often sufficient.

Always Take the Time to Make Your Game Better. As an online game designer you're in the unique position to make a game better than a single-person game ever could be. You're going to keep upgrading your game for years and years and you'll be able to incorporate the real-time feedback of hundreds, perhaps thousands, of very intelligent people. Take advantage of that by not just expanding your game, but also refining it. Hegemony's Abode will be better for the years of work put into the social system for Marrach. Your own game can take advantage of that and the years' worth of lessons that you learn as well.

And that's it for this week.

Building a game is a continuing task, and I'll see you next week, in this continuing column.

Recent Discussions on Trials, Triumphs & Trivialities: