Hi.

My Background

I've been playing computer games for a while (yes; I'm, that old :))

Recently, I'd attended a game design conference, looking into game development.

I've been learning UE4 and 3ds Max for about 4 weeks(15hrs per day) learning the basics.

Watched lots of videos and read lots of articles.

I really want to get into game design (Well about time) because over the years. I've had many ideas for games that I would like to design, but didn't know where to start until, about 1 month ago.

I've signed up for a taster course in UE4 @ university.

I would like some advice creating GDD (Game Design Document)

I've read a few documents about how these should be done. But they seem aimed @ advanced game designers.

Here is where I’m up to;

Type of game

• RPG Survival

• Main Characters and NPC (Non Player Character)

• Single Player

• Character advancement

• Story

• End game

Guidelines (Help)

• How to start the project

• Level Design

• Game resources

• Implementing game mechanics

• Setting Deadlines

Any help would be greatly appreciated.

Thanks

I've read a few documents about how these should be done.

There's only one way that design documents should be done: the way is most useful and effective for the team or person consuming those documents (that is, making the game). Everything else is subjective opinion and fluff, and anybody who tries to tell you that "all official GDDs have X, Y and Z" or "look like A, B and C" is probably wasting your time.

The fundamental point of a game design document is a codify the important ideals and goals of a project, generally so that they are clearly communicated to the rest of the team or that they are clearly communicated back to you so you don't have to keep the whole of the vision in your head constantly. An effective game design document can be a handful of quick, scrawled notes or it can be a complicated, ever-evolving wiki of information, or anything in between. The important part is to document what you think is important and what you want to focus on in a way that you are going to be able to find useful in the future.

You may not know exactly what that means to you yet, the best way to learn is to try and see what works and what doesn't on a particular project and then adjust your behavior as the project goes on or when you start a new one.

I would not include things like "deadlines" though. Scheduling is a complex problem and definitely needs to evolve over the life of a project, even if the design remains relatively fixed. It also depends on a lot of technical, nitty-gritty implementation details you may not need to be putting down into the GDD in the first place. But if trying to rough in a schedule helps you, then by all means, do it.

You can use this one as an example/ reference (it's a relatively small game):
http://crealysm.com/downloads/documents/booh-game-design-final.pdf

Also note that opinions on GDD's differ, depending on going for waterfall or scrum/ more agile (or some hybrid form). In any case a GDD should be living document in my opinion.

Cozzie , Thanks for the input.

Your GDD will help me create my own.

Here is where I’m up to;
Type of game
RPG Survival
Main Characters and NPC (Non Player Character)
Single Player
Character advancement
Story
End game
Guidelines (Help)
How to start the project
Level Design
Game resources
Implementing game mechanics
Setting Deadlines

Rogue, several of the things you listed are not part of a GDD.
Guidelines (Help)
How to start the project
Implementing game mechanics
Setting Deadlines

If I correctly interpret those line items, those are part of a TDD (technical design document), not of a GDD. A GDD can be thought of as a statement of the problem (here's what I want to make), and a TDD can be thought of as a statement of the solution (here's how I plan to make it).

GDDs are a facet of Game Design, so I'm moving this to the Game Design forum. If you have technical questions, though, those should remain in For Beginners where I found this thread.
Good luck with your project!

My 3 cents:

1. DON'T try to make an RPG as your first game.These games are among the hardest to design and build.

2. You first serious project should be very small in scope. Something like Tetris, Pacman or a little phone puzzle game. It will still take you months full-time to make it solo.

3. When you write your design document focus on creating good ToC. This will enhance your understanding of how things fit together.

If you decide to make a big 3D game there is a HUGE chance that you will never complete it.