I’m now back coding and designing Ancient Armies!
To aid with the ongoing development I bought myself a new development machine – A Microsoft Surface Book. This replaces my now deceased Apple Mac Pro.
I chose this machine because I was very impressed with them at my workplace. Plus having the ability to draw directly on the screen is essential for visualising the many geometrical problems that I have to overcome.
The fact that the screen also detaches from the keyboard to form a tablet is a bonus! All in all a very flexible machine!
So what have I been up to so far?
Firstly I spent 2 days designing how I was going to implement column based movement – both on road and off road. I also took additional time to design how movement orders will work for indirect orders – ie the orders you send by herald as opposed to direct command.
This is now all documented and safely stashed away in my Confluence system.
During the code research for the design work, I noticed that a few classes had got a little too big for their boots – yes Game I’m looking at you! As a result I invested some time to refactoring these so as to maintain a high level of code cohesion.
Refactoring is a perfectly normal activity and generally happens as a system evolves and takes shape. You can ignore the need to refactor, but you do so at your peril! The result can be an unmaintainable mess of code.
Although the design work for column based movement is now done, I will not start this new functionality until I have cleared down the backlog of bugs and issues that are still outstanding.
One issue I wanted to sort out straight away, is that I didn’t like the way the system automatically let the user side-slip a formation left or right. So I have modified the system so that the player must now make a conscious decision to side slip. This is achieved by simply holding down the side-slip key (currently mapped to left-shift), whilst issuing the orders.
If the side-slip key is not held down, the system will prevent the unit from side slipping.
In terms of bugs, the first one I ran into was this one:
Believe it or not this is the desert test map, which should normally look something like this:
It turned out that my overall approach to map overlays was way too simplistic. It failed to adequately accommodate the movement of files from system to system.
This bug only got discovered because Windows 10 on my new development machine gave me a different username from my other machines.
On the plus side, the system did fail gracefully – it loaded the map, but sans overlay. It was close, but no cigar!
The new overlay system is now much more robust.
When overlays are added to a map they are now imported into the system as opposed to merely loaded. Of course this in itself is complex as you need to be able to differentiate between images that are new and those that are already imported. Plus the system also needs to deal with the possibility that two different overlays may well have the same filename…
However, don’t fear! This has now all been taken into account and the system has been thoroughly tested.
So what’s next?
As mentioned above, I want to clear down the backlog before starting on the column movement functionality. There is a fair bit of work in there and I can see it potentially occupying a fair bit of my time.
If the bugs I’m fixing are relatively interesting, I will put up blog posts up about them. If not, you will probably hear from me in a few weeks time when I will declare that the backlog is empty!