Browse freeroleplay: This Month's Archive • Main Archive Page • Related posts • Previous by Date • Next by Date

[freeroleplay] Re: Vanilla Fantasy Worlds

From: Bryce Harrington <bryce@xxxxxxxx>
To: <freeroleplay@xxxxxxxxxxxxx>
Date: Sat, 26 Jul 2003 17:38:05 -0700 (PDT)

On Sat, 26 Jul 2003, James Jensen wrote:
> First of all, what I call "vanilla" worlds are easy to get started in,
> since they don't actually require extensive reading on culture and
> history -- a brief overview does the trick. Secondly, they allow for
> more flexibility in campaign events, since there are fewer intricasies
> to worry about. Thirdly, a GM need not feel their creativity limited
> when wanting to introduce new monsters or races, as this sort of thing
> blends naturally into the atmosphere of a vanilla world.

Another nice thing is that adventures set in these worlds are not highly
tied into the world, so that a GM could cherry pick from the adventures
for his own game world.  I used to take great advantage of this with the
old AD&D1E modules, that were set in Greyhawk but easily imported into
my own world.

> If there aren't any, then I think we need to make one. I've already got
> the beginnings of a map and some ideas to go behind it, but I feel
> uncomfortable about the idea of jumping feet first into the waters of
> advanced project management. However, I could probably have something up
> on my personal website next week, which, while not an open project, is
> at least usable for the Free Gaming community.

A few tips I can offer, having run a few projects before...

* Lay out some ground assumptions up front, as established and
  unchangeable.  You don't want to pick so many assumptions that it is
  constraining for people, but you want enough guidance to help avoid
  dissent later.  For instance, high vs. low fantasy, base rule system
  (or rules neutral), the overall magic/tech/power/etc. level, etc.  It
  can help to point to an example you'd like to "clone".  For example,
  "Sort of like Greyhawk."

* Don't lay out timelines, don't give out assignments, and don't expect
  contributions from anyone.  It's a hobby, not a job; if it looks like
  a job, it won't be fun anymore and people will get burnt out.  ;-)

* Design the project to be modular.  What this means is that each
  individual should be able to have their own sandbox to work in,
  without having to coordinate with others and make frequent revisions
  as people have new ideas.  This is very conducive to the "Vanilla
  World" approach.

* Avoid interdependencies between people.  If you can't do your part
  until Bob does his, and Bob goes AWOL, then you're stuck and everyone
  feels bad.

* Decide the preferred documentation approach.  If all the content can
  be kept in a common format it'll make maintenance be straightforward.
  I would recommend doing it in plain text, because that way none of
  your contributors need to learn anything or install any software.  You
  can use or make tools to put the text into TeX or DocBook or whatnot.

* Cut releases often.  You may want to have a bunch of individually
  released components, that are "bundled" into a single package, that
  someone takes responsibility for putting out once every month or so.
  Heck, as soon as you figure out packaging, release a 0.0.0 with
  nothing in it.

* Set milestones.  Define some specific, reachable objective and call
  that 0.1.0, and another and call it 0.2.0.  Keep the goals to things
  that are within reach so the team can actually achieve them in a
  reasonable amount of time.  Leave it flexible enough that changes in
  personnel won't totally disrupt progress.  I.e., instead of "Design
  Polumbria" say, "Design one large nation, 12 pages".

* Make it straightforward for people to contribute new components.
  Ideally, the process should be entirely automated so that a new author
  can get their work published without having to talk to anyone.

* Consider internationalization.  If the project is successful, people
  will want to make translations.  Figure out a process for making this
  work, so when someone wants to do it, you know how.

* Lastly, don't forget about publicity!  The project isn't going to get
  attention, users, and new contributors just out of the blue.  Write
  articles for 'zines about the effort, get the releases mentioned on a
  variety of gamer sites, and try to build relationships with other
  projects to share efforts.  Also think about getting booths at
  conventions so you can meet people and show off the work.

Bryce

Follow-Ups:

[freeroleplay] Document Format Question (was Re: Vanilla FantasyWorlds)
From: James Jensen

References:
- [freeroleplay] Vanilla Fantasy Worlds
  - From: James Jensen

[freeroleplay] Re: Vanilla Fantasy Worlds

Other related posts: