Dodeka Development #2
Author: HS_Dave
- Posted on: 13/11/2014
Post Type: Blog Entry
What a month. I've been to hospital three times (twice for myself, once for my wife) and just when I thought it was all calming down I ended up with food poisoning. Still, despite all that I have managed to get some work done.

I have quite a few features I want to bring to Dodeka but in order to bring them into the engine there is a "lot" of prep work to be done because of the way it was originally written for Duodecad. This starts with a lot of re-factoring to make the old code simply readable, a lot of code extraction to new classes to properly encapsulate it all and in some places just straight up rewrites to more sensible or more extendable code to allow the new additions to take place later down the line.

One of the things I've added is a new Game Rules system. In Duodecad there were only two rules that affected the stats of cards on the game board (other rules, like plus, are basically triggers for additional capture attempts) and the checks for them were built into the main game loop (I release forgiveness to my past self for my coding crimes). That is fine on a purely functional level, the game works as the user expects. But when it comes to extending the game with new rules (or even making changes to existing rules) it's a really bad system that gets very ugly, very bloated and very unmaintainable very fast.

With the new system I can define game rules as classes that implement the GameRule interface. In simple terms the interface describes some core functions that allow a specific rule to process the current game state and output a result based off the end result - whether that output is a modification to the attack power of cards on the board or a new capture attempt etc is up to the specific rule. This has two immediate effects on the game engine:

1) The actual core logic loop has been trimmed right down with all rule code removed. It's very easy to read and basically summarises as "for each active rule: Rule.Process()". This makes for a much easier to maintain code base.

2) The engine has become highly extendable. To add new rules and behavior into the game the process is basically to add a new class for the rule that implements the GameRule interface, write the logic for the rule inside the class Process function and then let the game know the new rule exists by adding AvailiableGameRules.Add(MyNewRule); to the Init() function.

What bugs and issues I actually run into as I add new features and rules in the future remains to be seen, but already this type of system is a massive leap from what used to exist. It is a wonderful (and perhaps slightly uncommon) use for the powerful c# interface - something I did not even know existed when I first started writing Duodecad!

For those that are interested I'm going to finish this post with a link to a youtube video I was listening to the other day which I thought was pretty neat. It's a short talk on designing maintainable code by Eric LaForce and I was personally interested in his section on Anti Patterns which I don't hear much about. Basically things that are bad. I identified a few too many in my own code base ;) Have a watch:

https://www.youtube.com/watch?v=EOkyQCQkmXs