Continuous Game Design:

Opening Remarks:

Designing your game does not end when you finally open your doors to new players. If you try to end game design there you're going to run the risk of a stagnant game. Stagnant games quickly become dead games! There are six areas which you will need to keep a constant eye on. As you evaluate these areas do so with an eye towards the mission and purpose of the game, but also keep an eye on what the needs of the players are.

Story Arcs:

Whether you are about to open the doors on your game for the first time or whether you've been at it for awhile, you should always keep an eye on story. Story first and foremost, because it is the role play, and by extension the story, that brings your players and keeps them.

You should design a story arc. A story arc is the overarching theme or series of events that you're going to hang your tinyplots around. I like to plan my story arcs with an eye towards executing them in about a year's time. A story arc is not a scripted plot. Rather it is a situation. Design a situation that grows out of past events or the back story of your game. Design the potential endings you are trying to get to. Keep it loose, keep it simple, but keep it there, in mind.

On Heroes much of the story arc has revolved around the Dark territory that was open at the start of the game. The first arc, with all references to the canon material removed, might have read something like this: "An evil nation sets up its headquarters less than a days ride from the home of the legendary magic users that protect the world. Now the struggle between light and darkness that has raged for 170 years and divided the world escalates to a fever pitch as the two nations clash and draw the rest of the world into their struggle."

Obviously the "end" of the arc came when that nation had changed sufficiently to demand a new story arc, which then grew up out of the situation caused by the end of the first.

TinyPlots:

Next you should bring out your trust notebook again. Jot down ten tinyplot ideas. Keep the participants vague. You are, after all, trying to involve players, and you really don't know who is going to show up and who is not. About half of what you write down should be related to your story arc. The other half should be subplots, other complications that cause problems for your players to solve. For example, in the first year of Heroes we also had a plague that the magic users could not cure with their magic. The plague had little to do with the war, but struck both nations simultaneously. When they weren't at war they were trying to get healthy again. Between those two problems alone there was plenty for the players to talk about and get involved in, but we added a third: a race to be the first to research a method that would allow instantaneous travel all over the globe. We offered that last as a sort of competition. Since both areas had their magic users, whoever achieved a set number of RP'd research sessions on the method won the day for their nation. The competition was intense!

Corrective Plots:

You think, perhaps, I've moved rather far afield of game design here. After all you've heard of tinyplots and story arcs already, and you've never thought of them in terms of game design before. However there is a third sort of plot which I like to call the Corrective Plot.

The Corrective Plot happens when you have a creative, enthusiastic player that runs a terrific tinyplot that gets everyone involved. The plot, though, has some elements that don't get cleaned up when the plot is over, and those elements threaten to wreak havoc on your entire grid. Perhaps the plot spawns a character who is so insanely powerful that he's become an OOC annoyance to everyone. Perhaps it threatens to unravel theme so that newbies don't have any chance of figuring out what the heck is going on.

It is up to you, then, to identify what elements need correction and create a tinyplot to address them. That's right. A tinyplot to address them. Not a nasty letter, not a retcon, not a blanket policy which forces people to your vision of the game, but a tinyplot to gently guide them to your vision of the game. This achieves a few things for you.

First, you won't become known as a raging dictator who has no sense of fun. This is important.

Second, you will provide more RP for the game -- and you won't need to work too hard at it because the whole tinyplot just grows out of a specific need: the need to get these problematic elements off of the grid. After all there are probably characters who would also like to get these elements off the grid. Now you are creating plots which play into character goals, instead of removing elements that their characters have agonized over, planned for, and centered their RP around with a wave of the wizardly wand.

A Corrective Plot can masquerade as a tinyplot or a story arc. But it is an essential tool for continuous game design.

Policies:

Here is the bad news. You are going to create a bunch of policies that do not work. Before your game opens you are giving your best guess as to what policies will best serve what you are trying to achieve. Some of those policies are going to come off beautifully. Others are going to get in the way. Or you won't make any policy at all on something vital that turns out to become a huge problem. You simply won't know that policy is needed until the whole situation is dumped in your lap. Be flexible. Be willing to get rid of policies or change them. Be willing to write new policies. Get used to saying, "the current policy". If you have to make a snap decision -- and you will, because you won't have a policy on some of the weird questions your players will come up with -- that is a precedent and you have to stand by it later. If you let one of your own characters do something outrageous, that is a precedent and you have to stand by that.

My rule of thumb? You cannot hold players to any policy that is not in writing in your news files. You can't penalize a player for a policy in place today that you didn't have in place yesterday...but you can certainly enforce the policy from the day of its implementation forward. You should never put a policy in place that directly contradicts what a bunch of players have been playing for a year because that's how long it took you to decide you didn't like what they were doing. No policy is sacred. If its not working, dump it.

I like to review my policies on a very critical, policy by policy basis, about once a year. The process actually does get shorter each year that we're open. Still, those policies you wrote before you got your first player are not set in stone.

Descriptions:

Your room descriptions aren't sacred either. If you have a tinyplot that flattens the town square, you should get out there and change the description to reflect that if the town square is going to remain that way for awhile. If the economic conditions of a once prosperous town have gone south, then get out there and make all the paint start chipping and peeling.

You really shouldn't have to do this too often as most conditions are temporary and can be handled simply by sticking a sign on the area indicating what the room's current condition is. Still, if you want a game where your players have an impact on life in general, be willing to rewrite and revise to account for what they've been up to.

Code:

Sooner or later someone is going to suggest a code that is needed or wanted. Sooner or later your code wizard is going to want to do something cool. My advice is to let them. That's the easy part of continuous game design when it comes to code.

The hard part comes when you realize you've got 200 created characters on grid and your character generation process is not up to par, or some other system you have that is widely used is not serving the game. My only pointer there is to make your changes quietly, quickly, and with minimum fuss, and then provide a clear explanation of what you did and why you did it. And be prepared for the complaints, because there's folks who will always like the old way better.

Final Remarks:

Part of the magic of a MUSH is that it is a living, breathing environment that a person can log on to, interact with, and change. At least, I believe it ought to be a living, breathing, dynamic environment. People like to feel as if they have a chance at impacting the game's greater storyline and in general you should try to design ways for them to do so. From the moment you open your doors you have reached a point where the game no longer belongs to you alone. Keep an eye on the game's pulse and correct your course as necessary, and you'll develop a loyal player base who appreciates your fair attitude and flexibility.

Back.