How my TDD and Repositories have evolved between the 1st and 2nd group projects.

Link to my WWW TDD:

My first attempt at creating a repository went very well.  I was using Bitbucket with SourceTree and created the repo easily.  The problem came when I first tried to push the initial project to the repo.  I had what seemed to be a catch22 error.  Couldn’t push because I hadn’t pulled, and couldn’t pull because I hadn’t pushed … at least that is how I remember it.  Corey was my programming partner for this project and we quickly changed over to GitHub for windows.  This went OK up until the last day when the repo crashed and nothing could be done.  Pat Monaghan quickly amended our “gitignore” file and fixed it, just like that.  *sigh.

Our TDD reflected my use of Bitbucket, but did not evolve when our need to change repositories occurred.

This was not a “living” document …. and on reflection, neither is my second one, but we will get to that shortly.

The document itself, is full of useless crap from the template, that should have been deleted.  There are no risks documented and considering the genre of this project, there should have been some risks.  Player not understanding the puzzles, player not understanding the way to transition between characters.   These were obvious after play testing and should have been documented then, at least.

The reason why this, and the next TDD wasn’t a living document, is because it was not a priority.  To be totally honest, the first time I looked at these documents, since creating them, was just now, before writing this blog.  That makes me a little sad, because the work and thought that went into them was wasted.


Link to my Valour TDD:

The thought and effort in my second TDD is more apparent.  The only useless thing from the template at the start of the audio section.  The remainder is concise, to the point and relevant to this project.

But again, it is not a living document because the concept about parallax scrolling of the scene and Lists/arrays for checkpoints throughout the level are still mentioned.

It is interesting to note that I did identify three risks and that each one of them came to fruition.  I naively did not identify the risk that team members would let the project down by leaving the art assets until the very last moment.  In hindsight, it could have been foreseen.

But this risk section needs to do more than merely identify the risks.  It also needs to identify the ways that the risks can be averted.  References to the GDD document would be applicable for the three risks I identified, and if there was nothing in the GDD, then it needs to be amended to make sure that my risks can’t be traps for the team to fall into.

As to the risk of team members letting the team down.  I believe that there should be a detailed, documented course of action for keeping the team on track and dealing with members that are not pulling their weight.

As to making it a living document, I believe that any changes can be made through using the strikeout feature and re-writing sections, at least for the duration of this course, so Lecturers can see that the document has changed over the length of the project.  As the document’s creator, it is my responsibility to make sure that any changes affecting the document should be discussed with all the other members of the group and bringing in the Game Producer if there is any lasting conflict over the changes.

Most of the content needs only be done the once and then reproduced for future projects, with minimal changes.  For example, a tutorial for using github only needs to be done once and only changed when a flaw has been identified, which only means that you have a new version for the project after that.  The same can be said about the process for checking if team members are pulling their weight.

My second attempt at creating a repository was a lot better. There were no conflicts with pushing, pulling or merging.  I don’t know if that it because I am still using the essence of Pat’s gitignore or whether everyone was more aware of using a repo.

Two think I will take out of this, is that there need to be more documentation about using the repo in the TDD.  There needs to be more than just supplying a link to it.  There should be provision for what to put in the comments when pushing.  No comments, or “The name explains it”, are essentially useless.  Full details should be provided.  The documentation should take a new comer by the hand and help them create, load, clone and use the repository.

While there has been a marked improvement between the two documents, there is a lot more room for improvement.


Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s