#30: The Team's The Thing

by Shannon Appelcline

April 19, 2001 - Text-dominant entertainments of the type that we're developing here at Skotos are both really small games and really big games. And that's what I want to talk about this time around – the teambuilding aspect of StoryBuilding at Skotos. It's not a requirement, but it just might be a really good idea.

Before I move on, however, I should probably explain what I mean a little bit. Saying that our games are both "really big" and "really small" is either a bit of black magic or a Zen koan. But hopefully it caught your attention. Read on.

When you compare a text-dominant game to a graphical game, it becomes obvious that they're really small. A graphical game can take hundreds of people, millions of dollars, and several years to produce. On the other hand, presuming that you've got a good game engine in hand and a simple design system – and that's what we plan to offer you here at Skotos – you can create a text-dominant game in a few months.

But, that's not to say that designing and developing a text-dominant game is just a few evening's work. And that's where the "really big" label comes in. We've accepted proposals from a number of individuals, but we think that they'll have to work hard if they remain on their own while designing their games. Timewise, we figure designing a Grand Theatre might require the same time commitment as a novel, while a World might be a similar time expenditure to a whole trilogy of books – or more.

Really this week I'm only offering one simple rule to StoryBuilders: Be aware of the time commitments required for designing a game, and be aware of your own resources. But, I want to talk about that a little more, to see how teamwork works in the design process and to offer a few things to watch out for.

You'll probably note that I'm keeping my column shortish this week. I've just finished Act I of my screenplay for my final screenplay class and it's already late. I'll make it up next week by ransacking through my screenplay class notes and seeing what else I learned that should be passed on...

Development Teamwork

In case it's not obvious to any StoryBuilders out there, let me offer the following gem of wisdom: creating a game is a big task. I'll allow you a few minutes to pick yourself up off the ground and rearrange your clothes. I'm sure that came as a shock.

But, really, I'm not kidding. Creating a game is a big task. Take a look at Castle Marrach as a quick example. Any day now we'll be opening up the Inner Bailey. It totals about a hundred rooms, every room having a multitude of details, every detail having the potential for glance, look, and examine descriptions. And, as our system grows more complex, every one of which has the possibility to have all kinds of weird responses, secret doors, gadgets, or what not.

I haven't written any room descriptions, but Michael, one of our designers, has, and he says it takes at least an hour to do a good job of detailing each room. So consider that, and consider all the rooms you want for you game, and all the NPCs, and all the monsters, and all the items. To say nothing of the actual game design and plot development.

Add. Multiply. Rinse. Lather. Repeat.

Right there is why you want to consider a team if you're StoryBuilding. Because of the raw amount of stuff you need to write.

But there are also other big advantages to having a team while you're developing. As you work on your game you'll find that there's a lot more to do than just write. Before you can create a single room you need to design how your game will actually work. You might want to draw maps or sketch out simple drawings. Someone has to write the documentation.

Likely, one person isn't going to be good at all these things; by letting multiple persons work on your world, you're just making your game better. Here at Skotos, for example, I'm probably the only person with the temperament to write docs. (Who would have guessed from my weekly blatherings?) So I do, and hopefully our docs reflect the enjoyment I get out of drafting them.

Teamwork.

Post-Release Teamwork

In the development phase of your game, teamwork is what I'd call "a good idea". Not required by any means, but a great way to break up some of the longer tasks and also to take advantage of a variety of expertise.

Post-release, however, teamwork isn't an option. It's required. (Another rule, I suppose, putting lie to my statement that I was only going to offer one this week: Figure out how you'll support your game post-launch before that launch.)

I've talked about our Castle Marrach launch before. We had about a dozen people hosting during those first weeks. In recent weeks we've dropped down to two Skotos employees doing some fraction of full-time work on the game... but at the same time volunteers have come in as StoryGuides and StoryPlotters.

Castle Marrach is a weird case, because so little of it is moderated by game systems and so much of it is dependent upon inter-game interactions, but every single multiplayer online game is going to suffer from some variant of these same requirements. If you want your game to run 24x7 – which is to say if you want it to be a real game and not just an occasional one-off – you have to figure out ways to staff it, with people to answer questions, with people to resolve problems, and with people to help keep the game running.

We're going to be making StoryGuide and StoryPlotter kits available to our StoryBuilders, so that they can give volunteers the opportunity to help improve these new communities... but a StoryBuilder also has to figure out how to create a network of people to oversee the whole game. That's going to require more than one person, provided that the StoryBuilder wants to do other things... like work... or sleep.

The Problems of Partners

Though I'm fairly thoroughly advocating teams this week, as my experience tells me that they're the best way to create online game, at the same time I'd like to offer a few caveats. We have had teams working on Castle Marrach, and on occasion that's caused problems. More rules, it appears:

Be sure someone is in charge. This problem won't be a problem for most folks, as I expect most gaming proposals to be centered around the ideas of one person. But, if you're working as part of a truly democratic team, make sure you all know who the boss is. Because, you're inevitably going to end up with creative differences, and there needs to be someone to arbitrate them.

Maintain communication. In order to build a coherent world, you need to make sure everyone is on the same page. This is especially a problem if you're geographically removed. You can overcome it by staying in good communication with all your team members. Here at Skotos we use a collaborative web environment called Twiki so that everyone can see what everyone else is writing. Email lists and regular chats can also serve this purpose.

Maintain consistency. You'll be aided in this directive by your communication, but you should be aware it's an all-encompassing issue. You need to be sure all of your room descriptions are written in the same style – or at least that all of your looks are in one style and all of your examines are in another (or that everything is consistent by some other clear division). You need to make sure that there's a single atmosphere and mood. You have to make sure your background is consistent – that everyone is designing the same type of games. Public MUDs and MUSHes tend to have terrible consistency problems, because you have widely different people with different ideas working on the same game. We hope to overcome that problem here at Skotos by giving people the opportunity to create lots of different games – but within those environments leaders need to keep things together, or the advantage is entirely lost.

A Conclusion

Before I close I want to say one last time that a single game designer can create a game at Skotos. In fact, his consistent vision might result in a much stronger game. But, he should be aware of the time commitments that will be required.

A team of builders is an excellent way to lower these time commitments – and absolutely required by the time you release anyway. But, as always, be aware of problems that collaboration can bring.