The GDD

One topic that comes up a lot during discussions of game design is the value, or potential lack thereof, of the Game Design Document. This living document, which can be used to guide and define the design of a game during both its planning and production phases, is a tool used by most major game studios, but it’s usefulness to a solo developer or small indie or academic team is more debatable. What exactly this document should contain is another point for debate.

So, what exactly is found in the usual GDD? That varies. This document, essentially an outline of a game project, is often tailored to fit the project and studio using it, but for those unfamiliar with the concept, some common examples of content might include:

  • Basic technical information about the project:
    • What engine will be used for development?
    • What platforms will it be released on?
    • What is the latest stable version of the game?
    • When is the projected release date?
  • Project goals and general design notes:
    • How could the game be described in one paragraph?
    • What are the game’s major gameplay and narrative genres?
    • What target audience is this game designed for?
    • What is the target gameplay length of the final game?
    • What are the game’s major selling points – why would players choose this game over the countless others they could be playing?
  • A mechanical overview:
    • What are the game’s major mechanics?
    • How will these mechanics be implemented?
    • How will players learn these mechanics?
    • Are there multiplayer modes or other optional gameplay modes?
  • A level/world/environment design overview:
    • How many levels/dungeons/towns/etc will there be?
    • What locations can the player visit?
    • Does the game feature shops or currency?
    • What are the designs of these levels or other locations?
  • A narrative overview:
    • Who is the character that players control?
    • What NPC characters are present in the game?
    • What is the game’s central premise or theme?
    • In what narrative setting does the game take place?
    • How does the player advance the story?
    • Does the game feature dialogue?
    • How does the story relate to the mechanics?
  • An overview of the User Interface:
    • How will the controls and camera work?
    • What menus can they player navigate?
    • What controls will they use to access and navigate these menus?
    • How do players save and resume progress?
  • An art design overview:
    • What is the overall atmosphere of the game?
    • What style should be used for the character designs?
    • How should the menus look and feel?
  • A sound design overview:
    • What atmosphere should the audio portray?
    • What style of music should be used?
    • What player actions will require sound effects?

Of course, this is only an example of a few game design basics that may, or may not be, present in any given GDD. Another thing that varies is the level of detail provided on any given subject. For instance, many game design documents also serve as technical documents, with specifications about how the mechanics, menus, and modes will be implemented in terms of programming and scripting, but others focus primarily on the design aspects themselves, without getting too deep into how these aspects will actually be implemented into the game. The genre of the game also naturally changes what should be present in the GDD. A highly story driven game, for example, might feature a full narrative outline or game script, whereas a more arcade style game may forgo the narrative design section nearly all together. Actual sketches, demos, or screenshots of level designs and other game environments may also be present or not in the GDD – it all depends on the amount of detail a developer desires to have in this single document, or in the case of some major companies, the amount of detail publishers require.

As with nearly anything, there are pros and cons to creating and maintaining a GDD for your game project. The discussion actually reminds me quite a bit of the classic ‘pantsing’ versus ‘planning’ debate for traditional writers – that is, whether or not to outline a novel or other writing project before actually writing it. As with a GDD, a ‘planner’ often writes the outline before beginning the novel and tweaks their notes as they go along and progress with their project. However, where game design documents differ from novel outlines is that a game has many more aspects to take into account, aside from narrative alone. A game design document can be very useful for combining the gameplay, narrative, audio, and artistic ideas a designer might have into one cohesive vision of a game. It can also help a designer remember some of the aspects of the design that might perhaps be slightly less exciting, such as the User Inferface and some of the technical details. After all, a game isn’t made from any one aspect – not the gameplay, the story, the art, nor the music. Instead, it’s the sum of its parts.

Personally, I tend to believe that game design documents are a very useful tool in the design process, even for a solo developer or small team, because they help the designers and the developers ascertain that all of their disjointed ideas really come together to form a complete and satisfying product in the end. However, there does come a point where the simple chore of recording and updating every detail of the game becomes a bit excessive or just another distraction from actually getting the development done.

Here is my personal take on the pros on the cons of the GDD:

Pros:

  • They are definitely useful for teams, and they help make sure that every team member is united in their vision and knows what they need to be working on.
  • They help a designer work through the small details of the game, from saving and loading to the gameplay camera.
  • They help designers ascertain that all of their disjointed concepts for the various components of game design – the gameplay, the narrative, the art, the audio, etc – all really do come together to form a cohesive whole.
  • The road map they provide, and their encouragement to plan out contingencies and details in advance, help designers attempt a project they might be more likely to actually finish.

Cons:

  • Game design documents must be constantly updated throughout the design and development process to remain useful, as the design of the game is always shifting as features are actually implemented, stories are edited, and resources are composed.
  • They take time away from actual implementation, and can lead to a slower start for a project. This is especially true for solo developers, who don’t have team members also working on and relying on the GDD.
  • They sometimes have a tendency to lead to either overscoping or underscoping. That is, they can encourage either feature creep or over simplification. After all, it’s easy to add a new feature to the design when all you have to do is write it down, and it’s also easy to be so intimidated by the road map that the nerves can cause a designer to play it safe.
  • They can turn into a distraction in and of themselves, if a designer becomes too focused on the accuracy and detail of the GDD.

For these reasons, when it comes to solo projects or small teams, I would tend to recommend GDDs more to those designers who might also outline a novel before writing one. For those who would simply sit down and start writing, forcing themselves to plan out and update a GDD might only hinder their progress on the project, itself, and they may find it easier to simply take less formal notes as they carve out their progress from nothing but the ideas in their head. I also find that game design documents tend to be more important for mechanical or gameplay oriented games. If a game is more story-driven, even if it’s otherwise fairly long or complex, it often seems to be more crucial to focus on nailing down the details of the plot, instead. The value of a GDD really does depend on the type of designer you are, and on the type of game you are making.

Regardless of the genre or situation, however, I personally find it most useful to write a GDD that focuses on the actual design of the game, not on the technical specifications of how that design will be implemented. In other words, I find it more useful to focus on concepts such as why anyone would want to play this game, how the gameplay and narrative connect, what the overall atmosphere should be, and how the difficulty curve should feel, instead of how any given feature will be programmed. I believe that a GDD should be about vision – it should be about turning your ideas into a cohesive experience that you are truly excited about creating, and it should be about why this experience will matter to the people who might one day play it.


 

If you are interested in creating a GDD for your project, a simple Google search will offer plenty of ideas and examples. If you would like something to start from, you can also download and edit the GDD template that I generally use for my projects here. (Some of the terms and concepts used in my usual GDD, such as engagement types and micro and macro arcs, come from terms used specifically at my school. They’re fairly self explanatory, but you can find definitions of those terms here.)

Regardless of what type of GDD you choose, it is important to tailor the document to suit your own personal style and the needs of your game concept.

 

Yearly Digest?

Whelp, it’s been forever since I updated this blog. The hush hasn’t been a lack of happenings, so much as a lack of time. Primarily, this is because I began attending a new college last fall. When this year’s summer break ends and fall semester starts anew, I’ll be a sophomore at DigiPen Institute of Technology, where I am pursing a Bachelor’s of Arts in Game Design.

Still, I’m going to make an effort to try to keep this place up to date, so to start, here’s a digest of what’s been happening in the past year.

First draft down!

I can happily report that I finally finished the first draft one of my upcoming novels, The Blue Crown. This is the same novel I talked about working on during Camp NaNoWriMo in my final post of 2015, and it so happened that I managed to finish off this draft during this year’s Camp sessions! The Blue Crown, now complete at 104k words, continued to surprise me. I’d expected to struggle and slosh through the final few chapters, but once I sat down and started, the end of the story came easily. This novel still needs a lot of work before it’s ready for readers, but it felt great to finally write ‘the end’ once more.

Final drafts are getting there?

The other novel I’ve mentioned quite a bit in the past, Paragon, is still in the works. I’m about 85% done with the fourth draft, but because of a bunch of plot and character changes, I believe it’s still going to need one more read through. I had hoped to complete the final draft and prepare it for querying before the end of the summer, but it doesn’t seem that’s going to happen. However, I do believe that getting Paragon out there by the end of year is very possible, and that will be my next major goal.

I’ve also already begun to pick at The Blue Crown. It is admittedly a bit of a mess in its current state, but not as much as Paragon was after it’s first draft. There are a few plot holes that need to be plugged and some rough edges that need to be polished, but I actually think there’s a possibility of this one being ready to go before 2017, as well.

