Purpose of the Technical Design Document - Game Developing

The technical design document is the blueprint for the software engineers on your team to use in the creation of the game. The ideal technical design document will specify to your developers not only what needs to be created but also how it will be implemented. I was introduced to strong software architecture for the first time in the game industry when I worked under Jay Lee at Interna (a game company that has since joined the mound of defunct gamecompanies). When I signed up for the job as a developer at Interna, I was looking to learn more about C++ and artificial intelligence.

What Jay Lee did was to use strong encapsulation of the implementation details by creating a detailed set of interfaces for the classes of the whole game (a massively multiplayer casino game). Jay labored for two months writing header files. There was not a bit of working code at the end of his two months, just header files. I remember that the members of the team were a bit skeptical about this; we thought while leadership was great and architecture was probably a good thing, would it not be better if our best programmer were writing some code? Well it turned out that it took three junior developers just three months to flesh out the source files as indicated by Jay’s headers to implement the software Jay described. It was the fastest any of us saw software come together.

JARGON: A header file or a .H file is a file in C or C++ that describes the interface to the software module defined in a corresponding source file (.C or .CPP file).

Jay Lee demonstrated very strong software architecture; ever since that experience I have been learning more about creating software better. The relationship between software architecture and the technical design document is that the technical design document is broader in scope and less detailed than a software architecture plan. The technical design document must synthesize the requirements of the game, develop a software design, serve as a testing plan, and also supply the project manager with critical information such as the required developer roles, dependencies between tasks and developers, and an estimate of how long it will take to perform each of the tasks assigned to the developers.

The conceptual overview of a technical design document

The conceptual overview of a technical design document

The technical design document has other customers besides the developers on your team: The game publishers are becoming savvier in their technical evaluation of game developers as the scope of the projects grows and the associated risks with the projects increase. Most likely you will need to deliver a technical design document as an early milestone to your publisher. The problem with a technical design document is that while most of the strong publishers are now asking for them, there are few senior game developers with the requisite technical expertise to perform an adequate review of the developer’s technical preparations. This lack of technical review means the technical design document will be poorly reviewed and as such is not a very visible deliverable. This creates another problem; early in the project the executive management is almost always eager to see progress in a game’s development. Often they cannot visualize the game the way the game designers are able to and are forced to green-light a project based on feelings of trust in the developer. All executive management teams would rather replace this trust with seeing some cool eye candy on the screen showing that the game is happily in development and looks fun. This creates an unholy tension when the developer is pressured to not think about the technical design of the game much in the early stages and must instead play catch-up all project long. It is widely known in the software engineering field that you would much rather identify and fix a defect in your software at the design stage than at the end of the project. Estimates vary, but the consensus appears to be that it is fifty times more expensive to fix a bug at the end of the implementation stage than at the design stage. Thus, I encourage you, by whatever means you can, to take your time on the technical design phase of your project and work closely with your publisher or executive management to make the work of the technical design stage visible and reviewed to assure that progress is occurring on the project. Email me if you come up with tips on how to get publishers more excited about the technical design document.

Strong process, poor process—relative efficiencies

Strong process, poor process—relative efficiencies

The later you identify and fix a bug, the more the cost rises.

The later you identify and fix a bug, the more the cost rises.

Why Have a Software Development Process?
All development houses have a development process even if they do not consciously go about creating one. A development process is the method your team uses to take the game specifications and turn them into a game. Even the solitary game developer working on her own private game, iterating each night after working the day job still has a development process. This lone developer’s process could be as informal as writing up a sketch of the main game interface on a piece of graph paper and then incrementally building the game, a new feature every night, until the game is playable. Some high-profile game development companies also use this method.

Steve McConnell’s seminal book Code Complete is one of the most accessible works discussing in detail software development methods and why organizations resist learning new development processes. The problem with learning a process is that it takes time, and most organizations are in short supply of time. They are under great pressure to get something visible and running as quickly as possible to reassure management that the project is well under way (a recurrent theme in this book, I know). A strong software development process will emphasize thinking at the beginning of a project where a weak development process will create an even larger burden of wasted time at the end of the project. In the most extreme cases of poor process, the projects find themselves in such a hole of despair due to poor decisions made at the beginning of the project that the project itself is cancelled rather than throwing everything out and trying again. I am firmly convinced that all of the games in the industry that are taking 30 to 60 months to complete are being performed at development houses with a poor development process, which results in a poor preproduction.

