Marking the Occasion

by Shannon Appelcline

October 24, 2002 - Last weekend I had the great pleasure of standing up for one of my best friends, at his wedding, as his Best Man. It was a humbling, touching, and gratifying role to be put in, and it made me very, very emotional.

During my Best Man speech, I recounted the fact that my friend had said, many times before, that he'd never get married. That it was a silly societal ritual. Yet here he was, having finally met the woman who was just right for him, and he was engaging in that ritual. And he was loving it.

I think a lot of us feel that same way in the progressive parts of post-modern America. I know before my own wedding, two years ago, I'd considered marriage an old, outmoded ritual too. Just like my friend, I'd assumed that I never would partake. But I did. It's the oldest story in the book: boy meets girl; boy and girl engage in fun hijinks; boy and girl get married anyway; boy and girl adopt two furry kitty cats and, sometimes, a dog, and live ever after. For the most part, happily.

So, why do we do it? It's no longer about passing a girl from her father to her husband. It's no longer about dowries, land, or political alliances. It's not even about permission to have sex.

As with everything, there are two answers. The first answer is ritual, which I've written about in the past in Trials, Triumphs & Trivialities #80, The Elements of Good Mythtelling, Part Six: Ritual Structure. The second answer is milestones, which is my topic for the day.

Because I can turn just about anything into a talk about game design.

Milestones for the Original Skotos Seven

We knew from the beginning, when we gathered our original Skotos Seven that helping game designers, arrayed at remote locations all over the world, to build a game from start to end would be quite a task. After all, we'd already done it in house, with Castle Marrach. Thus we understood that the care and feeding of an embryonic game involved week after week, then month after month, of solid, hard work. There were only two things that kept us moving: our community and the ever-looming deadline of September 21, 2000.

Yet we were bringing on external designers who had neither community nor solid deadline. We tried to figure out ways that we could provide the encouragement that they'd need, but it turned out that those exact two issues — community and deadline — would come back to bite us in the butt.

I've talked once before about the shortcomings of the original Skotos Seven program in Trials, Triumphs & Trivialities #65, The Wilderness of Your Intuition. (Our shortcomings, I should note, not theirs; we didn't yet have the right gameplan to support a development community.) That article was all about community. We'd hoped to generate a community among the developers, not then understanding that each game needed to have a community as well. I won't dwell on this point, except to suggest rereading the original article.

The question of deadlines was one we thought we understood when we rolled out the Skotos Seven program. We knew we couldn't lay down specific dates for the external builders, because they had their own lives that might not accommodate them. But, we did try to lay out crucial milestones which the developers could meet along the way. They were:

• Outlining the basic ideas for the game in text.
• Creating a small area for the game which could be used to tell a short, one-off story (a stage).
• Finishing up the full game for release, with initial, minimal features.

Unfortunately, our three bullet points for the original team might have taken 2-6 months each to complete. We needed milestones that were more frequent, for two important reasons that I'm just coming to understand now: we needed to build patterns of appreciation and closure.

The Importance of Appreciation

At heart, we're all operantly conditioned creatures. We do a task, and we get a reward for it, and so we're more likely to do that task again in the future... provided that we liked the reward. Working on a cooperative game design in a non-professional capacity is no different.

If, like our original Skotos Seven members, you go two to six months without any type of reward on a game design, or on any project, the chances are much more likely that you'll get burned out — that the behavior (game design or whatever) will be "extinguished". Because you've had no incentive to keep going.

Sure, the left part of your brain can intellectualize: "Well, if I keep at this for a full year, I'll end up with a nice game which will lead hundreds to praise my intelligence and creativity." But there's also the right half of your brain, speaking in its scratchy, visceral voice. "Not getting feedback. Not getting scritches. Want recognition. Bored now."

And thus, the first important reason for milestones. It's not about trying to make sure a team member is keeping up. It's about making sure that a team member can feel a sense of accomplishment in a short time period, and get the recognition and accolades he richly deserves for the cool work he's doing.

The Importance of Closure

Milestones also have another important reason to exist: closure.

When you're doing creative work, it's pretty easy to get stuck in an endless loop. It's not like you're working on a task which has a sharp, clearly defined end ("take these four stones across the street"). Instead, you can tweak forever. Add a plot; remove a plot. Add a character; remove a character. Add a paragraph; remove a paragraph. Add a word; remove a word.

Ad infinitum.

When is done done? Depending on your levels of perfectionism and anxiety, possibly never. Or at the least, sometime long after the heat death of the universe. Thus we reenter milestones — or possibly their less friendly cousin, deadlines. When is done done? When the project's due. And then you get the wonderful joy of getting to go work on something new.

Milestones in Game Design

With the newer Skotos Seven teams, like Lazarus Sleeping, Devils Cay, and Galactic Emperor: Succession, The Next Generation we've let the (generally large) teams figure out their own milestones and paths to completion of their game. If they're not full up on milestones already, then the one piece of advice I truly want to impart this week is quite simple: Design small, solid milestones into your game development process; they'll make your team members happy and keep things moving. However for Lovecraft Country we're taking a much more central role in the organization of the team and the development of the game. Based on that I can suggest some of the important milestones that we're thinking about, in developing that game. This isn't a complete list by any means, by rather some point-by-point areas that you can assign, begin work on, and finish.

• Design.
  • Outline the background.
  • Outline the main characters.
  • Outline the history.
  • Outline the future history.
  • Outline the main game systems.
• Development.
  • Objects.
    • Decide the categories of objects needed for your game (clothes, food, fish, whatever).
    • Decide the types of object that will be completed in each category.
    • Make completion of each category of objects a milestone.
  • Rooms.
    • Decide what rooms you need in your game.
    • Make a logical map outlining all of your rooms.
    • Divide rooms up into either locales (the northwest quadrant) or types of rooms (barber shops).
    • Make completion of each room locale/type into a milestone.
    • Draw a physical map after all your rooms are done.
  • NPCs.
    • Write a quick reference sheet for each NPC listing manners, background, history, quirks, commonly used verbs, adverbs, etc.
    • Physically create each character in-game.
    • Use as milestones individual characters or specific subclasses.
• Engineering.
  • Write sample typescripts for how each game system should look in-game.
  • Outline the algorithms of how each game system should work.
  • Engineer each game system; if a system is large break it into a few subsystems, which can each be a milestone.
• Release.
  • Release a small "Stage".
  • Release another small "Stage".
  • Release a simple version of the game.
  • Release a new system.
  • Etc.

That's it. Small systems. Small milestones. And in the end they hopefully help your builders find both appreciation and closure. And your game is a slightly happier place.

In Conclusion

So, how did we get here from marriage, exactly?

Personally I think that the reason that marriage hangs on, despite being a supposedly "outmoded ritual" is that it serves powerful purposes. It provides closure — both the participants and their friends realize that the couple is entering a different stage of their life. And, it provides appreciation. A married couple gets to feel the love, friendship, and happiness of their community, and it helps them to truly understand and solidify the commitments that they've typically already made.

We don't have these handy, neolithic rituals in the world of game design, and thus we need to invent them. So get out there and create some milestones of your own!

Next week: nameless things, shapechangers, and bloodsuckers. No, not another article about marriage. I'll see you in 7.

Recent Discussions on Trials, Triumphs & Trivialities: