Planning a Game Document & other issues

Hello Unity Forums.

Lately I have come across the problem of making 'Pre-Phase' documents for my video game, by this I mean I can't confidently create a proper documentation of how I want my game to be like. I usually end up with awkward descriptions that demotivate me as I look through them, as a one man team this usually makes me feel depressed when typing out scripts or character information. Maybe it was my lack of a good English teacher or my distraught communication skills in high school but I usually feel like my descriptions lack the 'flavor flave' that most writers seem to have built flawlessly.
Example (This is mine):
"Roldan Arguelles ‘Angel of Death’: Roldan believes in one thing, any hand aiming to harm an innocent face must be willing to face an early passage to the hell they desire, he stands for the people being oppressed by the militant groups and veers for their safety in his one man army against the Devil (so he claims). His gear sports of many stolen/hacked JGB equipment, has skills in advanced combat training, a heart with no mercy and a mask hiding a ‘scarred’ secret."

Another issue I have is story-telling confidence, I usually jut notes on ideas I come up with on different occasions, like 'would be cool if I had this guy jump of a train at one point' but I always feel as if it might not deliver the impact I wish to induce. And I know this is okay, most unoriginal game concepts come from a 'try or die' risk that usually involve the team rolling dices to determine if the implement is a good idea. But I can't come up with an idea, look myself in the eye and confidently say 'Sounds good to me' because I don't believe I can evaluate myself. Most people advise on going online and testing audiences but I don't think the same lies for stories and scripts, it'll be weird if everyday I keep asking 'Hey this guy dies is that okay?, I'm going to kill him off is everyone okay with that?' The story needs to be something the User experiences as an art form with criticism coming with a 'served plate' how can I ensure my meal is tasty before I even serve it? How can I choose the right ingredients for my audience without any experience about knowing what they want?
TLR- Starting Game Developer, one man team.
Thank you for your future answers.
Note: I apologize if this is in the wrong section and if you don't understand, I'll be happy to explain further.

 

I just recently start using Trello to get my game idea better documented. I have lists of stuff and in each list I have a card describing what I want implemented in the game..

 

Write it all down now. Don't worry about spelling, grammar or if it sounds fabulous.

After it is all down, then go back and rewrite, then rewrite again, have someone read it all, then rewrite. I led a team of writers years ago for an indie game and they produced amazing narratives and lore...but it didn't happen all at once. You need to get the ideas down first and then go back and make it look good.

Try it! I go back sometimes now and read thinks I wrote back then and say to myself...I wrote that? It is good! LOL Of course the final product took a lot of work and didn't just materialize out of my head at once.

Good luck!

 

It's actually bad to plan out every aspect of the game before you have something to test those aspects. For most, many ideas seem good in the head but bad in application. Jump into dev, make a prototype, and write your document based on your findings in the proto.

If you're trying to communicate your idea to others, also show them the proto because games often sound stupid on paper but are awesome when played.

 

Massive GDD docs are not for everybody. Remember their point is to help you make a game. If they don't help then don't use them.

Designing through iterating on prototypes is also a valid approach.

 

Are you writing a novel or short story for public consumption? If not, then it doesn't matter how exciting of a read it is. Your design notes\document are for you to know what you're trying to do. That's about it.

You can sit and write notes all day, editing them to perfection, but ultimately you need to plop your ass in a chair and start making the game. It's only then that you'll truly know if your ideas are working, and you can refine them from there.

 

Writing it down isn't about setting it in stone. It's about getting the ideas out of your head, for various reasons such as:
- Not having to remember them.
- Putting competing ideas down next to each other.
- Mixing and matching parts of an idea.
- Initial planning and revisions of said plan.
- Showing and/or communicating them to others.

I agree that you should prototype to help make decisions, but a part of that process if often writing down all the ideas your team thinks might be worth trying. So, don't just write one plan down and call it done, write down the variations it could have as well, and don't get overly attached to any one of them.

On that note, for the OP, don't worry about making all of the decisions when you're writing ideas down. It's perfectly ok to say "Need to solve X before this idea will work" or "This part needs more" or "Don't like this bit, but needed something" or even "this bit obviously sucks, fix later". As jpthek9 points out, the document isn't the product, the game is. The document is just a tool you use along the way - so use it however it gives you the most benefit.

 

I would add to other peoples post something that you must keep in mind:

Know your potential, especially you start a one man team. Are you able to do all gfx? Are you able to do all coding? Music + sfx? Probable you buy them.. so basically, be honest with you, absolute honest on what you CAN do, not what you want to do. Dreams are nice, OK, but you must be realistic, and try avoid future mistakes and disappointments. I am telling you that from my experience. Take it or leave it.

 

As a one man team you don't need to have a massive document. Just write enough to get the clear idea out of your head so there is space to think about other things. Try bullet points, or post it notes (or trello for the electronic version). If you want to combine all those & also have some flow between them try mind maps. I find them really useful for clearing my head & organising the ideas, with the flow arrows helping to highlight gaps in logic.

 

This!

You want something tangible soon, a vast majority of your 'good' changes will come from playtesting. Having a solid GDD is nice but its totally useless if you don't have any output. Get some simple core ideas on paper so you have a static foundation, start building the prototype, play around with it, retroactively update the GDD.

 

Thank you for your replies and advice:

I started taking lessons on different Game Making Elements to help me on my path: Environmental Design, Programming, Sound Design, Concept Art. Is this wise? Is it too much?

I totally agree with this, I usually create a separate document where I post in random things that come up during leisure times.

I usually feel like my documents need to be exciting when I go through them so I can obtain the same sort of motivation I do whenever I come up with a new game idea, when I write something in a basic form it makes the idea seem boring,

 

Maybe yes, maybe not, you don't really know until you start practice And here comes the experience, good luck

 

A friend and I are using Quip for this. It's document tools are really basic and kind of uninspiring and limiting, but the thing where the document goes hand in hand with a chat history and complete change log is sweet. Our design doc is literally a live and ongoing talk about the game. It's rad.

 

There are a lot of online services offering collaborative tools.

BUT, you don't release a game only with design document, you need a lot more. From design document to release there is a long way

Unfortunately, a lot of games remain at design document.. I've seen a lot of small teams stuck at basic development, and unable to go forward, with impressive design documents.

 

Technically you don't release the GDD at all.

There are arguments to be made for having good systems and background structures in place.

But there are also arguments to be made about only building and developing things the customer is willing to pay for.