General purpose

While my tile class is not finished, it is finished enough for what Coffee Quest Revenge needs. To be perfectly honest, I have probably spent more time on the tile system then was needed. I could probably have gotten away without having a tile class and having a fairly simple map class (what I am working on this week, or at least will be working on Thursday through Saturday). I am writing a more elaborate class for both maps and tiles. The reason being is that these classes have uses with a large variety of games so having general purpose classes will allow me to use these classes with many additional games in the future. The obvious advantage is that once the work is done, the work does not have to be re-created for slightly different versions used in future games. While cut and paste coding can also be used to gain this advantage, it is probably better to have a proper set of classes. The key disadvantages to creating general purpose classes is the extra time required, the speed, and the overhead.

Obviously, if you are creating a class that is going to be used for a very specific thing, you only need to write the code necessary to do the particular thing that is needed. When you are creating a general purpose class, you have to take into account all sorts of uses for the class. This takes time to figure out and time to implement. Of course, nobody says that the whole class needs to be implemented, so only the functions that Coffee Quest Revenge needs have been implemented, with a todo list of additional functions that can be added when they are needed, so the time requirements are not as bad as they could have been.

Speed is another issue and is one reason may game developers, especially in the early days, would avoid using common libraries. Because you are doing things in a more general way, there is less code optimization and shortcuts that can be taken. This means that overall, the common libraries will run slower than something that was written for a specific purpose. In the old days, this could have a significant impact on a game. With the speed of today's computers, this is much less of an issue.

Finally, there is some overhead in getting the general purpose classes to work the way you need them to. In the case of Coffee Quest Revenge, the tileset used is pretty hard set so could have easily been hard coded into the game. Other CQFS engine games will not be so lucky and need to have much more flexible tile sets. This means that Coffee Quest Revenge needs to set up the tileset information to use the common classes even though this work could have been avoided if I would have wrote special purpose code for handling the map.

One final note. I have plans for Wednesday night so won't be getting any work on CQR done. This means that the second build will be delayed another week, though I will be putting in my ten hours on Thursday night, Friday night, and Saturday with hopes that I don't fall behind in my ten hour commitment again. This also means that I will not be posting tomorrow, but will try to post Thursday evening.

Directories

I spent the day adding the directory links to all the game pages on the site. I was catching up on my podcast listening while doing all the cutting and pasting. I foolishly did the directory links as hard-coded links, but when you consider that all the pages are permanent pages anyway this is not that big of an issue. Though a better way would be to generate the directory algorithmically, though as the actual path doesn't always match the directory of the content, this probably wouldn't be as easy as if I had planned for a directory from the start.

While "organic" programming has become trendy lately, due to the frequent release schedule I force upon myself, Blazing Games and all the games created for it have always had an organic nature to them. By organic, I mean that you start your program (or site, as the case may be) with small initial goals. You then grow the program by adding new features and functionality to it. As iterations pass, you end up with a much larger entity than you ever imagined you would have. Sometimes you are able to trim chunks of the project (refactoring the code), though sometimes you end up with knots due to the way the thing grew (interfaces that have to be maintained even though they don't quite fit in with the rest of the growth).

Blazing Games has grown to huge proportions, and hopefully it will continue to grow over the upcoming years.