Future-proof Your Code

You don’t need to, but it might just help you in the, er, future.

I still don’t have a name for my new app, but it’s got a working title of DiscGame. This is because the app is a game based around the concept of flicking a disc at a target. Inspiring stuff.

Anyway, future proofing computer code; what’s that all about? In the context of DiscGame it’s about creating general data structures and classes that can be used to implement many different variations of the game. The reason for the future-proofing is so that a new idea for a variant on the game should, in theory, be easily implemented by using the existing code. There will always be some new coding required, but a lot of the main building blocks will be in place.

To this end, I spent a couple of hours today re-factoring the code in the prototype just to get that future-proofing in place. Two hours of coding to get me back to the exact same place I was already at, albeit with code that is now in much better shape to take on new game variants.

To give you an idea of the game variants and why this re-factoring is important consider this. The first game of DiscGame is a simple “Highest Points Wins” game. The player swipes discs up the screen towards boxes and each box is worth a certain number of points if the disc stops within it. Simple. The first variant is a “Round the Board” game, which features a set of boxes that have to be landed in in order.

There are, at a basic level, three things to think about in these two variants: the movement of the disc and tracking where it finishes; the layout of the boxes that the disc can land in; any specific rules.

My future-proofing means that two of those three things are handled by re-useable classes. Firstly, the disc is implemented in a class that handles all display, update, and interaction code. When the disc is swiped and it stops moving it raises an event that other code can process. In essence, the disc code can be re-used in every game variant without any new code being written. Secondly, the boxes that make up the game board are all handled by two classes; the first that provides details of an individual box, and the second that provides a collection of the first in order to handle group processing. Again, this means that the code across game variants can all be handled by the same class, e.g. fading boxes in and out is handled in one place, no matter how many game variants there are.

The bit that can’t be future-proofed is the specific rules of each game variant. However, because the other pieces are re-used it means that the only new code really required for each variant is these rules. So, for example, in “Highest Points Win” I need code to handle the addition of scores when a disc stops. In “Round The Board” I need code to figure out if the disc landed in the required box and if so what the next box should be. New variants will effectively only require the code for the rules as the code for the disc and the boxes is re-used.

With what I’ve done today I’m now in a place to fine-tune a lot of the game code in one place (the disc and the boxes), and free to work on the almost plug ‘n play code for the rules. I’ve got a lot of ideas for the different variants and I think some of them will surprise you with their simplicity and elegance of implementation. Never mind how addictive they’ll be.

Oh yeah, and then I ordered an iPhone 5, because all good re-factoring deserves a reward.

%d bloggers like this: