Game Design Document state report 03...

Hello there!

As GDD work continues I've reached page 90 of the document, with huge amount of work still to do.

Since my last update I've made short description for Minigame and Cut scenes elements of the game, but also started to write "real" gameplay as part of Scenes gameplay design.

Minigames...

For JKA2 I've envisioned few small one–screen puzzles. They will be simple in nature and will use RPG maker default mechanics – moving around using controllable minigame specific character or item.

Nothing complicated there, but will add an additional element to the original gameplay introduced in JKA1.

Cut scenes...

Cut scene in JKA2 will be made as scripted sequences run in RPGMV engine.

I've divided cut scene into two types: separate cut scenes and in-game cut scenes. In realty they are almost identical. Main difference is that separate cut scenes can be stand alone as a special scene (example - hydroplane flying over a sea), while in-game cut scene can be started via some in-game interaction (Jessie interacts with a lever which activates a cut scene where doors open and NPC approaches Jessie).

Although this was not necessary, dividing cut-scenes into two types will make production somewhat clearer.

Scenes gameplay design...

I call it "Scene gameplay design" because main gameplay part of this type of games is scene navigation and interaction with elements on the scenes. For open world type of games this segment of GDD would be called differently but main logic stays the same - designer should define all elements needed for entire game to work as desired. None of the gameplay elements placed in the game world should be left undefined.

If there are elements left for level designer to add on their free will or if there are elements which depend on art design - boundaries should be defined and be in mind while writing this segment of the GDD.

For example there is no need to define animated elements on the scene (like smoke particles) and adding those can be delegated to an artist, keeping in mind art style guide and location description. On the other hand if those elements affect the gameplay (like fire hazards) they should be thought of and defined in this part of GDD. Also if level designer adds enemies, loot boxes, obstacles etc. without a clear guide this can affect gameplay drastically.

Scenes gameplay design Legend table

First part I did here was to describe each game scene in a few sentences; paying attention to gameplay relevant areas and global setting I've defined earlier.

I've created gameplay flow on paper before, so here I "just" need to describe it and present it in a production viable sense, with all elements precisely defined.

Then I started to make scene sketches. Since game view is default to RPGMV, I can draw scene sketch fairly accurately. This part of design is the first test of how sound per-scene gameplay and gameplay in general really is. Here designer can adjust any small or big problems regarding scene interactive areas or even quests. It's much cheaper to rearrange gameplay elements here and not while art or other parts of the game entered production. Unfortunately this step is often overlooked which leads to a lot of shuffling in production, broken gameplay or even domino effect of various inconsistencies in the game. 

Some scene sketches

As I'm doing scene sketches I'm simultaneously explaining scene action areas and all gameplay elements affecting or affected by a scene.

I use bulleted list type of track for this since I find it visually most easily to read. Depending on the complexity of the scene and gameplay this can seem like a never-ending task.

First time I was doing this type on in-depth game design document I felt overwhelmed. It seemed as if there are just too many elements to define. In reality those elements should and will be defined sooner or later. But in most cases they are added later as game is being produced and this can turn into a complete mess. So I suggest - do it on time, do it here, be concentrated and relaxed... you will save yourself and your team a lot of time, money and frustration.

Scene description with sketch and interactive objects positions defined

While making this part of the GDD you are also testing entire gameplay before actually implementing it. I believe this is the best time to find bugs, resolve logical issues, improve on quests or change some art elements.

Sketches made here can even be used as mock-up art while implementing the gameplay. So this is another reason why is a good idea to take some effort into defining scenes and all its elements now, instead of just going mindlessly through it.

As you can see by defining scene gameplay elements I often use references for comments, dialogues, items... There are few reasons for this:

• First there is localization – you should keep all texts separately and not scattered throughout the GDD.  This will make localization a lot easier. Even if you don't have multiple languages keeping text as separate segment is always a good idea.
• The second reason is the simple fact that this part of the GDD would become very difficult to read with all those extra things scattered around.
• And third reason is the ease of production. By keeping all elements of the same type separated, production of those will be incredibly easier and quicker. For example there is a list of items with their text labels and icons, then there is table of comments and dialogues, also there are other gameplay elements like minigames, cut scenes and fighting scenes.

While writing this part of the GDD I'm keeping track of all those references in a separate file, so for example there won't be two comments with the same reference label.  Comments are Jessie's reactions when observing something on a scene or they can be triggered by some event. Just in the first scene there are 22 comments... for now.

By defining gameplay I also need to define certain conditions, so I'm defining and keeping track of most important variables - for example when in-game action activates dialogue branch with some NPC. This gives you better comprehension of cause and effect without actual in-game implementation. So you can "predict" certain comments or dialogue branches or new in-game events – basically you can improve on your already written game design. Also it will make gameplay implementation a lot easier, quicker and bug-free.

Layout of defined scene gameplay

All elements of the GDD that are still undefined I write in red, so I know what I still need to do. You can see comments and cut scenes are still in red. This is not necessary and you can keep track on those in a separate file, but I like to use this approach.

I also like to use other colors for some specific gameplay elements as a visual cue as where they are (minigames, dialogues, fighting scenes).

I've described now how this segment of the GDD is being done. I will need some tome to define gameplay for all the scenes. Hopefully I'll finish it in the next two or three weeks.

I'll do some parallel work on comments and dialogues. By doing this simultaneously it helps me to get deeper into the game world and it can give me some better ideas regarding game world and quests. That is why I like to work it in logical segments. For example main ZOO area has specific setting, NPCs and quests. Once when I'm done writing down gameplay for this area I will make comments and dialogues for it. In those comments and dialogues there can be some references from this area or they can even give me new ideas how to improve this area by adding new details to it.

So... a lot of creative work ahead of me!

Stay tuned!