Hello,

A while back I read a book called Domain-Driven Design: Tackling Complexity in the Heart of Software. The main message of that book is that the true goal of software is to model a real world problem (that is a domain) in software. It sounds obvious but the problem is that software is abstract. It is easy to get lost in the ifs and loops and end up drifting away from the problem at hand. Let’s consider chess - it is similar enough to Lords of Illic after all. We have pieces on a board, two players and squares. The chess set has been honed over many years to be suited to the game that we play with it. For a moment though let’s consider a different chess set. A set where each piece looks exactly the same - there is not even any difference in colour between the two sides. Of course to play chess we still need some way to distinguish a piece from each other. In this chess set the only difference between the pieces is a three digit number on the bottom. The set comes with a table which says which number is which piece.  For example 352 is a black rook but 567 is a white queen. This set has everything you need to play chess, but in practice you'd be unlikely to finish a game. This particular chess set has a clear mismatch between the ideas of the game and how it is “implemented”. It is not modelling the concepts of the domain well. In chess it is important to be able to evaluate the state of the board at a glance and to be easily able to distinguish which piece is which - each one has its own rules after all. This example may seem a bit unrealistic, but one advantage of a physical medium is it has a lower tolerance for this kind of mismatch. On the other hand, code is abstract. A bad implementation of chess could appear exactly the same as a good one. We have a lot of spare computing power and if your game is fun and its bugs are not too bad people will play it. Since this kind of mistake can easily be tolerated it is very common in the games industry. Good engineering practices such as Test Driven Development could help fix the problem but games which use TDD are few and far between. I can’t claim however that Illic is a paragon of virtue - I've had a lot of large mismatches in Lords of Illic - usually involving UX and UI which I've talked about in the past. Recently I have uncovered a large mismatch in Lords of Illic’s core.

In chess there are pieces controlled by two players who are limited by the rules and play on a board. Thus we need to model the players, the pieces, the rules and the board. In Lord of Illic each piece (or character) on the board is represented by a class I called Agent (and one I usually refer to as a unit just to be confusing). The idea is that you ask an agent to move to a tile and attack. This doesn’t sound so bad, but we do not ask pieces on a chessboard to move to a space and we don’t ask them to defeat an enemy in that tile. We pick up the piece and put it on the space we moved to. The method I picked works after a lot of hard work, but it makes it harder to test and hence harder to extend. The Agent is not a pawn which does what we ask, but instead thinks a bit about it, does some checks and then maybe does something. This mismatch is not a surprise for me. Back when I first started making Lords of Illic I was a student and I was most definitely NOT thinking about a game as a domain that needs to be modelled. I was working on intuition as I tried to puzzle out the problem at hand. I think I did a good job based on what I had at a time, but from the beginning something has always bothered me about my solution. I have revisited these basic assumptions time and time again thinking that there is something I am missing. 

Now I am going to diverge from my original topic and conclusion. When I first wrote this entry I had a very depressing conclusion about what all this meant for Lords of Illic. Earlier this year (or perhaps last year?) I read a book called “Working Effectively with Legacy Code” - a book that gave me the tools to work with gnarly code which can’t be properly tested. Thus my conclusion was that I could use techniques from the book to fix the issue but it would be incredibly difficult. However that night (or possibly morning) when I was half awake the solution appeared before me. I could see all the steps I needed to refactor to pull the combat code which had originally been at the very core of Illic up to next to the player option. What this does is make combat an object which is controlled by the player. Perhaps this sounds a bit strange but in a game of chess the rules are fixed and the player has to make moves within those rules. The player and the rules are separate concepts. This just leaves the agent to just tell combat to proceed when it is in position and then when animations are finished. And as it turns out I actually could fix the issue exactly as I envisioned and in one afternoon! (Which isn’t strictly fair because it was actually the culmination of a long term project where the code has been migrating from the Agent to the Player object). After all these years I am finally able to see the solution to the problems that I agonised when I first tried to create Lord of Illic. My intuition back then was that the way I was separating the code was wrong, but it took years of reading programming books, watching videos and general research to put my finger on the problem. So rather than lamenting I think I should be happy. It shows how much skills have grown in just five long years.

Why did I need to fix this problem you might ask? Couldn’t I just polish the game and be done with it? Well perhaps that was true, but I wanted to fix an exploit in the game. That is if you restart your turn you get different random numbers. Without combat being controlled in a singular location it is very difficult to fix - now combat is centralised in one place it is quite easy. It would also allow me to record the random numbers if I wanted to store and replay battles - an idea I have been rolling around in my head for a couple years now. Either way it feels good to solve a problem with a burst of insight.

Until Next Time.