TDD and GDD

Documentation of Technical Design Document(TDD)

• A Technical Design Document (TDD) is a method for a team of programmers to build and code the game's features. It allows the team's developers to specify the requirements, how they should be achieved, and the tools and technologies needed.
   
• Furthermore, the TDD is a valuable document to display when looking for a publisher for your game since publishers are increasingly cautious about analyzing the games they may invest in.
   
• The Technical Design Document serves as a template for your team's software developers to implement and code the game's features. The technical design document will allow your developers to specify what needs are, how they should be achieved, and the tools and technology needed.
   
•  The only difference between a software architecture diagram and a technical design document is that the technical design document has a greater scope and contains less information.

Technical Design Document (TDD) Sections

Depending on the company or project, the information contained in a TDD may differ. However, some sections are more common than others. Therefore, we'll divide them into core sections and different sections.

Most important sections: The core sections appear in all TTDs, regardless of the game's theme.

The GDD's features: Because the TDD is the document that will manage all technical aspects of the game's development, it's vital to outline the most significant components of GDD so that they're easily accessible.

Technical Hazards

While we are prioritizing team goals, there are also hazards to consider. If the business plans to make a level similar to Dishonored 2's time-travel level (where you can move from the past to the future while the environment changes), one of the hazards could be having two maps loaded and drawn at the same time slows down the game. The risks are written down in the TDD to account for them.

Objectives in Terms of Technology

The technical goals are a set of objectives created to ensure that everyone on the team knows where they should be directing their efforts. They specify what expectations to accomplish in the code, game engine, or platform that will deliver the game. Immersive ambient sound, intricate AI, and realistic shadows are some examples.

TDD Code Style Guidelines

This part, which is one of the most important in TDD, describes the code conventions that will be used throughout the development of the entire project to have an ordered and homogeneous code that any programmer on the team can both comprehend and work with. The programming team's goals determine the depth of the code style requirements.

The following are some examples of items found in this section:
 

• Naming rules: Describes which language the code must be written in, how variables and functions must be named, how we should use parentheses and whitespaces, and whether or not we should use comments. 
  
  Consider the following scenario:

We must write all #defines in capital letters:

#define MAX_HP 300

 

• When utilizing classes or structs, it explains how to handle variables, how to declare and initialize them, and whether to display them in the public, protected, or private area. 
  
  Consider the following scenario:

Each time a pointer is constructed, we must set it to null:

int* test = nullptr;

 

• Loops: Explains loops to use (while, do-while, for) and utilizes the break and continue keywords in the code.
   
• Conditional statements: Explains how to manage conditionals, such as whether to separate them if the line from the functions within the conditional or to put everything on the same line, when to utilize scopes, and whether a dependent with or without operators is preferable. 
  
  Consider the following scenario:

Rather than if(something == true), we prefer a conditional like if (something)

 

• Classes and structs: There is a standard for when to use lessons, when to use structs, and how to write the elements.
   
• XML: Describes how to write variables in the project's XML files and how to name their nodes and attributes. 
  
  Consider the following scenario:

If a node only has one attribute, it will be declared in the same line:
 
<house colour="red"/>

Other Important Sections of TDD

• Game Engine Selection
• Diagrams at a high level
• The 3D objects, topography, and settings are described in detail.
• Application of the Physics Engine
• Artificial intelligence and game logic
• Specifications and information for audio and video
• Networking
• For operating the game on a system, you'll need a delivery platform and the necessary hardware and software.

Advantages of TDD (Technical Design Document)

The ultimate purpose of a design document is to make communication and alignment easier, not to add needless bureaucracy to the process.

A technical design document's use is to assist in critically examining a problem and its suggested solution and communicate priority, effort, and impact to various stakeholders.

A good design document will anticipate concerns and queries throughout the code review process, identify edge cases, and allow users to offer improvements before a significant amount of work has been completed.

Note: If a design document is contentious, it's a good clue that a face-to-face discussion is needed or that the problem isn't adequately stated.

Even if there are many schools of thought on what exactly is in a technical design document, the benefits are pretty obvious:

• Provide an apparent reference throughout the process to speed up implementation.
• Create architectural alignment ahead of implementation to reduce friction in code reviews.
• Provide replies to stakeholders, reducing distractions for busy engineers throughout implementation.
• Once the system is operating, it serves as a resource for anyone who wants to learn more about it.
• It's beneficial for onboarding new team members.

Disadvantages of TDD (Technical Design Document)

Although there are numerous benefits to using a Technical Design Document, there are multiple drawbacks.

• In one way or another, it's out of style.
• We now live in a digital world where everything is digitally advanced. Thus there is very little need for paperwork in this new era, especially for technical design documents.
• Because they are rigid and inflexible by nature, updating TDDs is a complex and time-consuming operation.

What is GDD?

A game design document (GDD) is a software design document that acts as a blueprint for your game development. It aids in the definition of your game's scope and establishes the project's general direction, ensuring that the entire team is on the same page.

Anyone who says "check in the design document" refers to the Game Design Document (GDD). This document describes all of the game's characters, stages or levels, gaming mechanics, viewpoints and settings, storyline, and numerous menus and options implemented, among other things.
 

A GDD typically includes the following items:

• a quick summary (game concept, genre, target audience, project scope, etc.)
• Playing the game (objectives, progressions, in-game GUI, etc.)
• Science of mechanics (rules, combat, physics, etc.)
• Elements of the game (worldbuilding, story, characters, locations, level design, etc.)
• Music, sound effects, 2D/3D models, and other assets
   

The game design document is one of several that cover every aspect of the game you're making. The production plan refers to all of these papers taken together:

• Documentation of a Concept or Vision (Proposal)
• Project Schedule 
• Project Schedule 
• Software Testing Plan 
• Risk Mitigation Plan 
• Artistic Design Document
• Technical Design Document 
• Project Schedule

Relation between GDD and TDD

Both the TDD and the GDD are video game-related living documents, which means they are updated and altered frequently during the product's development. The Game Design Document (GDD) is a videogame's soul, comparable to a television series' Bible (sometimes a GDD is also called Bible). 

It enables game developers to organize and manage their ideas in a document that will be followed by all team members and used as the foundation for the game's development. The TDD, on the other hand, is a blueprint for all of the technical components of the GDD-defined features.

In this approach, "although a GDD is generated from the game concept and is a functional description of the game from the user's point of view, a TDD is an architectural description of the game from the implementer's point of view," as Laura Deng mention it.

Advantages of GDD (Game Design Document)

 

1. Make Your Concepts Real:  It's a means for you to refer to specific characteristics or features of your game. When working with a group, a GDD ensures that everyone in the team understands the game's overall structure and operation.
   
   This makes it easier to communicate between departments, minimizes confusion, and reduces the amount of back-and-forth, saving you a lot of time. A Game Design Document is still helpful if you're a solo developer because it acts as a great reference. As previously stated, neither of us has a perfect memory. Therefore, you may forget specific details. You won't have to worry about it with a GDD (unless you somehow delete it).
   
    
2. Keeps you concentrated: Many game creators make one of two planning errors: they either include too many or too few features in their game. Both of these issues are equally problematic.
   
   Both of these issues can be solved using a game design document. It can keep track of all of the gaming features. It is evident when you have too many or too few features. You'll be able to plan adequately for your execution.
   
   The most remarkable Game Design Document can also reveal the game's missing features and functions. Maybe you made a platformer game but forgot to add a jump feature. Unless it's part of a deliberate design decision, it's something you should indeed include.
   
    
3. On the same page with everyone: Multiple parties are involved in most game development projects, including developers from various departments and stakeholders. The entire process will become chaotic if everyone involved is not on the same page.
   
   Each department of the game production team will carry out its vision for the game, which may differ from the ideas of other departments. The game's accurate picture will remain elusive, if not non-existent.
   
   On the other hand, this problem avoids with a game design document. A game design document will lay out the game's vision in detail. As a result, each department will know what it has to do with no inconsistencies. It would also be simple for various stakeholders and project managers to maintain track of the entire process. When folks get off track, they'll be able to identify it and correct the route. This approach can also benefit solo developers.
   
    
4. Excellent for marketing: If done correctly, GDD may be a goldmine for PR and marketing. It includes your game's distinguishing elements, concept art, a general theme, etc. You or whoever is in charge of your marketing can create screenshots, trailers, press releases, etc. And, because a good GDD usually includes some information about the target audience, you or your marketer should be able to develop these products to capture their attention.
   
    
5. Some game design docs are so extensive that they even cover the audience's target identities. This can assist marketing teams in creating targeted marketing campaigns that will help you gain more users.

Disadvantages of GDD (Game Design Document)

 

1. They err on the side of caution and make a lot of assumptions.

A design document's concept is just that a record. It's not a game fragment, and it's not proof that an idea is brilliant; it's just the concept. This simple Microsoft Word investigation of ideas precludes them from ever being confirmed. Many assumptions will be made along the road, and your product will now be built on flimsy grounds.
 

2. They are constantly out of date.

Let's pretend we've created a fantastic document and have it implemented by a developer. We've discovered that several features need to be updated. Not only must we provide direction to our developer at this point, but we must also begin dissecting our document to improve it for future reference.

You must update your documentation whenever you make a change in the game. A never-ending cycle of revisions and adjustments. All of the time could be spent assisting with programming, asset creation, or balancing things that will benefit the team and the product. I promise that your design document is out of date in at least one significant area if you look at it right now.
 

3. They are very inflexible.

Design papers aren't open to interpretation by definition. They're not drawings on the back of a cigarette pack that needs deciphering. They are precise plans and blueprints for an idea that must implement numerically, or the design will break apart. This rigidity kills team innovation, saves everything for the designer, eliminates buy-in, and creates a barrier between ideas and implementation.

Frequently Asked Questions

What is TDD?

The development team creates a Technical Design Document (TDD) that describes every element of the overall design or specific parts of it, such as The signature of an interface, which includes all essential data types and structures (input data types, output data types, exceptions)

What is GDD?

A game design document (abbreviated GDD) is a dynamic software design document that describes the design of a video game. The development team creates and edits a GDD, primarily used in the video game industry to organize work within a development team. The development team creates the document as a guiding vision used throughout the game development process due to collaboration amongst their designers, artists, and programmers.

Why is the game design document referred to as a "living document"?

As a result, a game design document is frequently referred to as a live document, i.e., a piece of work constantly improved throughout the project's execution, sometimes daily.

Conclusion

This blog has thoroughly discussed technical design documents and game design documents. In software engineering, design documents of some kind are helpful. Your team and company primarily determine the format you use. What matters is that it can provide you with the information you require.

On the other hand, overdoing the design document can be a waste of time that could be better-spent coding; ask why each piece of a document template your company employs is in there, and remove any that aren't required.

A class dictionary with functions and variables for a class, in my opinion, is a step too far for design papers. Unless, of course, the team is so inexperienced that it benefits them!

For more in-depth knowledge, check out our more blogs on game development PyGame library in Python, Building Snake game using PyGame Part-1, Building Snake game using PyGame Part-2, Python Libraries Game Development,  Game Developer and Game Designer, and Game Theory. Please look at this YouTube tutorial to learn more about the placement preparation strategy.

You can familiarize yourself with lots of interview questions and can explore more. 

For more such fantastic articles, check out the website Coding Ninjas.

Happy coding!