I have nothing but contempt for Design Bible evangelists. It would be one thing if its proponents were off in their corner of the universe — awash in their own sea of ignorance; alas that is not the case, and people still push the idea that bigger is better, longer is stronger, and information density is somehow information clarity.
People who proselytize design bibles as a means to disseminate information have never, ever, been on the receiving end, because attempting to assimilate that data is like drinking water from a fire hose. Never forget: how you present information is no more important than the message itself. If no one wants to read it, then the message is wasted, and I wish this had been beaten into me when I first started.
I once heard this referred to as “Old School Design”, which is a labal that I despise. To label one “Old School” and the other “New School” is a soft-handed way of not taking a stand, of being afraid to have an opinion. These labels justify both methods by saying each have their own merits and, “gee can’t we all just get along?”
Fuck no.
If all you do is write monolithic tombs, bursting at the seems with cross disciplinary information, stuffed with layer upon layer of facts, figures and stats, then you are as monstrously wrong as your document is big, and I’m going to show you why.
The Importance of Finding Information
Being a designer is a lot like being the town historian. You can expect daily quizzes on the reason for a feature’s existence. As a rule, people do not enjoy doing unnecessary work; coupled with the difficulty of seeing the “big picture” of one’s task, and you can expect that almost every person, from every department, will stop by and demand to know the reason they have to do something.
Designers are not, at least I’m not, gifted with photographic memory, so I may not immediately remember why I made some decision four months ago to use RED lasers instead of BLUE 
lasers on our space robots. Boom: enter my documentation. I open up a small file, with detailed notes, and then either explain the reasoning for some feature or discover a new problem that needs solving. If I have to go mining through a 30 page document to find this information, which I may or may not even find, I am going to not only piss off the person asking for verification, but also weaken the respect and team dynamic. They expect the designers to be keepers of this information, so failing in your job makes it seem as if we have no idea what we are doing. You don’t want that, do you?
This problem is compounded when the designer being grilled is not the same designer that requested the feature. This happens more often than you think. No one outside of the design team cares who worked on what part of the design. We are just The Design Department. We, as a group, must all understand how all parts fit together. If I have to go digging through a 30 page document to look for something that I didn’t even design you can bet your ass I’m going to be grumpy.
The Importance of Maintenance
What if the answers are not there? Then we have a new problem, and this requires us to update and maintain the design. Let’s return to the situation of someone asking what color the lasers should be on those space robots. Maybe I didn’t specify what color the lasers should be, and while at first this appears to be a problem of pointless minutia, you could not be more wrong. You do not want the Space Robots shooting weapons that look the same as the Allied Rangers, because then you would have no idea who was shooting at who. We must update the design to be more clear.
Now let’s assume you have two methods of finding and updating this information: you can search a giant file for the page that contains the info you need, or you can open a small file nestled inside a clearly defined folder structure. Not convinced on which is superior to the other?
Ignore, for a moment, that on a purely psychological level one is clearly more daunting than the other, and notice the secondary benefits of this method. How many factions are there? What are their names? Clean organization has great benefits, but it can, like all things, be abused. Too many folders makes it hard, if not harder, to find and update the information you are looking for, so be careful.
The Importance of Organization
If you express every concept in a word document you will limit yourself, both in how you convey and how you organize. I talk about this a lot when it comes to documentation and game design, but you must always take into account your intended audience when writing. Some people are visual learners, some are hands-on learners, and some are written learners. Don’t make everything a word doc.
Let’s say you are designing weapons for our fictional Space Robots game. You can document their look, their feel, and their function in a myriad of different ways:
- Style 1: A chapter inside the design bible labeled “Weapons”, which explains, in general detail, most of want to know about them.
- Style 2: A single word doc named “Weapons” that exhaustively explains everything you’d ever want to know about them.
- Style 3: A folder called “Weapons”, which contains a single word doc for each weapon. Each doc contains pictures and an exhaustive description of what you’d want to know about that particular weapon.
- Style 4: A folder called “Weapons”, which contains a folder for each weapon. Inside each weapon folder is a document describing the look weapon, an excel document describing the animations of the weapon, and a glut of images that show its intended look. In the root Weapon folder is an excel file that describes numerous stats about all the weapons.
- Style 5: A folder called “Weapons”, which contains a folder for each Class (pistols, rifles) of weapon. Inside each category is a folder for each weapon of that Class, with a document describing the weapon, an excel document describing all of the animations required, and a glut of images that show its look. In the root Weapon folder is an excel file that describes numerous stats about all the weapons.
I could continue breaking things down into deeper, more complicated folder structures, but I find that stopping at Style 5 is the best. I have already explained the importance of breaking things down into Roles and Classes, so it should come as no surprise that I prefer that method. You will also notice that as things progress the number and type of documents also expands. The benefit to using files like excel to describe things is that it allows the reader to quickly change how they view information by altering how it can be sorted. There is a rule about information called The Five Hat Racks
There are five ways to organize information: category (similarity relatedness), time (chronological sequence), location (geographical or spatial references), alphabet (alphabetical sequence), and continuum (magnitude; highest to lowest, best to worse).
-[Truong, 2004]
This is also known as the LATCH principle, and though I could easily do an entire post about it, the relevant point is that excel, when used correctly, can easily sort information in meaningfully different ways, which is paramount when dealing with a large team of people trying to quickly glean information.
And yes, one can just as easily insert tables into word documents, but separating documents (to give an example) out into form and function allows two people to simultaneously and independently update them. Collaborative design in a large team — especially one using perforce — benefits from clean organization.
The Importance of Collaboration
Though we sometimes like to picture that games are designed with a single vision, that is not how it works. Games are made up of multiple systems, and each of these systems are worked on by different people. Bob may design the weapons, Steve might design the factions, and Jon might design the quests. If you have everything about your game contained in a single file, even with good version control software, trying to merge all that data back together is going to be a fucking nightmare. Not to mention that binary files (excel) cannot be merged at all, so breaking files up is even more important.
Closing
The observant reader will notice that in all my examples of folder organization I left in the “GIANT FILE OF DOOM”. This was on purpose. As much as I hate them, they still serve a purpose, and I would remiss if I didn’t talk about it. Design Bibles are terrible for quickly finding information, for being easy to maintain, for organizing information well, but they are great for conveying the full picture.
Having a single document that encompass the entire game is especially important in the early days of the project. Not only will writing things down helps you to fill holes that you might not take into account, but also any person who reads it will have a strong understanding of the entire game (such as a publisher). Note: this also means that you need to be careful not to put too much information. For any and all other purposes these monolithic design documents are worthless, and once you have successfully broken its data up into smaller, more manageable chucks, assign one person to keeping it updated and avoid it all cost. Do this and you will overcome one of the greatest hurdles that you face when writing documentation for a game: getting people to actually read it.
This all is a bit of a strawman; you’re not actually arguing against Design Bibles, you’re arguing against poor organization, and ‘good’ organization is remarkably subjective. Where is the right, perfect place to separate the damage of a space laser, the drop rate of a space laser, the design of the component rule sets and code blocks invoked by the space laser, the fx used by the space laser, the animation used by the space laser, the rules and systems to craft the space laser, and the rules and systems by which players may buy, sell, or auction the space laser? For any way you could choose to segment out how to organize that information, for whatever type of categorization you could choose, there are a dozen others that are equally valid.
Particularly now that we have access to search tools, whether it be across our intranet wiki or just within a single word file, It is perfectly reasonable to have a single giant ‘Design Bible’ that encapsulates and ties together all of those systems and yet is still easily navigated. It is only a few moments work and a minor bit of discipline to have Word automatically construct a Table of Context and an Index for you.
Further, it is perfectly reasonable to have, simultaneously, a single giant document (useful to, for example, get new hires caught up) and many smaller files that are all automatically kept in synch because the single big document is an automatically compiled gestalt of an internal wiki.
Personally, I prefer to work in small files, because it allows me to have multiple documents open at once in different side by side windows, so I can easily do comparisons and make sure features are lining up and supporting each other. However, the ‘right’ organization and breakdown is largely dependent on the specific perspective that each reader brings based on their specific task and need from the documents. That being said, though, that’s how I choose to work, not how I choose to find and reference information. Hunting for specific facts through a dozen discrete documents when the concept I’m looking for is something that doesn’t cleanly fit into any one of them (such as what color is the beam of our space laser), when I could just open the giant bible and hit CTRL+H + “laser color” and have a decent chance of finding it instantly seems like a step back, not a step forward.