Hey everybody. I'm currently starting a project with a small team, and, as head designer, I've been making some documents describing the overview of the game and prototypes to be made. As I am an early game designer, I figured it would be a good idea to ask for constructive criticism on how I am going about things. I want to refine the initial prototype as much as possible before I move forward. Anyway, I have two PDFs, one on the overview of the project, and another serving as the rough draft for the first prototype. I would appreciate it if you guys would give them a look and provide some feedback. Thanks!

https://triplecometstudios.wordpress.com/2016/10/10/full-metal-spitzer-design-documents/

Okay, first just take my advice with a grain of salt. I'm not an expert, but I've designed a couple of games by myself. This is what I've learned on building the documents.

First thing I would say is to not split your design documents up so extensively for the prototypes. The first problem with doing so is that it will unnecessarily complicate things. The second problem is that you're restricting your team members access to the various bits of information.

I don't really understand what you're trying to do with the prototypes however. I get that you want to play-test whether something works or not, but you don't need a separate prototype each time you do that. Again, many prototypes would just unnecessarily complicate things. If you want to play-test many of your features external from the game you're building, just make a single prototype that does that function.

Next bit of advice I would give is to split up your documents (I know, ironic). For my own projects, I create the following documents:

Business Plan - marketing, the future of the game/team (say are you going to build a company around this etc.) - if you're ever looking to sell your game for money, do a business plan

Project management - managing the project, including QA and things like that - anything about the project that isn't directly related to the game itself, or the business plan

Game Design Document - The game itself. Target audience, scope, what do you want to achieve, what is in it - gameplay, story, GUI etc. etc. etc.

Technical Design Document - The technical details of the game. For example, this two-handed sword deals 5 damage. The player has a base of 3 health and 1 damage. At this specific moment, the player will say this text etc. etc. just every technical aspect of the game. Balancing is included in this.

Level/Art/Sound Design Documents - this is fairly simple. Details the level, the art and the sound design. Each will want to take from the atmosphere explained in the game design document. The art document should have concept art and than the real art.

I believe most people put the game design and technical design documents together as one, but I like to separate it - makes it easier to get to what you need. I also sometimes separate the GUI from the game design document if it is a heavy design aspect (say for an RPG).

The only reason I create the separate documents is that it becomes much easier to access the information you need without having to trawl through extra unnecessary things. I find it helps a lot when you're working on the game (but that's just me). I haven't built enough games to know if this assumption is correct.

Right now, though, your biggest problem is that you just don't have anywhere near enough information about the game. Make your prototype first. Is it fun? If the answer is yes, then go to your design documents and build your game extensively. It'll save you a lot of headaches in the future.

Thanks for the feedback. I think I may have communicated my intentions badly in my initial documents. While I am making separate documents for each prototype, they are also going to be included in a monolithic "Design Document". The design document's purpose is to provide reference to why we made every major decision in the project. I do intend to make this more readable, however. Someone on another site gave the suggestion to include a table of contents that links to parts of the larger document.

On the topic of prototypes, I realize now what I said is misleading. The book I study under is "Art of Game Design" by Jesse Schell, and he recommends an iterative approach to game design. Find what could prevent your game from becoming a success, and then devise a way to answer that question, using the results to improve your game. Prototype DOES imply a separate build of the game, but in most cases, this is not my intention. A prototype in many cases will be a simple experiment with playtesters. "Is this challenge too hard?" This would be solved by designing an experiment, or as I would label it, a prototype, that answers this question. Unless the question calls for it, this will be done with the current build of the game.

I'm essentially including all my prototypes in one big document initially for the purpose of keeping track of what I need to do. While there will never be enough time to complete every prototype (extensive playtesting is expensive, so many less important questions will come down to intuition) I would like to know where the holes in my design lie. The document I included will include information from all the documents you mentioned, but I fully intend to separate the information into individual documents. Obviously the art team should not have to sift through my ramblings on programming or level design.

That said, I do think you have a great way of breaking up your information. Initially, I was going to split information up into documents pertaining tasks for the individual teams, but I think your method is important as well. A simple table of contents alone won't be extremely effective when I'm trying to extract all my information on market research, the business plan, etc. I'll sleep on it and thing about some kind of middle ground, or maybe just maintain both.

Again, thank you for the feedback. Other than the structure of the document itself, did you find any issues with my design logic or any of the individual design decisions I made? Despite my extensive studies on the subject, I am still fairly new to game design. Any kind of feedback will be helpful.

Also, I forgot to mention, and I apologize if this is more of a technical question than a design one, but I have reservations on making the crushers close in 535 milliseconds. I have programmed my game engine so that it is frame independent, but I am still unfamiliar with any strategies behind programming a frame independent game. To be frank, I am not sure that even with frame independence that having something happen every 535 milliseconds is possible. If anybody can explain why this is possible or not now, I would greatly appreciate it. It would cause a lot of frustration to develop this prototype only to figure out this is not possible.

Also, I forgot to mention, and I apologize if this is more of a technical question than a design one, but I have reservations on making the crushers close in 535 milliseconds. I have programmed my game engine so that it is frame independent, but I am still unfamiliar with any strategies behind programming a frame independent game. To be frank, I am not sure that even with frame independence that having something happen every 535 milliseconds is possible. If anybody can explain why this is possible or not now, I would greatly appreciate it. It would cause a lot of frustration to develop this prototype only to figure out this is not possible.

It seems like you have a pretty straightforward and cool basic game concept (a one-level bullet hell shmup with a side goal of performing for an audience?) but it's a bit buried in there. The first thing a reader of these documents (that is, one of your devs) needs to know is the basics of what game you're making. (There's a lot of text introducing game design concepts, and asserting or justifying obvious things like a unity of elements, iterative design, the importance of fun, etc. Of course you want those! Appearing to argue *for* them paradoxically makes it seem like these are heretical ideas in need of justification rather than necessary parts of game design.)

I'd be a bit more assertive in committing to particular ideas. Say at the very beginning "These decisions give us a starting point for something, but at this stage nothing's irreversible and don't hesitate to push back!", and maybe don't bring it up again.

I'd also think of some further essential experiences. While not every game has both of your stated experiences, the ones that don't are somewhat outliers. The essential experiences should give all your designers a place to start. They could be core emotions and cognitive things like "Paranoia" or "Divided attention" or something pretty specific like "Alone where no one speaks your language", "A moment of freedom from all responsibilities", "No dirty trick is too dirty if I win", "A small child really wanting to play a game, but it's too advanced"... then they could go off and do their jobs, hunting/inventing/proposing art/music/animation/etc. styles that reinforce those ideas. That's the good midpoint between telling them what styles to use (that's their expertise) and not specifying anything at all.

Otherwise, I echo what ShiftyCake says, especially that you're missing things like intended budget, platform, distribution, pricing, etc. If you think it could be divisive, that's extra reason not to avoid talking about it. You don't want to bring a new dev on and they were under the impression you were making a paid game and it's free, a PC game and it's for mobile, or a kid's game and its for adults, etc.

Also, I forgot to mention, and I apologize if this is more of a technical question than a design one, but I have reservations on making the crushers close in 535 milliseconds. I have programmed my game engine so that it is frame independent, but I am still unfamiliar with any strategies behind programming a frame independent game. To be frank, I am not sure that even with frame independence that having something happen every 535 milliseconds is possible. If anybody can explain why this is possible or not now, I would greatly appreciate it. It would cause a lot of frustration to develop this prototype only to figure out this is not possible.

You can't make anything happen exactly on the millisecond, because frames are only displaying every ~17 milliseconds. But you can test in your update loop whether enough time has passed, and if so, do a thing. That'll average out to a little more than 535 milliseconds, but don't sweat the difference.