That game demo is almost done

As for that demo of Glass, my full-length RPG game project, it’s almost done. It’s taken a hell of a lot longer to get it ready to share than I expected, with lots of little bugs and balance issues rearing their ugly heads, but I’ve also taken the time to add in a bunch of new combat and exploration features that I’m pretty happy with. It’s slow going, partially because I’ve also begun working on a few other game projects and because school kept me busy with game development work as well, but it is getting there. The only thing I have left to do is run through the content several times and make sure everything goes smoothly, from beginning to end.

On that note, if anyone would be interested in doing some pre-release playtesting of the demo, don’t hesitate to let me know. When the time comes, I should be able to offer compensation to those willing to test the game and provide feedback, but I’ll post more about this once it’s ready to go.

New RPG Maker MV projects

The semi-recent release of RPG Maker MV has served as a somewhat productive distraction from several of my other projects. After all, it’s hard to ignore an engine that’s shiny and new.

Right now, I actually have two game projects going in MV. On is a life simulation game mixed with dungeon crawling elements, which is still in its early stages of production. The other…I think I’m going to keep a bit of a secret, for now. However, I do hope to have this one ready for release by the end of 2016, as it’s already in its alpha stage of development.

2016-08-13

A screenshot of one of my MV projects. Hmm…this one looks a lot like Happy Birthday.

Fun with Unity Engine

Aside from RPG Maker, I’ve also invested some time in learning to use the Unity Engine. Actually, this is partially because it’s very similar to DigiPen’s Zero Engine, which is what I’ve been learning and using at school. It seems a shame to not be able to put some of those new skills to use in personal projects, since academic projects, while valuable in their own way, just aren’t the same, and I feel that getting your hands dirty on your own is often actually the easiest way to really learn and grow. So far, I’ve mostly gone through a bunch of different tutorials, but I do have a simple platformer game in the planning stages. Working with a new engine and on a new gameplay genre has admittedly been a breath of fresh air. Unity really is tons of fun.

Academic game projects

Of course, what I’ve spent most of my time with over the past year has been school. DigiPen likes to talk about its rigorous course work, and after freshman year, I can safely say that it isn’t kidding. DigiPen delights in keeping its students busy.

Still, at least the coursework is fun in its own right. While at the school, I’ve actually assisted in the creation of three game prototypes, lead the creation of one complete game, and designed and created several different board games, which was something almost entirely new to me, but surprisingly engaging.

I’ll talk more about these academic games projects, and what the experience at DigiPen has really been like, in a separate post on the topic, but in summary, in my first semester, I did narrative design for an adventure/puzzle game called Push the Button, level design for a puzzle game called Quantum, and narrative design and level design for a puzzle platformer called Artificial Platformer. In my second semester, I was both the lead designer and the lead writer for a murder mystery adventure game…expect it wasn’t a murder mystery because the college’s strict ‘PG’ content rating doesn’t allow murder in its projects, it was about a cookie jar. That was a fun one, in its own dysfunctional way. All of these games were completed in teams, and aside from working on the design of the games’ content and their narratives, I also dabbled with art and sound design, and did a hefty amount of programming and gameplay implementation from scratch, especially with Cookie Jar.

All in all, school has been a really great experience. There are a few things that bother me, such as a couple of sub-par teachers and the school’s general, dismissive attitude towards the subjects of solo projects and narrative design. Personally, I feel solo projects are really important for any game designer/developer in terms of learning who they are as a designer, and in terms of becoming well-rounded. Team projects have their own benefits, for sure, but they aren’t the same as really digging into your own project and facing down your own weaknesses, as well as really building on and discovering your strengths. In a team, it’s too easy to stick to only what you already know. Also, anyone who doesn’t believe that narrative design is an important aspect of game design is out of touch with the game industry and its diverse audiences as a whole, but these topics would also be better off in a different post. Despite these complaints, however, the school has definitely helped me grow as both a game designer and as a person, and I’m looking forward to returning next month.


All of this aside, I’ll update this blog more often during the coming school year. If there is anything you’d especially like to hear about, let me know. Has anyone experienced any exciting happenings since the August of 2015?