[MUD-Dev] Skotos Seven StoryBuilder Obstacles & Openings

[Christopher Allen]

Skotos Tech has long had a dream of empowering external developers
to create new games within the Skotos community. In the fall of 2000
Skotos selected an initial group of designers to do just that, which
we called the Skotos Seven. A year and a half later we're looking at
the obstacles that our original developers faced, and based on what
we have learned are opening up the doors to a new group of world
builders.

Shannon Appelcline has written an article on the obstacles that
these game developers faced, and how we are changing our
StoryBuilder program based on what we've learned. It is in the
Skotos Articles section at
http://www.skotos.net/articles/TTnT_65.shtml . It should be of
interest to any company that is using outside developers to create
games using inhouse tools, as well as potential future
StoryBuilders.

-- Christopher Allen

------------------------------------------------------------------------
.. Christopher Allen                                 Skotos Tech Inc. ..
..                           1512 Walnut St., Berkeley, CA 94709-1513 ..
.. <http://www.Skotos.net>               o510/647-2760  f510/647-2761 ..


Trials, Triumphs & Trivialities #65:
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.

   - 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.

   - 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.

   - 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.

   - 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:

   - 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.

   - Build a Sustainable Game. Have your team ready to move on to
   actual game administration when the creation is done.

   - Make Your Game Unique. It needs to stand out and to draw people
   in.

   - Make Your Game a Story. This is what will interest people and
   make your game memorable.

   - 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.




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev