Building Click #3: Blindness and Debt

In the last edition of Building Click, I asked when the appropriate time to re-factor is.  The answer to my question was 27 revisions ago. I initially decided to ignore what needed to be fixed because my desire to fix was such that it was preventing the application from being successfully written. It seams that I am now reaching the opposing extreme in that now my code contains much needless repetition. This repletion was allowed for the sake of the simplest solution but now it’s getting to an extent I can no longer ignore in good conscience.

Because of this I have decided to branch the development branch and work on cleaning the existing tests and code up before adding aby new features, at which point I will begin my usual test-re-factor cycle again to avoid accumulating this level of code stench again. I’ll maintain the original concept of implementation simplicity by not going too nuts with the design patterns and architecture, I just want to break the big monolithic blob that is the Game class into a few smaller well-defined classes for the sake of cleanliness and future maintainability

After my refactoring the application will be structured as below:

Game:

Acts as the external interface to the system with which the UI will interact. This class will act as a facade over internal classes and will become considerably lighter as most of it’s current responsibilities will be re-assigned to single-purpose classes.

Timer:

Will contain all game timing functionality and probably game state management logic as the state of the game is heavily dependent on timing.

Counter

Responsible for score-keeping functions.

 

To me these alternations seam simple and well-defined, id anyone (James?) has questions or comments relating to these changes please let me know.

Building Click #2: When To Re-Factor

Right now I’m listening to Groove Armada and staring at the source code for Click, not coding, but thinking about what I have written and what’s wrong with it. I should issue the caveat that for the proposes of this conversation wrong refers to something that I don’t like about the code and not something functionally wrong with it.

A class is supposed to model a discrete object like a Window or a Button, thus far the Click engine exists as a single monolithic class that has become a central repository for the entire engine which makes me uncomfortable.

Because of my tendency to not finish projects I have ignored the bad smells in the code for quite some time and development has progressed, however I fear that if I don’t do any cleaning the code will become increasingly difficult to work with in the future

At this point my plan is to branch 0.1 when it is feature complete and clean up, but to be honest I’d like to do it sooner, I would also appreciate some different perspectives on the issue so feel free to contribute in the comments.

Building Click #1: History, Changes, And Progress

This series of posts documents the creation of Click from it’s previous life to what we hope will become our first ever game.

---

Before we delve into Click and it’s creation, I feel obliged to explain that this is not the first time I have tried to write this particular application. As with many of my previous projects, this one was shelved based on what I can only describe as frustration.

The original idea for Click came from a union of my desire to write code and my desire to irritate the world en masse. Click requires that the user to earn as many points as possible in a limited amount of time, should the user succeed points are earned. A mostly functional version of the game was constructed some years ago but this had a number of issues and was abandoned.

I decided to rebuild Click for a number of reasons:

1. I enjoy writing and playing the game.
2. I am determined to complete a project, it’s a vital step in determining whether or not I really have what it takes to be a software developer
3. It gives me the opportunity to play with new technologies and put into practice what I have learned since the original failed attempt

This version of Click shares the same basic concept as it’s predecessor while making significant changes. The biggest change is the move from Windows Forms to the Silverlight platform, which will allow the game to be played within a browser on Windows, Mac or Linux.

As well as technical differences another major area of change can be found in my attitude to the development process. I tend to want to do things “right” to the extent that if something is not right, I will stop and modify it until the wrongs have been rectified, however this often leads to frustration and incomplete software, so for Click I have adopted a strategy of making it work before I make it right which has lead to some ugly looking, but functional code which I can’t wait to clean up in the next version.

As of right now 90% of the engine features selected for version 0.1 are implemented and I anticipate that the remainder will be complete in the coming weeks (time permitting). After this we begin the design process for the user interface, at which point we will have something you can actually see.