Unity Mission Design document graph to assess

HI i am writting a game design document and one part of it mission design. I have put some graphs but together but i dont know if they are going to be easy to understand for potential programmers.(for now there is lack of Explenation how "Global game Clock invokes missions).

I plan to have around 12-15 missions. could sombody from programmers tell if these graphs are clear enought to start work with? or maybe they way too unclear .. I'll be programing this as well but i would like to outsource some programming stuff and i wonder if this kind of graphs could be readable to a leavel that people could start work with it

graph in pdf file

 

I think it's readable enough, but probably working harder than necessary. An outline could represent the same information in more compact form.

 

I agree with @JoeStrout. It might sound counterintuitive, but avoid flowcharts. They define implementation. At this point you want to define requirements.

Also define them as succintly as possible. Storyboards and bullet lists make a good combination. They're both compact. A storyboard is like a supercharged flowchart, since you can include so much information in a picture.

Only specify the "must haves." Trust your programmers to make the right implementation choices for the rest. Empowered programmers are more productive. For example, say you have a storyboard sketch of an options menu. You don't have to specify exactly how every little thing works on the menu. But if you know that it absolutely must have a volume mute checkbox, point that out in a bullet. Let your programmers implement the rest as they see fit. Also try to avoid adding new "must haves" midway through the project. These inevitably happen, but accept that they "cost" twice as much (in terms of time, effort, etc.) as specifying them at the beginning. I'm not talking about waterfall versus agile; you can build malleability into the "must haves" to support iterative design.

 

As far as using this for implementation, this seems useless. What programmers want/need is an understanding of the systems. What you have is a weird outline from a player's perspective that doesn't really explain what systems they are interacting with. The best I can tell is this is supposed to be a visual novel with every option displayed right in front of the player.

 

initially i started with huge 1500 pecies mindmap with all possible systems. Unfortuatly mindmaps do not show progression of the game. So I came up with idea to write down all the missions I can think of first and then make list of all core needed intergated systems . When the list of needed systems would be complted.Then i would create descriptions or chars how these systems interact witch each other. The game is going to be 3D RPG type with story telling and progression of homless persson seeing demons so i thought that it will be easier to figure out all needed, animations,sounds,stories,and systems by defining missions and progression of game.Supercharged sotryboard is a great idea but it would be like the highest level of game design.And currently I am trying to make production schedule for 16 months. The thing I am a bit afraid of is writting evrything in such details that there wont be any place left for changes at production stage(what can be a huge issue if you decide that something is not needed and something is lacking).The game will be founded by a publisher and i have to set milestones. So the good aproche for writting it down is esential

 

This describes the flow of the game. But it doesn't do a good job of describing the systems that need implementing. A lot of the details you describe would just be things set up in the inspector or via an XML, it makes little sense to hardcode each mission.

So yes its a start, but you want to focus in a little more tightly on systems. What does the hunger system do? What does the mission system do? What does the global clock do?

 

yeah you are right today I have already created full flow of the game and now I am describing deeper how each system is going to work this gameFlow.pdf is like a scafold to build upon.For sure it could have been done better.thank you all for your time and intrest

 

Even if you use a flow chart to define mechanics (I've used them before) don't show mission specifics, show generics and the systems.

But to begin, define the game in words that can be broken down into tangible tasks.