Comparative differences between games design and simulation design - Part 5: GDD and the SDD
During my first development project, I learnt about TLE and the companies SDD (which stands for an Software development document). Although more orientated around a TDD (Technical Design Document) or GDD (Games Design Document) in the games design environment, there are some similarities within the two styled documents that allow for a good view and breakdown in how the document is viewed or used within both industries.
In games design, it is usually defined as the "GO TO" document or "Bible" that is regularly updated whenever a decision is changed, although not the same in an SDD as usually the main designer will update it and hold it in a cloud based area for others such as tech leads or other users can look into it and add / edit when necessary.
Within a GDD, the main areas of concentration are the following:
Within an SDD, the main areas of orientated around the following:
SDD although is very broaden in the fact that its software orientated, the issue then becomes when it goes beyond the use of just software. In simulation, the use of sim engines and some gaming engines (like unity), it presents a clear restriction in some aspects to the visual presentation. In previous work within this new industry, I struggled to understand purposely what I was meant to be working with due to the fact that most of the people who were working with the engine didn't really care or know what it is to do to make an environment thus the documentation seen didn't help me retrospectively. Although it's more a criticism for later in the evolution, the sections are specifically designed to be orientated around a white style coding environment (Coding with little visual working) for my own perception of the document than what its requirements are specifically for visual design.
Although you can visually describe what it is you're wanting which i have seen with previous projects, having a visual concept or imagery to guide and present you what it is you're looking for is very helpful in specifying what exactly it is you're wanting. That is the main criticism that I can see straight off, another issue is more within how some of the areas are not really needed such as some mid sections within each of the sections are unimportant and really shouldn't be there.
That said, A GDD is also an issue with some of its areas. Although it sounds a bit stupid with the statement but when you're trying to design and work with a template. Like games design companies... unless you actually work within the industry.. you won't really know what the template will look like and every place has a different interpretation of what the GDD is and what should be included within it. Also a lot of information can be provided from a high concept design which is a mini GDD without most of the information like core mechanics etc.
Within each document style consists of problems seen within each industry in what is covered and what is not.. Although I'm more criticising of the SDD than I am of the GDD and TDD, it's more specifically because within my department when the whole process of sims isn't just sim engines but also including for other forms of virtual work as well. Its weird to think that although a document can be specifically set to a criteria of coding but in its design then presents a restriction specially as a designer that most of the stuff would be either none important or unnecessary but with future projects, hearing what is needed... a ground basis idea is helpful if a full creation will be made.
Overtime, with a look at documentation if the same process continues within future projects. An idea might be to go look at it and propose a change to allow for both styles of design in case of the future endeavours.
So what is a SDD?
A SDD is a go to document that holds all necessary information that is needed for a developer on a project to go, look at the requirements, look at how the software is setup, limitations, restrictions, aims and overall what is needed if someone else is inter grated into the team to replace or add on in the quickest way whilst trying to prevent slowdown on development. In engineering, it isn't orientated as much on visual and games mechanics as a GDD which is what is necessary for a games designer than an engineer but also in retrospect, for a designer a GDD isn't as strongly orientated around the programming or coding which is a positive but also a negative if perceived correctly.In games design, it is usually defined as the "GO TO" document or "Bible" that is regularly updated whenever a decision is changed, although not the same in an SDD as usually the main designer will update it and hold it in a cloud based area for others such as tech leads or other users can look into it and add / edit when necessary.
Within a GDD, the main areas of concentration are the following:
- Main Story Concept
- Breakdown on all characters (Protag, Antag, NPC's, Side players etc.)
- Goals
- Mechanices
- Win / Loss requirements
- World concept / design
- Input Concept
Within an SDD, the main areas of orientated around the following:
- Connection mapping
- Class definition
- Variable and breakdown of data
- Software required
- Testing
So whats the similarities?
At the top and overall view of the documents. They are specifically are the GO TO bible books which the way that the documentation is presented. It demonstrates the necessity that is needed and the documents are designed in a way that will allow for a small indie dev book or a complicated in depth big production title. The documents also hold necessary update information and set to be formal in presentation although it can be difficult to document and format properly if the document is not set up properly, I've found some formats to be horrible to work with especially in the way formatting is made or done.What are the issues with both documents?
Although this is weird, the issues are specific with their titles.SDD although is very broaden in the fact that its software orientated, the issue then becomes when it goes beyond the use of just software. In simulation, the use of sim engines and some gaming engines (like unity), it presents a clear restriction in some aspects to the visual presentation. In previous work within this new industry, I struggled to understand purposely what I was meant to be working with due to the fact that most of the people who were working with the engine didn't really care or know what it is to do to make an environment thus the documentation seen didn't help me retrospectively. Although it's more a criticism for later in the evolution, the sections are specifically designed to be orientated around a white style coding environment (Coding with little visual working) for my own perception of the document than what its requirements are specifically for visual design.
Although you can visually describe what it is you're wanting which i have seen with previous projects, having a visual concept or imagery to guide and present you what it is you're looking for is very helpful in specifying what exactly it is you're wanting. That is the main criticism that I can see straight off, another issue is more within how some of the areas are not really needed such as some mid sections within each of the sections are unimportant and really shouldn't be there.
That said, A GDD is also an issue with some of its areas. Although it sounds a bit stupid with the statement but when you're trying to design and work with a template. Like games design companies... unless you actually work within the industry.. you won't really know what the template will look like and every place has a different interpretation of what the GDD is and what should be included within it. Also a lot of information can be provided from a high concept design which is a mini GDD without most of the information like core mechanics etc.
Evaluation
The documentation is not the important part of the design process, in fact a lot find it troublesome specially if there is only one person who is developing which leaves a lot of time that could be found to be productive on other things than documentation. I found although it would a task of mine, an annoyance sometimes to update my document for my MA prototype. That said, it does specifically have its merits within the idea of everyone working on the same page to be exact, but the argument of time to work on that to working on other things and not documents such a waste of time to people to do.Within each document style consists of problems seen within each industry in what is covered and what is not.. Although I'm more criticising of the SDD than I am of the GDD and TDD, it's more specifically because within my department when the whole process of sims isn't just sim engines but also including for other forms of virtual work as well. Its weird to think that although a document can be specifically set to a criteria of coding but in its design then presents a restriction specially as a designer that most of the stuff would be either none important or unnecessary but with future projects, hearing what is needed... a ground basis idea is helpful if a full creation will be made.
Overtime, with a look at documentation if the same process continues within future projects. An idea might be to go look at it and propose a change to allow for both styles of design in case of the future endeavours.
Comments
Post a Comment