It is understandable why gamedevelopment companies are generally poor at enforcing a strong software development process. First of all, most software companies are poor at the development process by all accounts; second, the industry holds creativity sacred (a good thing, but it can be used as an excuse to avoid professionalism); and third, the games themselves are always becoming larger, faster, and more complex—about at the rate of Moore’s Law. The result is that studio heads or publisher executives who might have had hands-on experience in creating a game five years ago now have a misguided interpretation of the scope of the project they are responsible for. Interpreting Moore’s Law liberally, it would suggest that over five years a game would be eight times larger in complexity and scope than an equivalent title five years before. This last point I think is significant and rarely discussed; managers are often walking around with an impression of the work to be completed as much smaller, like when they were creating games hands-on. They were successful then, or they would most likely not have achieved their leadership position. That means they must have been successful with their software development process and that the penalties back then were correspondingly smaller. I think this is a great source of subtle evil in the game industry.

JARGON: Moore’s Law—computing power will double every 18 months. So are you ready to hear about a better software development process?

The Unified Software Development Process
We at Taldren use a modified, light version of the Unified Software Development Process. I will, however, present an overview of the full Unified Software Development Process and then go back and explain what we do.

The core workflows of the Unified Process are requirements, analysis, design, implementation, and test. Looking over this list of five activities, I would imagine most people in game development would be surprised to see the three preproduction activities: requirements, analysis, and design. If I were to interview game development houses to ask them what core workflows (after explaining what I meant by the term) they are using in their development, they would probably say design, implement, and test. This is one of the key features of the Unified Process; it formally recognizes that gathering your requirements is a different activity than analyzing the requirements, which is in turn a wholly different activity than designing your software to meet your game’s requirements. If you think back towards an earlier chapter on gathering your key business parameters before creating your game design document, you will notice that I added a bit of material from the game development domain to the requirements capture stage.

Core Workflows of the Unified Process

  1. Requirements
  2. Analysis
  3. Design
  4. Implementation
  5. Test

The Unified Process recognizes that a real-world project cannot crisply complete one workflow and then move to another workflow. To address this, the Unified Process is an iterative and incremental workflow method, where each stage of the project is driven through inception, elaboration, construction, and transition.

Phases of a Workflow in the Unified Process

  1. Inception
  2. Elaboration
  3. Construction
  4. Transition

The work flow of the Unified Software Development Process

The work flow of the Unified Software Development Process

In the real world you will find yourself late in the project, perhaps near alpha, when you realize that your game inventory system is broken and not fun (it turns out tracking the adventuring gear to the nearest gram was not a great idea), so now you need to go back and design a new inventory system. The Unified Process would have you stop and think about your new inventory system, review your requirements, analyze what impact the new inventory system requirements will impose on the existing game, design the new inventory system, implement it, and test the inventory system.

The various models of the Unified Software Development Process

The various models of the Unified Software Development Process

Perhaps at this point you may be getting bored and rolling your eyes and thinking to yourself, “This is just a bunch of fancy multisyllabic names; of course I think about my stuff before I code it.” While it is true that these terms are just a bunch of jargon, if you actually consciously name what activity you are performing, you will have a much greater awareness of what you are doing. This awareness will translate directly into being more purposeful about collecting your requirements when the sign over your head says you are in requirements capture; you will be a far more effective analyzer of the requirements when you are not obligated to think about how you are going to code the rasterizer. Your designs will be much stronger when you have all of the requirements and their impact laid out in front of you.

When Should the Technical Design Document Be Written?
The technical design document should be developed in preproduction along with the game design document but perhaps staggered back a bit to allow the game design document time to form up. The technical design document needs to be developed with a thorough set of plans and time estimates before the schedule and the project plan can be completed.

During production it sometimes becomes necessary to change the direction of some features in response to technical research, focus group testing, market research, or an awareness of a lack of thorough design in the preproduction stage. In response to any change in the game, a fast response mini-technical design stage should be initiated before any new development of these changes is undertaken. In other words, don’t allow your deeply thought-out technical designs to be The various models of the Unified Software Development Process held up like stone tablets that must be followed. By all means, change yourdesign during implementation if you identify a better design

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Game Developing Topics