RSS

The Difficulties of writing a TDD

19 Aug

It’s coming up to the end of Studio 1 and I thought it’d be a good time to express some of the difficulties and importance placed on a Technical Design Document. In the earlier weeks of Studio 1 we had only recently learnt about a TDD and what it’s supposed to do. My understanding of a TDD is that, it is a place where all of the scripts and systems are set out in place and how they will interact either separately or as a part of – or with something else.

Ultimately – it is an entity as a whole, as how the game will function.

The only difference being making a game and writing the TDD is that you are actually designing systems before trying to create them and make them work. I’m not going to say that Transmutation has failed catastrophically because the perfect TDD wasn’t written. I was about to say that our TDD was a good start, but after giving it a quick review I can safely say that it only started to scratch the surface of what Transmutation currently is.

In my head thinking about creating Transmutation it seems easy to say I could make it, or I could make it by myself if I had to. The core concept is to have mutants spawn – have switchable playable characters that can attack mutants. There’s a beginning state and end state. Survive for a duration or die and some bits and pieces in between. Easy enough right? Sure – If I had all the time in the world. But that’s the catch, I don’t. A TDD is supposed to be the building foundation for figuring out systems before trying to create them. It’s supposed to be time saver and a reference for the already designed system instead of figuring it out as you go.

So as an example – As you can see in the first play test there’s quite a number of issues. Instantly a big standout is the fact that mutants can float.

1962b6

Floating Mutants

The NavMeshAgent was something that wasn’t documented in the TDD – I knew it was they way to go and I’m almost certain both programmers and I discussed using navmesh (and we all knew how to use it) as a way for the mutants to move. It was originally just “Find Player One” and translate the rigidbody towards the players location. But by the first play test navmesh had never made its way into the game?

A) If it was documented from the start – rather than designing a placeholder system for mutants to move – we could have had the correct movement from the start. And like I mentioned before it’s the time saver. Do the hard brain work before trying to implement the system.

B) Even if it wasn’t in the TDD – why did the navmesh fall off the priority list? Would have it made a difference in the task schedule? Even if we didn’t know exactly how we were going to implement it, having it in the task schedule would make it take priority over creating a dud placeholder. Or even forced us to take a step back and go “Right! Navmesh – Instead of just trying to implement as we go, let’s head back to the TDD and figure it out first”.

And that’s only to mention the Mutants floating. The same could be applied to the elevator doors not opening. Although I figured that out as I went and it worked before play testing, It could have been achieved faster and worked properly every time if it was designed before implemented. The same again – could also be applied to the mutants trying to find every player instead of a single one and only moving towards it.

I’ve only had a small fraction of practice with TDD’s, Ball Ball was my first go, Sea Of Mutiny didn’t require a TDD, Transmutation was my second go. So I’m slowly building up an understanding on the importance of actually writing a TDD. I know it’s important and I know it should be done. But not in little stints, like figure 5/100 things out, work on the 5, get them working perfectly and just continue on working blindly for the other 95 things. Either go back to the TDD or get more sorted from the start. Writing a TDD isn’t a one off “Right I’ve written one, it’s perfect – now every TDD I ever write will be a breeze”.

NO. THIS STUFF IS HARD YO!

The important thing to take away is that I’ve made a mistake, I can learn from it and do better next time. Instead of doing all of the nitty-gritty documentation stuff that a person who really knows what they’re talking about Game Dev related says so. And try to be done with it as fast as possible so I can go make stuff, because having a physical representation of what the game needs on a screen rather than in a document doesn’t mean more progress has been made.

Until next time –

FeenikxFire

Nic

Advertisements
 
Leave a comment

Posted by on August 19, 2016 in Uncategorized

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: