There are certain things that I’ve done and that I’ve seen done that can contribute to a world imploding during development. As I’d mentioned in earlier installments of the Etilica postmortem and as Phil had also mentioned in the comments, Etilica needed to be “clean” when it left beta. How might have this been accomplished? You need solid preproduction. Professional game developers tend to use terminology derived from the entertainment industry. Thus, instead of requirements, specification, design, development and testing phases, they have preproduction, production, rollout and operation. There is a pretty clean overview of this process, written by Richard Bartle in his book, Designing Virtual Worlds. Some of these bullet points are not entirely applicable to small teams and hobbyists, but the basic idea holds. I can say from experience that you should not skimp on the preproduction phase. I can’t guarantee that having one will be the magic bullet of your success, but not having one will give you grief.

At the end of “preproduction”, you want to have to following two things:

A design document that you can always refer back to – There are excellent write-ups here and here on Gamasutra for writing design documents. “Real” designers may have better things to do than write documentation when they really want to build, but that document will encapsulate your vision for everyone on the team. If your team always remains one or two guys, you can get away with not doing this. This document will entail how the subsystems (of the prototype below) function, how gameplay works, special shticks if the world has any, and basic, bullet pointed lore.

A working prototype with all of the core systems in place – A barebones world with all of the core systems in place should be playable. It may not be recognizable as the one you are planning to build; in fact, it is better if it is not. It does need to have all of your complex custom subsystems in place. Do you have a unique faction system? Do you have a custom dynamic encounter system, loot systems, crafting, character advancement, death, scripted AI, etc? These should all be in place.

A professional team would probably just have something minimal to show case gameplay ideas and leave their implementation up to the programming team during production. For a world build by volunteer hobbyists and indies, you’ll need more. The industry term for a pre-alpha, yet vaguely playable level mockup is a hull. A hull has no visual details and probably only has a plain texture thrown on the geometry to be able to see it in a game engine. It is just for testing concepts at this point.

You’ll need a keel (yes, a play on hull) for your world. You and the team you recruit will be extending it from there, but the foundation remains the same.

What you should avoid:

Resist the allure of “agile methods” during preproduction– Many amateur worldsmiths have probably never heard of agile methods, such as SCRUM. It can be an alluring idea. The central concept behind agile methods involves creating a deliverable every 30 days (or 20 days, or 6 weeks, etc.). The opposing approach, known as waterfall development, is currently out of fashion among software developers. Its premise was first you clearly define your requirements (qualitatively what the software will need to accomplish), then you clearly specify a set of key performance indicators (KPI’s) in a specification document (quantitatively what the software will need to accomplish), then you design it from soup to nuts and finally you sit down to write the code. The idea is that the code will flow and be relatively (not completely) bug free. Waterfall development often suffers from the problem that requirements are not completely known initially, or change, or that a proposed design element is not as completely and utterly awesome as envisioned once coded.

Agile development came into fashion because it addresses this. Taking your development in bite sized chunks has great merit. Ensuring that you have a deliverable every 30 days is a great way to keep moral up (after all, milestones are clearly being reached). A protracted design phase – as happens with waterfall development methods – can give people the feeling that nothing is happening and cause them to leave. I’ve seen this firsthand more than once. Often, there is some guy insisting on doing iterative development from day one. If you follow his advice, your group will quickly make progress and will be passing around its first screenshots in no time. In fact, I’ve seen more than one group on MMORPGMAKER use screenshots as the evaluator of progress. Then sometime down the road, you’ll run into a wall where your world is of undocumented complexity or there is no clear consensus about a particular design point.

Having a design document to refer back to prevents this. Save the SCRUM for production. In fact, you will be practicing waterfall development where preproduction is the requirements/specification/design phases all rolled into one and production is the implementation phase. Learn to love it.

Don’t recruit your team until after preproduction – Remember what I said about members feeling that nothing is happening? During preproduction, there will be a phase where it seems this way. After the initial brainstorming phase, there comes a period when you have to flesh these ideas out and come up with a design document and perhaps some code design to do with it for the prototype. That modeler you recruited from deviant art on the second week? He won’t have anything playable to put his models into. That lore writer you found? At this point, she’ll either start rewriting your cannon or will get bored and go back to whatever forum you found her on. That programmer you found on sourceforge? Programmers have a habit of measuring their productivity by code written. This is especially so for undergrads looking for a project to burnish their resume with. Once you have a design document in hand, have chosen an engine and prototyped your main gameplay elements, your project will look much more attractive and will give a greater feeling of progress. It will be much easier to recruit and hold onto people.

Lastly, having a design document handy when recruiting allows you to recruit them into the vision. I can’t stress enough the need for all of the team to drink the kool aid; even if nobody else in the universe does. This allows your world to have direction and not turn into a herd of cats.


About Dave

I’m a 38 year old American who has lived the past 9 years in Germany and India.
This entry was posted in Uncategorized and tagged , . Bookmark the permalink.

4 Responses to Prepreproduction

  1. D^t says:

    Great write up though probably the most true bullet to me would be not to recruit till after preproduction.

    After sitting n both s ides of the fence (project manager and programmer) I can say if you don’t bring in your people with a clear and complete design doc – you might as well not bring them in. You are only wasting their time and your money.

    Don’t get me wrong, the design doc can change on whim but without at least a skeleton list of short term goals which they can, at the very least, extrapolate what your long term goals may be, budgeting time and keeping moral will be very difficult.

    I’ve never worked on an mmorpg before but I can imagine the same principals can be applied. Good post.

    • Dave says:

      >probably the most true bullet to me would be not to recruit till after preproduction

      In my experience, this is the #1 killer of amateur and indy projects. Sourceforge is littered with the hulks of abandoned text, 2D and 3D worlds. In nearly every case, there was a group of people who got together (or an individual who recruited a group of people) to make a world. They had lots of great discussions about theory and then… nothing. Probably half of them were never the least bit serious and were what I call pontificators; those players who like to discuss design on various blogs and on GamerDNA. The other half could have been productive had they been brought on board when there was a design doc and a keel.

      In the case of a modded world on a popular platform, such as an NWN PW, the keel can be relatively easy to build. There are off the shelf subsystems for most of what you need to build a PW; including things such as dynamic mob spawns (NESS), drops, etc. An off the shelf MUD codebase or Realm Crafter would be similar. Yet you still need it. Etilica would have been a LOT easier to work with had these subsystems not gone in haphazardly after hundreds of areas had been built.

      And you need that design doc as well; also for the reasons you mentioned.

      >I’ve never worked on an mmorpg before but I can imagine the same principals can be applied

      I’ve never worked on an mmorpg before either. 😉 I don’t much care for the acronym MMORPG because of the massive part and I usually avoid virtual world because these days that seems to mean Second Life. I prefer persistent world (PW) because it makes no declarations of size and all of the successful hobbyist worlds are tiny (both in scale and playerbase terms) in comparison to any commercial worlds.

  2. Edward says:

    The problem with the term “persistent world” is that many virtual worlds are not persistent. If a world has a small number of players who are in the same physical location, it may be online only during scheduled games — particularly if there’s no central server. Educational worlds may be online only during training sessions. Virtual worlds created for research may be online only when a simulation is being run.

    Currently, most hardcore roleplay worlds are persistent. I suspect this will change as it becomes easier to customize a virtual world, though.

    • Dave says:

      Strictly speaking, you are correct. The only problem is that the term “virtual world” has become synonymous with There, Kaneva, Second Life and their ilk; the social worlds. MMO is an ill fitting term because the massive part in it makes everyone think WoW, WAR, EQ ½, etc. MUD is associated with text.

      PW – or PoW (persistent online world) as some of the people on the MUD Dev2 mailing list prefer – does not carry any of these associations. At worst, a small subset of people may associate it with modding the NWN series, but they are few and far between.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s