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.