If I were creating a design document for a VR app (or creating a book about creating a design document for a VR app, and then creating a VR app), it might look something like this:
Post X: Design Document
In this post we’ll look at the design document for our final project, [redacted for the time being], “Space Blast (working title).” The document is accompanied by inline analysis in bold. The analysis consists of reasoning transplanted from previous posts (and books) as well as fresh insight.
I’m sure you’ve heard it before; a design document is the blueprint you use to build your game. There’s no standard format, but there are standards. Your design document must clearly convey to your future self, collaborators/employees, and potential investors exactly what to expect. No surprises. A good design document should allow for freedom as to how things are accomplished, but there should be no ambiguity about what needs to be accomplished.
Table of Contents
I. Gameplay Synopsis
Ii. VR Considerations
1. Simulator Sickness Mitigation/Elimination
2. Technical Accommodations
III. Design Considerations
IV. Narrative Synopsis
V. Game Mechanics
VII. Concept Art
Don’t confuse this or any particular design document for a template. Broadly it can serve as such, but keep in mind that, as aforementioned, there is no standard format. The Table of Contents will vary from game to game (notice the subtle differences between this and the Table of Contents from No-Code Video Game Development Using Unity and Playmaker’s Project, “Get to The Choppa”). Even on a per game basis, the final design document may bear little resemblance to its former self. It should be amended and updated as development progresses. If I were to show the design document to potential investors it would be complete with screenshots and marketing information. The brevity of this design document reflects the purposefully limited scope of the game as initially envisioned.
To be continued…