hey, heres my story, im learning C++ Gave Dev via a home study course, its a legitimate course offering an nationally recognised qualification, im now up to my first portfolio project (10 - 15 page TDD, not a GDD) and im stucker then bubble gum stuck to a rag....

does anyone have any recommended or go to links that they would pass on for me to find some sort of decent reference so i can gain some insight into what is included in a decent TDD, i have done a few google searches but i cant really find anything that is helping me get a grip of the situation..

any help of any kind is appreciated,

cheers fellas

It really depends on what you want to portray in your technical design document. From my experience, a lot of teams have different methods of working. Some prefer to use very detailed TDDs maintained by a technical designer and the engineering team. Whilst other teams prefer to work with more freedom and simply have a TDD with basic information, like rules, formulas and assets required.

The best thing to do first is find out what your team (or the company you want to apply for) needs in a TDD and tailor it for them.

When I write a technical design document, I like to write the brief overview of the area I'm working. I then go through the overview and expand on the idea and add values, rules and other bits of technical detail to the design. I sit with an engineer and explain to them the basic idea before I move onto the next stage. They might find a problem with you idea or problem with your design which needs editing before you can go into further detail.

After that I then explain what's required in order to get that design from paper into game. Listing out things like formulas, data values, models, textures, audio and most importantly outlining what sort of code support the design will need if a massive help to anyone else looking at this design.

One thing to consider is how you present your TDD. For example, in a 2D fighting game I would draw a 2D diagram of the animation flow and then write the technical damage rules and timing values. This is a lot more useful for an engineer and artist as opposed to an array in excel with a list of moves and damage values.

I found this on youtube. It seems like a good way to get started if you want an example:

Hope this has helped. :)

cheers for the pointers mate, appreciated

TDDs aren't supposed to blow minds. I'm used to TDDs that are created by a developer doing work for a publisher, for whom the TDD is written. They're essentially a statement of the solution to the problem (you can view a GDD as a statement of the problem). What software technology are you going to use to build the game -- what equipment are you going to use -- what personnel are you going to use, what are their roles, and include their resumes/CVs. What is the hardest technical aspect of the game, and how are you going to deal with it. What version control system will you use. And discuss the filenaming convention. Even if you're not making the TDD for a publisher audience, it's a very useful document to write -- it's like a business plan for the technology. It focuses your thinking and gets you into the proper mindset for the endeavor to come.

thanks, seeing as this is my first official project that counts towards my final marks i want it to be perfect / mindblowingly so, i really appreciate the help and direction im getting here, thank you,

question... would a TDD contain example coding for say some sort of AI and then explanation of why i have structured certain aspects in such a way?

thanks, seeing as this is my first official project that counts towards my final marks i want it to be perfect / mindblowingly so, i really appreciate the help and direction im getting here, thank you,

question... would a TDD contain example coding for say some sort of AI and then explanation of why i have structured certain aspects in such a way?

Excessive details about how the game works are going to be worthless in a TDD, because they are volatile and because they are only interesting for coders who are going to work with the authoritative actual sources and data files, not with your incomplete and potentially obsolete quotations and summaries.

Provide an overview of the important technical choices and their reasons, without neglecting the options you discarded; you'll need such "theory" as a starting point to revise those decisions (possibly in another project) and/or as evidence that your decision-making process was sound and diligent (both to convince yourself that your TDD is finished and down the road when your technical choices turn out to be disappointingly bad or unfit for unforeseen requirements).

For example, suppose that at the beginning of development you chose a middleware that does what you need, and then halfway through your project the company that should provide updates and support for it suddenly evaporates. Can you show your manager that when you researched that solution you found nothing but popularity, customer satisfaction, timely updates and good support? Or does your TDD show that you neglected the less technical aspects of the software selection process?

Thanks people, u are all being a huge help, though this task still looks scary im feeling a little bit more comfortable with where to start,

Sloper Strikes again. Thanks mate.

I'm somewhat looking into this myself, atm (TDD and GDD). So good going with the topic. herbertsworld's video is nice as well. I'm gonna check out more of letscreateagame's channel etc.