Video Game Technical Design Document Template
Now that I have established that a technicaldesign and architecture are good things to have, it is time to define what goes into the technical design document. The technical design document acts as a plan of attack on the requirements of the game: a plan for whom, when, and how these requirements will be accomplished. This technical design document is a miniature project itself going through several stages: requirements capture, requirements analysis, high-level architecture, mid-level software design, deployment design, a testing plan, and a transition plan. Each of these stages will be chock full of documents, diagrams, and time estimates to complete the tasks described within. Requirements Capture Capturing use cases The requirements capture stage is the most critical to a successful project and in many ways is the most difficult. It is Capturing use cases difficult to decide when you have identified all your requirements, and it is also sometimes difficult to describe them clearly, such as when you are trying to push your graphics to the "next level," whatever that might be. Let us tackle it in order of easiest to most difficult. The easiest requirements to capture are the requirements described in the game design document! This document should have a design for the main game interface, the shell screens, the game mechanics, the art design, and the content such as missions, levels, and puzzles. The Unified Modeling Language has the use case diagram, which is most helpful in the requirements capture stage. The idea behind the use case diagram is to note the actors (users and other discrete systems such as a CD authentication server) and the interactions these actors have with the software system. The use cases of the officer menu in Starfleet Command 3 The above use case is from Starfleet Command: The Next Generation. The function of this menu is to act as a vending machine, "selling" new officers for the players to use on their starship and allowing the players to "sell" back the officers they already have. The purpose of this diagram was to collect every single action the player would have with this menu and arrange it graphically to aid in the technical analysis of what needs to be done. Accompanying this diagram is a regular document detailing these individual interactions or use cases. Displays or Player Views View Ship Name View Current Prestige View Starbase Name View Current Officer Assignments This display displays six such officers; there is no scroll bar. At all times there is to be an officer displayed here; even when the player transfers out an officer, a flunky ensign with basic skills throughout will be displayed. We need a long list of potential officer names that is race specific and easy to add to. View Officer Profile A. Officer Attributes B. Officer Skills Helm Skills OPS Security Medical Tactical View Available Officers If there are no officers available at this starbase, display this text: Player Activities Accept Transfer Out Transfer In Auto Assign A fundamental tenet of the Unified Modeling Language (UML) is that you should never create documents and diagrams just for documentation's sake. You should use your own judgment on how much rigor you should apply to the problem. That is because beyond the use case diagram, UML offers eight more diagrams such as the test case, the activity diagram, the sequence diagram, the class diagram, the package diagram, and the deployment diagram. This could be a bewildering array of diagrams if you went about every menu with nine different diagrams and 50 pages of supplemental text. You would quite clearly never make a game, but you might make a bureaucrat proud. With that cautionary statement about not going overboard, I think it is well worth your time to collect all the use cases that directly involve the player. Unlike most business applications, we game makers have the player perform many interactions, and some are quite complex. Take the time to create a use case diagram for each shell screen. Most of these you will not need to document much, just some notes here and there about how many characters that text entry should take, how many digits that display should produce, and so on. It is absolutely required that you create a menu flow (my term) diagram to chart the flow between your shell screens. The main display of your game, whether it is an isometric role-playing game, a starfighter game, or a racing game, should be where you put in most of your use case analysis time. Take the time to mock up the display in Adobe Photoshop or some other layout tool. Then carefully hunt and peck for every interaction and requirement you have or the main display. I would recommend using a whiteboard or a piece of graph paper to collect this first pass of interactions and use cases. The menu flow diagram for Black9 Next, rearrange your use cases to factor out common functionality or behavior from your various interactions and create your use case diagram in a tool such as Visio. As a last step, adorn your use cases that have certain requirements, like a frame rate of 60 seconds, that are not direct interactions. This can be articulated as a note on the view main display use case. An example of adornment To be productive with interactions, do not attempt to analyze the use cases into anything that resembles implementation. At this point you do not care how the interactions will be handled; rather you just want to know what the interactions are. Reverse Engineering No matter how hard you look, you will never uncover all the use cases and system requirements for your game project during the technical design portion of preproduction. Don't worry about it; anytime you discover a new use case, just figure out where it is factored into existing behaviors, if any, and update the use case diagram and supplemental text. Nonobvious Requirements Design requirements—you want the game to support user extensibility, such as a map editor or a scripting language, or use an existing code base. Interface requirements—similar to a design requirement but closer to the code, such as using OpenGL over DirectX for portability. Implementation requirements— these are unusual coding standards such as the commerce level of transactions and database storage when implementing your own billing system for an online massively multiplayer game. A simple example is the platform Performance requirements—examples of these requirements are the all-important high frame rate or a tolerance to a specified level Internet latency. Requirements Analysis The analysis model is not the name of a diagram, rather it is the name given to the collection of diagrams, text, and designs that lie between the requirements capture stage and the deeper design stage. It will be in the design stage that you make your final plans for the construction of the software. In short, the analysis model is perhaps a fancy name for your first pass at the rest of your technical design. You can create a package diagram recast in the analysis model, a sequence diagram, or a collaboration diagram. What you are seeking to do is iteratively move towards the deeper, more specific constructs. The goal is to avoid creating bugs and defects in the game's design and architecture that could be fixed now just by rearranging some symbols in Visio rather than rewriting a tree of classes near the shipping of your game due to a subtle bug. You must use your judgment here to decide how far to push the analysis model. Getting the client-server interactions of a massively multiplayer game is a place I would feel comfortable taking my time. Looking over the previous table, it is clear that no matter what software development process or lack of one is employed, you will always end up analyzing your requirements and implementing the requirements. What is to be accomplished in the requirements analysis stage is to pause and take stock of the use case model and "parse" it into developer language by taking the use cases that have been grouped together by factoring common behavior and come up with proto-classes and basic sequences of events. The idea is to start jelling the technical design without committing to final class diagrams; this will prevent you from following what may be the wrong path of implementation. In other words, if you start producing final class diagrams in response to the first use case you see, then you will produce a system that best answers that first use case. In any area of the game where you have a complexity of use cases, all of them vying for your attention, you should probably take the time to stop and produce an analysis model of the aggregate use cases. As always, use your judgment; there will be many times parts of your game will not require the rigor of an interim analysis model to be developed before going ahead and creating your final technical design. For example, the menu presenting two buttons to the players requesting them to choose between single player and multiplayer game mode will not require deep thought, and you should just go ahead and take the use case diagrams as the analysis model with a mockup of the screen and its place in the menu flow, I would call it a final design! Class Diagram The class diagram is the workhorse of technical design. Most programmers along the road of objectoriented design will discover the class diagram on their own. Either they were faced with a tangled set of code in a maintenance job and started scratching sense out on a graph pad, or perhaps they are facing a complex new system they have been tasked to create, and they want to nail it so they reach for the whiteboard to consider a few different class hierarchies. As the following shows, the class diagram is a simple collection of boxes, each representing a class, and lines between the boxes showing how the classes are related to each other. There are many bits of detail and formal notation we could add to the class diagram such as descriptors declaring a method to be public, private, or protected, and whether a class is a template class or whether we are referring to an instance of a class—an object. These additional bits of notation are a part of the UML I will introduce later, but for the moment let us just consider the essence of the class diagram: classes and relationships. A basic class diagram Relationships Drawing "is a" and "has a" Relationships and Ordinalities Focusing on the difference between "is a" and "has a" relationships Adding Annotation Other UML Diagram Types The class diagram is one of the diagrams used to perform structural modeling. Two other UML diagrams for structural modeling are the object diagram and the package diagram. The object diagram is a variation of the class diagram where the instanced objects and the relationships between these instanced objects are the focus of the diagram. The class that the object is an instance of is semantically designated by naming the object box like this: Goblin: Monster. Important attributes and values of the object are listed below a dividing line in the box as seenin the accompanying diagram. An example of an object diagram Package diagrams are used to organize your class diagrams. Once you have about a dozen or so classes on a sheet of paper, they will start to blur together and lose their meaning. A package diagram looks a lot like a collection of file folders where the interesting bits of class are listed inside the file. An example of a package diagram Dynamic Modeling Sometimes a simple state diagram cannot model the complex message flow between various objects performing interesting tasks in your game. For example, in a client-server game there is often a complex flow of data going back and forth from the clients initiating requests and providing user input and the server taking all of this information in, resolving the game actions, and sending out packets to cause the clients to correctly update their displays. A very useful diagram to model this detailed, complex behavior is the UML sequence diagram. An example of a sequence diagram Architectural Diagrams UML also provides a deployment diagram that appears to be useful only for massively multiplayer client-server games. The deployment diagram describes where all the pieces of the software are going to reside at run time. An example of a deployment diagram For most games, especially console games, the deployment of the game software is well understood and a deployment diagram would only be another diagram in your technical design document suitable only for impressing Dilbert's boss. Large-Scale Planning and the Evil of a Long Build Time A full rebuild of any large project will take a long time, but a small change to the implementation of a single function in a file will be a snap for the compiler to change and the linker to come up with a new executable for you. However, the gray area is where you realize you must change the interface to one of your classes and a header file must be touched. If only a couple of files include this header file, no worries, but if dozens and dozens of files include this header file, look out you might as well just do a rebuild all. The trick to good large-scale project making is to consistently practice good OO and keep your code modularized. Very crudely speaking, do not get in the habit of copying the include directives from one file to another like a huge fishing net, hoping to catch the right file. Take the time to verify that each and every include directive needs to be at the top of the file you are working on. This has been a constant struggle with our Starfleet Command series. When I took over the project in 1998 it was my largest project to date and I had a lot of challenges. (I will skip boring whining comments.) Too far down the list of priorities was writing code with a fast build time. At the time we were under heavy pressure to make a date, and all of us thought this game would be it and we would be on to other projects. We had no idea our game would be such a success as to meritw orking with the same code four years later. Our project builds slowly due to its size, but it is a crime that relatively minor architectural changes cause significant build times (30 minutes or more!). We would love to rewrite the entire Starfleet Command code base from the ground up that would be the way to go! However, with tight budgets we must use as much of the animal as possible with each release. In this realworld example we have chosen to go the route of incremental refactoring. Refactoring Refactoring can be applied to cleaning up any aspect of how your code is created. For the latest version of Starfleet Command we have separated the 3D rendering engine into a separate DLL, and we have vastly decreased the labor involved in sending messages back and forth between the client and server. The multiplayer code base both at the application level and the UI level were refactored. And the disappointing UI engine that we inherited from 1998 Quill we have wrapped a safe and sane coding condom around that performs as advertised while leaving the underlying Quill alone. Refactoring is a pragmatic practice, and I am a practical person. So we are rewriting and polishing up significant chunks of the code as we go, creating better software as we maintain a regular release schedule. Insulation Besides just practicing good OO there is another technique your programmers can employ tactically to sections of the game to dramatically insulate portions of the code from each other. It goes by different names such as Interface-Impl and Insulation. The basic idea is to create an interface class that contains an implementation class. The role of the implementation class is the traditional role of getting the job done, and the role of the interface class is to be the only public access to the rest of the project. This permits the developer of the implementation class to change the attributes and members of the implementation class all day long without needing any other modules to be recompiled! A classic example of the use of insulation is a class that is a stack. The stack could be written using an array or a linked list (or quite a few other data structures) to push and pop data onto the stack. You write this class as clean as you want, but you will always give away your implementation details in the header file. Sure, that information is privately declared, but it is still publicly viewable and, more germane to this point, any changes to the stack classes implementation, say from an array to an STL list, will cause a rebuild of all modules that ever used your stack class. A stack written as an array : A stack written as a linked list: A stack fully insulated from implementation details: In practice there are many variations you can take to elide your implementation details, with the wholesale privatization of the implementation class being the most aggressive and achieving the highest degree of insulation. I have worked on a project that used this method of insulation aggressively throughout the project, and after discussing it in depth with my teammates, in the end we disagreed with the widespread use of insulation. In particular it makes inheriting a class a pain, and while it does save a lot of mind space by hiding the implementation details from the rest of the team, it also places an extra duty upon the developers who have to write the interface and implementation classes. In the end, we decided it is most useful in larger classes like game manager classes, which are likely to undergo a lot of revision in development while at the same time are unlikely to ever have anything derived from them. Please read the detailed and wellwritten book on a relatively unexciting topic, Large-Scale C++ Software Design by John Lakos. Forward and Backward Code Generation with a Modeling Tool Think about it; your programmers can link a bunch of boxes together in a class diagram describing the relationships between the classes, attributes, members, parameters, public, private, protected—quite a few details hit a button, and bam the files are created and the skeleton code is written! All that is left for the programmers to do is program. That makes UML cool. The reverse engineering part can come in handy when you need to digest a whole mess of code. It really is quite fun and educational to generate large class diagrams and spend an afternoon pasting them to a wall and reading over them to get a feel for the lay of the land. There are several tools to choose from for the creation of UML diagrams, including Rational's Rose and Together from Together Soft. We have even been teased by Microsoft that Visual Studio 7 will come with a new version of Rose bundled into the development environment. So yes, you can use your own boxes and lines, but why not use the boxes and lines that have software out there that can help you? Testing Plan Unit Testing and White Box Testing The best kind of unit and white box testing is automated. For example, some developers of 3D games have a test where a computer constantly generates random locations and directions for the camera to look at to see if any positions and/or views cause a crash. In the development of Excel, Microsoft employs three or more redundant, independent algorithms for the calculation of the worksheets and compares the values across them all to identify errors in the algorithm that is being optimized for shipping with Excel. Black Box Testing Beta Testing From Use Cases to Test Cases
Requirements capture is the process of identifyingall the requirementsthe game as a piece of software must satisfy to meet the goals and expectations for the game. Requirements can take a myriad of forms from a frame rate requirement of 60 frames per second, to fitting on a single CD, to not taking more than 80 programmer- months to complete, to having very few defects, to having 3D sound or 10,000 polygon characters, to being part of the engine development. The goal is to write down every single expectation the team, the executive manager, the designers, and the fans have for the game. Note that this stage is named simply requirements capture; there should be no efforts to cull, prioritize, or otherwise analyze the requirements and make any decisions. The goal is to just cast the net as wide and as far as possible and be very thorough in collecting all of the fine details. Any premature efforts to analyze the incoming requirements will bog down the process and create decisions that are made on less than the full set of information available to make these decisions.
These are just views; there are no player interactions in these use cases.
This is a simple text display of the player's ship's name.
This is a simple text displayer of the player's current display. Display these prestige points in normal text output color if they have enough prestige to buy the least expensive officer in the base; if not display this prestige as red text.
This is a simple text display of the name of the starbase or location that the player is performing officer selection. In the case of multiplayer or skirmish games, display the name of the mission type.
This is a complex display combining the following elements:
This is a complex display combining the following elements A and B:
Each of the skills is broken down into three sub-skills and a display of skill rank. The skill rank should have a header of skill rank rather than the vague info as depicted in the current interface diagram. The skill rank should be a word description:
This is a complex display combining the following elements:
Cancel
All transfers in and out and auto-assignments of the player's officers are thrown out and the officers the player had in place when entering the menu are restored as well as the prestige the player had at the start. The player is then returned to the source menu or activity from where they came from. An "Are you sure?" modal dialog might be a good addition to this choice.
All transfers of officers in and out of the ship and auto-assignment of officer stations are committed as well as the prestige changes. The shadow copy of the officer assignments from the beginning is thrown out. The player is then returned to the source menu or activity from where they came from. An "Are you sure?" modal dialog might be a good addition to this choice.
The officer that is currently selected on the side of the player's ship—the crew manifest—is transferred off of the player'sship and is placed in the starbase (and is viewable there). When the player transfers an officer out they only receive a K constant on the trade-in value for the officer. I would like to initially set this value to 1.0 so that the player has no inhibition on transferring their officers from station to station. However, I would like to be able to change this value later, for balance or difficulty settings. It should always be successful to transfer an officer out. The transfer out button is always available. If the player selects one of those basic ensigns with no skill, it just disappears into the ether and cannot be effectively transferred to a new station. This is to prevent the player from transferring out their infinite supply of ensigns and filling up the starbase.
The transfer in button will take the officer currently selected on the starbase side and swap places with the officer currently selected on the player's ship side (effectively performing a transfer out of this officer at the same time). If the player does not have enough prestige to transfer in the selected officer from the starbase, then the color of the cost of that officer is red and the transfer in button is not enabled.
By a simple algorithm the officers on the player's ship will shuffle about to have the officer with the best skill for each station. The algorithm should be something like this: Take an officer and average the officer's Medical sub-skills to compute an average Medical skill rank; repeat this with all major skills and all six officers. Now sort the officers in order of who has the highest major-skill value from largest to smallest. Whomever is at the top, assign them to the station that corresponds to the skill that has the highest major-skill rank. Keep going down the list until all six stations are filled.
Now all this is just fine when you are working from a clean slate, but in this world of licenses and franchises you will often find yourself working on a sequel or port of a previously released game. Use case diagrams are a valuable tool for performing reverse engineering, that is, taking a system that is already built and working backward to understand how it works. Understanding how the existing system works is a key step to successfully taking over someone else's code base. Here all of the use cases are already functional in an existing game. Your job is to play the game and take note of every interaction the player is having with the game and every requirement expressed in the previous game and produce use case diagrams and use case documents to describe the existing engine. Last year at Taldren, when I hired Ken Yeast to take over maintenance programming for my area of SFC: Empires at War, he had a little trouble wrapping his mind around the sequence of events and interactions involved in the matching of humans and AIs in the online gameplay for SFC: EAW. Ken not only came up to speed with my code in an efficient manner, but was actually fixing subtle and complex bugs with the ability to "see" what is expected of the system.
Here are some other nonobvious requirements that your game may have:
for your game PS2, PC, GBA, etc.
The purpose of the requirements analysis stage of the technical design document is to take the use case model of the game, which describes the game in terms of player interaction, and create an analysis model of the game in the highest level of technical design for the developer. The following table enumerates the purpose of the analysis model.
The class diagram describes the static relationships and roles of the classes that comprise your game's software. The class diagram can be exhaustive and detail every class and relationship and be printed out on several hundred sheets of paper and pasted to a wall (we have a couple of walls at Taldren serving this purpose for fun), or your class diagram could be focused on a narrow portion of the game such as the classes driving the AI of the starships in your game.
The class diagram models the static relationships between the classes. It does not model any dynamic behavior of the classes such as when they are instantiated or destroyed, and it does not describe the message flow between the classes. It is the relationships between the classes that make a class diagram a picture of value rather than just a collection of boxes on a piece of paper. These relationship lines describe the dependencies between the classes, and these dependencies define the architecture of your game. There are several vocabulary words that are employed in formal OOD to describe the relations between classes, however they are all variations of three possible relationships. The "is a" relationship is used when one class is derived from another class. An example of this is: a textbook is a child class that "is a" book. The "has a" relationship denotes the relationship between a class that uses another class in its composition. The textbook class could have a "has a" relationship with the page class. Very neat and tidy, eh? Well, I have a loose end. There is one more relationship that occurs between classes; it is the compile time dependency in which one class uses another class in the implementation of a method (also known as a function). Any module that manipulates strings is quite likely to include the header file string.h from the Standard Library. Each type used as a parameter in a function creates a dependency between that class and the invoked type. Drawing every single dependency relationship between a class and all of the other types that are employed in methods of our class under study would only create a very hairy diagram sporting way too many lines to be useful. That is why the dependency relationship is a kind of third cousin to the more important "is a" and "has a" relationships.
The "is a" relationship is denoted by a line between two classes with an arrow on one side pointing to the parent class. The "has a" relationship is just a line. The "has a" relationship line is often adorned with the cardinality of the relationship on either or both sides. An example: The "has a" relationship between the textbook and the page class would have the Arabic numeral "1" on the side of the textbook and an asterisk "*" on the side of the page class. This shows an indeterminate number of pages contained in the textbook. It is also quite possible to be more specific. The relationship between the die class and the face class could be adorned with a "1" on the side of the die class and a "6" on the side of a face class unless you are playing third edition Dungeons and Dragons as I like to do from time to time; in that case the relationship between die and face would need that asterisk back again to account for your pile of 20-sided, 12-sided, 10-sided, 8-sided, and 4-sided dice.
Quite often you will want to add important information and details to a class diagram that is not a class or a relationship but a note. To add a note to your diagram, simply draw a rectangle and dog-ear a corner, then draw a line to the class, object, or relationship that you want to clarify. Adding performance requirements such as "must render a steady 30 frames per second to the 3D view class" is a good example of a relevant notation.
The Unified Modeling Language provides a number of diagrams that support different areas of technical design and software architecture. In a later section I will cover in greater detail the diagrams I find useful. Here I will present the briefest of introductions to the rest of the UML diagram family.
Structural modeling is the modeling of how the software will be constructed from a static point of view—in short the activity you would imagine when setting out to architect your game. However, your game also has dynamic functionality, and UML has diagrams to handle this activity. Remember flow charts? UML has polished up the flow chart and now calls it the activity diagram. The activity diagram models the logic flow from start states to end states.
Modern games are becoming large pieces of software that need to be designed and orchestrated on a macro scale. The UML provides component diagrams to illustrate the relationships between modules, libraries, dynamically linked libraries, databases, and other significant chunks of your whole game's software composition.
There are a few tricky parts of building large software projects that all of this solid planning aims to keep in check. The largest bugaboo of large projects is large build times. With computers already amazingly fast and only getting faster every month, it is easy to not care about build times. When your project builds and runs in five to fifteen seconds after making a change to your code, you never break your concentration. When the build times grow to about a minute or two in duration, the build time might be just long enough for you to reflect on what you are doing and perhaps be able to perform useful thinking. Once build times grow to five minutes or more, you have a serious productivity leak. When build times reach twenty minutes or more, people will naturally take a walk down the hall to chat with neighbors, hit the restroom, gulp some water, or get invited out for lunch, and two hours may elapse before they settle down again at their workstation.
Refactoring is the art and science of making the code better without adding new features. A smart maintenance programmer will take time to not only understand the code but also to clean up OO foulings and other architectural errors in the code.
I fear I may be straying a little off the path of the technical design document. However, I defend myself by wanting to convey to you not only passion for reducing build times, but also some practical advice on achieving faster build times. I also argue that a section in your technical design document discussing your coding practices and software design approaches, including a section on build times, could only earn you a nod of approval from the folks who are to review your technical design document as well as acting as the most clear piece of communication to your team about how you intend for build times to be managed.
So why do I advocate UML's particular set of boxes and lines for describing software? Well, any set of lines and boxes will do, as long as you think through the stuff you need to think through and communicate it well to your teammates and project stakeholders. That being said, UML is making rapid progress in beingaccepted as the industry standard for describing and documenting software. By becoming an industry standard we are now seeing several products on the market that will perform both forward code generation from your diagrams and reverse engineering on existing code. I should let that settle with you for a moment.
Towards the end of your technical design document you must have a section on your testing plan. How will you test your game? Toss it to the publisher and fix what they ask? Beta testing, unit testing, black box testing, or white box testing which will you employ?
Unit testing is the most straightforward of testing procedures. As you finish a piece of your software, write a testing suite to exercise your new piece across all ranges of valid and invalid input and see what breaks. This is the sort of activity developers of the piece of code should implement as a matter of course in the development of their work. Also note that unit testing will not work with poorly architected code as you will have few truly modular parts of your game that can be tested independently from the rest of the game.
This is the type of testing most publishers will perform on your game. They may have organized checklists to follow, but in the end it will be a bunch of young folks early in their careers playing your game in a relatively unstructured manner, looking for things that are broken. The advantage black box testing has over white box testing is that since the testing is performed from the user's perspective with no knowledge of the implementation details, black box testing will often find bugs that a white box testing plan was not even looking for. The flip side is that since the testing is not based on any knowledge of the implementation of the game, the testing can become rather unfocused and can consume quite a lot of man-hours in the pursuit of bugs.
Beta testing is great; it is putting the game in the hands of people who will buy your game. Fix all of the bugs they identify and you know for sure you are spending your time on bugs that need to be fixed. The problem with beta testing is that it is an exaggerated form of black box testing, where you have fans just playing the game and reporting what they feel like reporting. Beta testers also consume great amounts of the development team's attention, as they are real people who will express their feelings and need continuous feedback and direction to keep them happy and productive. However, every game (and product for that matter) should undergo beta testing, as it is the only way to determine if you really are making something people will enjoy.
How do you organize your black box and beta testing? Again, UML offers an aid, the test case diagram. The grea thing about this diagram is that it is just the use case diagrams from the start of our project being dusted off and getting a shiny new label. Remember all of the use cases you worked up to describe all the interactions between the player and the game? Those interactions are precisely what you want to test during your black box and beta testing efforts. Just collect all of your use cases and convert them into a checklist of a testing plan for the black box testing team and the beta testers to test.
Video Game Technical Design Document Template
Source: https://www.wisdomjobs.com/e-university/game-developing-tutorial-261/what-goes-into-the-technical-design-document-6744.html
Posted by: aherncapsery.blogspot.com
0 Response to "Video Game Technical Design Document Template"
Post a Comment