June 17, 2011

Progress

Using concepts from Agile I feel pretty confident about my current goals. I've mapped out my first iteration and have started work on it. Unfortunately, I happen to have more spare time than I anticipated so only a few days in I'm 2/3 done a 2 week iteration. Now, those that have no idea about what I just said: I'm doing more than I thought I would. Right now I'm in the process of starting on the settings menu for the framework.

The question is what kind of settings should I have without even having a game to manipulate? Obviously, one of the them will be FPS, possibly even graphics quality... which... i'm not sure that is something I want to support at this point. I could put in an Audio flag, but I have no audio so that seems almost silly. Maybe the ability to adjust the FPS is all I really need at this point in time. If the game requires more settings I should make it easy to add them in.

I want to change the game so that on start up the screen displays a splash screen. Most of the back-end is coded and really I just have to add a few things and pop the splash screen up. I totally threw test driven development out the window and massively over-engineered the buttons. I created a number of things that I am not currently using, but I will definitely be using and re-using them in the future. So really I won't have to rewrite a better implementation next iteration.

This is why I dislike test driven development, you program for the now and not for the future. That is great when requirements change for your program, but when you know what you are going to be doing. It would be silly to just simply ignore them now and have to re-write the code again later when you are adding new functionality. I'm not saying I spend hours figuring out the best way to do something, but I do take a few moments to figure out a good architectural approach to a problem. If I at least start with something reasonable I can then go back later and enhance it if needed. TDD simply says, write only the code needed to make the test pass. Which really means that your implementation might work, but it could be a nightmare to change later or even perform very poorly. Having to write additional tests to simply prove that your implementation is a poor one is great, but why bother writing bad code in the first place?

No comments :

Post a Comment