The Wilderness of Your Intuition

by Shannon Appelcline

March 21, 2002 - A year and a half ago, Skotos announced the first five members of the Skotos Seven. These were external developers who were going to be using the tools Skotos had built to create their own game worlds. It was a great idea, and Skotos did have the tools to pull this off. Castle Marrach, after all, had been developed by a handful of non-engineers.

A year and a half later, no Skotos Seven games have come to fruition. Some of the Skotos Seven officially announced their departure, as Gareth-Michael Skarka did in Signals from a Dead Channel #15, Fading Signal. Others just sort of faded away.

We still have a lot of faith in the concept of external developers. We've got three teams still officially working: Sam Witt is still leading Horizon Station, as he has been from the start; relative newcomer Laurel Stuart is working on Devils Cay; and a gentleman named Matthew Gaston is working on an Og game for us (though it's currently on hiatus). In addition, we're ready to start looking at new applications.

If you've been interested in writing a game for Skotos, this is your opportunity to get your foot in the door. We're going to be making some more announcements very soon about what types of games we'd really like to see. We're also going to be reviewing all the apps we've received in the last year or so.

With us standing on the crux between old games and new possibilities, however, it seems like a good time to look back and say ... why didn't that first group of external games work out?

Overall, I'd say there were two big problems: StoryBuilders going it alone and a lack of understanding about the commitments required to create a game.

Living in the Wilderness

The biggest problem with the original Skotos Seven was probably in how we formed the teams. We recruited seven people at first; since we've learned that we probably should have recruited the Skotos Thirty-Five, or so, and formed them into seven teams. In all honesty one person just isn't enough to create a whole game, especially not doing it part time, and working in isolation. They don't have sufficient resources and they don't have much encouragement.

We actually realized this a over a year ago. I wrote an article on how important gathering a team was in Trials, Triumphs & Trivialities #30, The Team's The Thing. We've also worked hard to get new and continued builders hooked up with other people interested in their world. However it continues to be an issue, as some of the newest people submitting proposals to us haven't really considered anything but building their game on their own.

But going it alone doesn't just hurt in not having enough hands. You also often don't have enough hearts. We didn't really realize beforehand how hard it would be for a single person to create a game, sitting in his home office, and writing on his own. Even if he had all the time in the world, without people providing feedback — without feeling that he was part of a community — productivity was likely to grind down.

I'm pretty sure this latter reason is one of the big reasons that we lost some of our original designers. We've been trying to draw the whole community of designers together, but it's a hard task, with us each living in different time zones, with us each living different lives. However, each StoryBuilder can do a lot by building communities within his team — through e-mail or live conferences.

Commitments & Expectations

The other big problem with our original Skotos Seven had to do with commitments and expectations. People didn't know what they'd be able to produce or how much time it would take.

When we first signed our original Skotos Seven we worked really hard to suggest that they should be thinking about a game like Castle Marrach — a primarily social-based game with a great backstory and ample opportunity to roleplay. We tried to make it clear that we didn't have systems in place to do things like complex skills or intricate combat.

At the same time, we were saying that programming knowledge wasn't required — and if people had built games like Castle Marrach that would have been true. A writer can create everything required for a basically social-based game. But, that's really not what people were interested in creating. Sam Witt has done beautiful work on game systems for Horizon Station which will be terrific some day. He's not the only developer to have done so. In the end we had a very basic disconnect on our hands. We were telling people that they could create games without programming knowledge, but those same people were entirely interested in creating games that required programming knowledge.

We've given up on our "no-programmer" tagline for Skotos games. We're now suggesting that every team should have at least one engineer — to write the basic systems that a designer envisions. We're also doing what we can to put increasingly powerful programming tools in that engineer's hands. The rest of the team probably still can get by with writing skills, but we now see that someone is required to take over the system-construction part of things.

Take a gander at Trials, Triumphs & Trivialities #33, What A StoryBuilder Can Do for some more discussions of what requires programming and what doesn't in the Skotos system.

The fact that our original Skotos Seven almost all wanted to build really big games also had a big effect on the original time commitment. We'd been figuring 6-18 months for each of the first games. We'd said a social game like Marrach was like writing a novel. Unfortunately, our StoryBuilders were all constructing more complex games, and so those novels became trilogies and open-ended series. In addition Jeff Crook, one of our original Skotos Seven, offered a caveat to my statement. Sure it was a similar time commitment to writing a novel, he said, but it was the time commitment you would expect if you had never written a novel before.

Being A Successful Developer

So, with all that said, how can you be a successful external StoryBuilder at Skotos? What can you do to be one of those people who gets a game out, and not someone who falls by the wayside in the next year or two?

My best suggestion is to learn the lessons that we've discovered to date.

1. Build a Team. Don't try and go it alone. Instead form a group of interested people. Get at least three people at start, if you can, and then expand it. The Skotos community has already proven a great place to discover StoryBuilders, but your work, school, or community might be good draws too.
2. Include a Coder. We give up. You're not going to just build a social game. So, make sure you include a coder on the team to engineer the systems you envision.
3. Form the Team into a Community. Once you have a team you need to figure out how to keep them all connected. We're happy to help here, at minimum by setting up a mailing list. If you can get just a few rooms built fairly quickly for your game, then you can have a nice live place to meet too. We're also working hard to create a community of all of our external StoryBuilders. Help us out by participating.
4. Be Aware of Time. Making a game will take a while, especially if you've never designed a prose-based game before. Be aware of that, and be aware of how adding systems will increase that time. If you can figure out a cut-down version of the game — smaller in space or in systems — to release first, you should. It'll make you feel a lot better to have something out there, and will also allow you to start getting feedback from your players almost immediately. As I've mentioned in both Trials, Triumphs & Trivialities #39, Ah, Sweet Simplicity of Life and Trials, Triumphs & Trivialities #62, Galactic Empires Part One, Failing at Succession, building complex systems all at once without feedback can be disastrous.

Those, together, form the psychological and practical guidelines that I think external StoryBuilders should abide be in order to successfully get a game out the door. There are a bunch of other, more design-oriented suggestions which I outlined back in Trials, Triumphs & Trivialities #17, Why Yes I Am God!. In brief:

1. Build a Contained Game. Not only do you initially want to keep things small, but you also want to offer good reasons for that smallness.
2. Build a Sustainable Game. Have your team ready to move on to actual game administration when the creation is done.
3. Make Your Game Unique. It needs to stand out and to draw people in.
4. Make Your Game a Story. This is what will interest people and make your game memorable.
5. Make Sure You Know How Text Games Work. A lot of the initial proposals we didn't accept didn't show a good understanding of how text games work. The biggest problem, generally, was expecting text games to follow the same rules as tabletop roleplaying games — i.e., presuming that you'd always have people around to run them. Clearly, not the case.

If I were to expand any of my design discussions, I'd simply say: come up with a vivid central idea for your game. It should be something that takes your breath away, that is immediately picturesque. You want what entrepreneurs call an elevator speech: a 1-minute explanation of what your game is.

If you can do that. If you can, concentrate on a solid central idea — a spark that you can blow upon to make it flower into a raging fire. Then you've got your start. Collect your team, find your coder, build your community.

The rest is gravy.

Recent Discussions on Trials, Triumphs & Trivialities: