Some of you may have heard the term “Design Document” before. You’ve almost certainly heard of a “Roadmap.” But what are these things, exactly?
See, it’s been a symptom of modern game development, with its emphasis on “community engagement” and marketing hype, to either skip, minimize or blur both of these essential yet criminally under-loved bits of documentation. While it’s easy to understand why that happened, it doesn’t justify the results, and certainly won’t save your project if you choose to behave like a AAA producer or personality-cult development house.
Strictly speaking, the Design Document is the DNA of the game. In its earliest form, it is the first, complete outline of the Vision in text format, covering the basics, the aesthetics and the end-goals. But it’s meant to be more than that. This document is supposed to be all-encompassing; it isn’t just a short story, but an entire Bible, digging down to the deepest practicable nuance of the game’s development. We’re talking technical details and bothersome logistics, the stuff that makes most folks’ eyes roll. How much time (and money) is budgeted to texturing this specific planet? Who’s going to do it? What software is used? What format is the finished product? What steps are taken to bring this into the workflow? Who’s informed at each step? It gets better: How is progress measured? What does “complete” even mean? In the event of unforeseen technical or even organizational setbacks, how will this texture be finished? Or discarded? Or remade? Or avoided? The answer to every single one of those questions is supposed to be in this document.
Ideally this "Bible" is complete before proper development even starts, but in the real world this is never the case because the rudimentary document is part of the initial pitch to a publisher. In the modding scene, you could imagine a similar purpose in order to drum up interest and attract a development team.
There’s just that hairy issue of “confidentiality.” After all, you don’t want to spoil everything, do you? How will people be interested if they’ve already read ahead and know all the details? Where’s the fun in that?
Sure, so why bother writing all this stuff that “nobody” will ever read? Don’t worry, I’m sure we all get the idea anyway; we’ll wing it!
Repeat after me:
No
Half
Measures.
Not only is this terribly bad form and potentially demoralizing for your development team (it sure will be down the line when they remember there isn’t any core plan to fall back on, that’s for sure), but it’s also something that a mod project cannot benefit from. Big, professional development teams are “padded” from the effects of an incomplete or overly-ambitious plan by a combination of recycled assets, long-running series which recycle whole gameplay and development loops, a wealth of in-house experience that can “cut corners” with some degree of certainty and finally, of course, the ever-present pressure of the bottom line and a finished product. How many mod projects can boast even one of those saving graces?
You gotta Plan Ahead. Unless your vision is delightfully small, unless you’re a totally self-sufficient one-man-band with everything written shorthand or firmly in memory, then expect problems if you don’t. Big ones. Project-breaking ones. Drama-inducing ones. It should stand to reason that the longer a project takes, the worse the effect becomes. Imagine having to re-build consensus over and over again, not only with your own developers but also with the community at large. How much time and effort is wasted just in trying to keep that communication (and team morale) going, when it could have been put down in black and white from the get-go? How many in-fights do you avoid? How much bad press?
Even as far as “spoilers” go, it’s rare for mod projects to be so narratively complex that they warrant that kind of secrecy. And even if they did, specific plot points can be buried in the data. If my hypothetical Freelancer project included a new system named “YZ Ceti,” which had 2 stations and a locked jumpgate, would you immediately know what it was for? If I said the plot involved the Coalition from Earth, and you connected the dots by figuring out that YZ Ceti is a real star fairly close to Sol, would you know how it works the story? All I’m saying is that you can shield a surprising amount of narrative, without having to lie or fall back on a non-disclosure policy. And that’s before you consider whether secrecy is needed at all for a mod project. You're not trying to write a best-seller here, nor to film a blockbuster. You're here to make a game that people are willing to wait to play, and one that people are willing to build for free. Remember that.
Ambiguity in the planning phase is a symptom of gambling addiction if you asked me. You’re gambling on the cohesion of your team and your vision, and you’re asking all of your supporting fans to gamble on your competence and integrity to get the job done. You should already know my answer by now: Integrity First. Let’s not even give people the opportunity to doubt our intentions before they can play our product.
So with all that being said, how do we design this thing? The specifics of my hypothetical Freelancer game would be too complicated to write up here in the format a design doc would require. But if you wanted a tentative table of contents, it’d look something like this:
1 – Mission Statement
- Guiding Principles
- Game Vision
- Metrics for Success
- Expected Timetable
2 – Design Overview
- Genre and Target Audience
- Game Flow Summary
- Look, Feel and Sound
3 – Mechanics
- Menus and Interface
- Ship Physics
- Ship Types and Characteristics (see Appendix A)
- Weapons and Equipment (see Appendix B)
- Planetside Mechanics
- Other Multiplayer Mechanics (FL Hook, off-site web pages, wikis, forums, etc.)
4 – Story/Characters
- Setting
- Groups/Factions
- Character Bios
- Main plotline
- Multiplayer tie-in (the majority of the section for an MMO style FL)
5 – Level Design
- Setting Recap
- Key Locations (hubs of player activity/mechanics/decision-making)
- Types of Locations/Areas/Bases
- Galaxy-level Design
- System-level Designs (see Appendix C)
6 – Art/Sound Design
- Interface
- Alternate Views (primarily with reference to in-cockpit view)
- Character Aesthetics (see Appendix D)
- Ship/Vehicle Aesthetics (see Appendix A)
- Equipment/Weapons/Effects Aesthetics (see Appendix B)
- Environment Aesthetics (see Appendix C)
- Sound/Music Aesthetics (see Appendix E)
7 – Multiplayer Components
- Community Organization and Moderation
- Player’s Online Rights and Responsibilities
- Player Conflict Resolution and Redress
- Player-run Faction Rules
- Player Canonization Rules
9 – Marketing and PR
- Disclosure Policies (Not to hide things, but to make sure only public faces are involved)
- Art/Sound/Video Assets Expected
- Scheduled Releases for Promotional Content
- Third-party Integration (supporting websites, communities, i.e. ModDb)
10 – Team Accountability
- Team Composition
- Division of Responsibilities
- Communication Methods and Policy
- Big-Picture Workflow
- Big-Picture Timetable
- Quality Assurance Policy and Procedure
- Conflict Resolution and Redress
11 – Department Breakdown (One each for all departments, i.e. Story, Art, etc.)
- Department Composition
- Department-specific Tools/Software/Formats
- Department-specific Workflows
- Department-specific Assignments and Timetables
12 – Appendices (All master lists with accompanying info relevant to stats/design/etc.)
- A: Master Ship List
- B: Master Weapons/Equipment List
- C: Master System List
- D: Master Characters List
- E: Master Sounds List
As you can probably tell from the very first section, I’m re-emphasizing core principles and fundamental guidance. That is what this plan is for, after all. The “Mission Statement” isn’t just a few lines, either, but a big-picture bolstered by some description. In essence, this first chapter is your pitch. Short, sweet and to the point.
Sections 2 through 8 are where most design docs you’ve seen probably begin and end. It’s a much deeper dive than the pitch alone, but it’s still vague enough that it’d require many, many appendix items to fill in the blanks. It's the bones of the game, covering all the basics from start to finish. If these parts aren't set in stone by the time work begins, you may want to consider a different profession.
Sections 9 through 11 are something you probably won’t see on a regular design document, but the contents must exist somewhere. Proper companies likely defer to long-standing policies and procedures that pre-date the game itself anyway, and the marketing team is heavily influenced, if not completely run by, the producers. Nitty-gritty timetables for specific departments and assets aren’t usually published, and since some games lend themselves to copying existing workflows (series with minor changes) they might not even feel the need to write down new ones.
But we’re not talking a professional studio here. Your mod project is your entire company, team and PR effort all wrapped up in one. Cut the middleman and do yourself the favor of building these into your design document from the start. You might not feel the need to publish these parts, but it might go a long way towards gaining community respect if you did. Either way, it’ll be a tremendous asset to the development team, ensuring cohesion and continuity even in the face of turnover and roadblocks. It also creates accountability for a volunteer team that can neither be denied salary nor prosecuted for fraud. Granted, a highly-motivated team shouldn’t even need this incentive, but it’s the chief executive’s trump card, and it can also keep the community happy simply by existing.
The Appendices, though... This takes dedication. A project that outlines master asset lists in detail means serious business and is, quite frankly, professional. They remove so much ambiguity and can so hinder feature-creep that the design can almost execute itself. Granted, this is also where the most mistakes will probably be made due to unintended consequences or through simply overlooking something required. But so long as you look at every addition to this list to be a “failure,” the master appendices should serve well to keep the entire team accountable, particularly the dreaded “idea guy.” See? Even the “idea guy” can be checked without a producer. Whoever said money made the world go 'round, anyway?
That’s a lot of talk about the design doc, but how about that “Roadmap?” Well, I hate to break it to you, but “Roadmap” is just fancy marketing lingo for “a projected timetable, dumbed down for consumption.” Historically speaking there was no such thing; nobody asked for or needed one. It’s only been in recent years, when savvy consumers (and investors) ask to see the design document and are either stonewalled or left disappointed at its shallowness, that roadmaps were produced. Assuming you’ve put together a fully fleshed-out design document that includes timetables, a “roadmap” is superfluous except as a marketing exercise, and you could just as easily strike that from the department’s list of tasks since they’d have better things to do. Welcome to management, huh?
Writing all this out can take time. It isn’t pleasant. Some sections, particularly Programming, will require you to either be well versed in it yourself, or to have enough team specialists already onboard to translate appropriately. As such, most designers can only write up the first several with any confidence, but that’s fine; If the Vision can’t be communicated, you won’t have a project or a team to manage anyway.
I suspect that one driven individual could put out the Mission Statement in a week or so, supposing they had thought plenty about it already. If a team was gathered over the next 3 to 6 months, it would then take another month of serious planning to finish the remaining sections, putting you at anywhere from 4 to 7 months before the project starts taking shape. That sounds like a dreadfully long time and counterproductive, but I’ll bet you five bucks it’s because you’re not accustomed to mod teams producing design documents in the first place. Brush up some marketing materials and publish the design doc when it’s done, and you will be able to say with confidence that development has, in fact, already been started. And having done this, you’re also far more likely to actually finish what you started, which is a lot more than a lot of other teams can say. After all, “A pint of sweat saves a gallon of blood.”
This should cover all the basics of getting a project off the ground. Managing it deserves a whole section on its own, but I don’t see the need for it, given that no two projects are the same, just as no two teams, and no two people, are. Proper leadership is more art than science, and everything I described in this section has the “science” part down pat. From now on, we get to talk about art. It won’t be nearly as useful or as universally applicable, but I’ll do my best to connect my mod-specific designs to the guiding principles and the overall structure of the project.
It’ll also draw the most flak from around here. Hold onto your butts.
![[Image: E0HASy7.png]](https://i.imgur.com/E0HASy7.png)