For the camera system I made, when I handed it to the people for using it, they found it very hard to set it up. So the first thing I will do after developing a tool is write a tutorial on how to set up that particular tool I have developed. Through all the feedback I have learnt a lot of new things about constant testing and fixing.

One of the main things that I have learnt that if you are developing a tool, always have a version with you that works. This allows a steady flow from development to testing. The more the people have a chance to play with it, more feedback is possible and can iterate on the tool further. I wish I had the time to do the changes that I needed to do so that could get more feedback from other people. What I should have also done was that should have made a questionnaire every time someone tested the camera system. This way I would have had a more detailed description of the various things they found both good and bad and then could have reflected upon that.

While I was making the camera collision system, I used a simple hack to fix the clipping planes. It was not the most efficient way to do it but I will be working on fixing that in the near future.

One thing I would definitely consider using is process described in the below flow chart

I have also been researching on methods like Test-Driven Development(TDD) where it offers more than just simple validation of correctness, but can also drive the design of a program. By focusing on the test cases first, one must imagine how the functionality is used by clients (in the first case, the test cases). So, the programmer is concerned with the interface before the implementation. This benefit is complementary to design by contract as it approaches code through test cases rather than through mathematical assertions or preconceptions.

For TDD, a unit is most commonly defined as a class, or a group of related functions often called a module. Keeping units relatively small is claimed to provide critical benefits, including:

  • Reduced debugging effort — When test failures are detected, having smaller units aids in tracking down errors.
  • Self-documenting tests — Small test cases are easier to read and to understand.

I hope to use these in my future projects both in games and while developing tools.