Any suggestions? I take it I should focus on the project philosophy, but should I be brief on the reasons for the split or expound upon them? Should I go into specifics of what belongs or what doesn't, or should I leave the real nitty-gritty and specific game mechanics out for a later revision once the fork is up and running?
Basic guidelines to help answer the basic questions of "Should this be in the game" and "What level of realism are we shooting for?" are good.
And I am definitely in favor of a basic guiding principle of "Realism is great as long as it does not impose too much tedium on the player". Want it to take 8 hours for my character to craft up some easy but time consuming? Sure, as long as it doesn't take more then me as a player going "Hey, character, make this thing".
Yeah, I think that the most important use for a design document is creating a set of guiding principles for which features should be in the game. If someone has a question about a change, the design doc should be able to guide them to a clear "yes" or "no".
I would say that, as a simple guideline, game features should be (in descending level of importance):
- Fun
- Realistic
- Lore-friendly
Most important is
fun. The game should have an emphasis on engagement, player agency, and reduction of tedium, and thought should be put into early/mid/late game pacing. Next is
realism; Cataclysm is just as much a post-apocalyptic survival game as it is about zombies. Complexity is good, bloat and tedium are not. Finally, a gameplay feature should be
lore-friendly, to keep a consistent tone, so long as it doesn't violate the first two guidelines.