When I started developing Ancient Savo I had a handful of core ideas. One of those ideas was to have a flexible modding system with a lot of stuff defined in XML-formatted text files. Another idea was that you can continue playing as your adult off-spring, with an option to send them to establish homesteads of their own. Right from the start I knew that there needs to be some sort of AI to manage the other families of the clan while player is controlling one family.

Based on some of my previous coding projects I had a pretty solid basic idea on how to start developing a system to parse the game items and terrain types from XML. But how to make an AI which can keep a family alive in the game? This is a question which has been lingering around in the back of my mind for a few decades already, and sometimes I've been actively planning and testing different ideas in my mind. On a very general level the AI could be a version of 2D path finding algorithm; you have nodes, and each node can be connected to other nodes, and going from a node to another makes a path - you scan all to possible paths until you find the most favorable one (the shortest, the fastest, or which ever happens to be your criteria). Well, at some point I decided just to start coding, following my old and trusty principle of game development; first code the bare minimum essential core elements of the game, ensure that it is functional, then keep on adding features, and don't we afraid to rework when you realize that this or that feature requires you to restructure some of the existing code.

I'm afraid I've lost count, but I'd guess it is five years since I started to actively develop Ancient Savo. And now, finally, I have all the other essential functionality set up well enough so that I can focus on developing the AI to control a family. And this, once again, made me to reflect on my method of design by coding. I'll try to elaborate a little;

One of the benefits of coding alone is that communication doesn't take time or resources. It is enough to just have a idea in my own mind, and I can start working on it already when the idea is not clear enough to be formulated in flow-charts, class diagrams or sentences of human language. And, indeed - this is what I sometimes do. I've spent some time just thinking in my mind and drawing drafts with pen an paper to think how the AI would evaluate which action to take. But it feels like a too big task to handle all in my mind on a very abstract level. So I go back to the "start with the bare minimum of the essentials", and just start writing code, then run it to see what happens, and then fix it, and then adding functionality to see if I run into problems or if the intuition takes me to the right direction.

At the moment of writing this I don't yet know for sure. I'm at the early stage of having a thing which works, but has obvious flaws and need to be reworked. But I find it easier to design this way - in a way the lines of code are my plans; I write them to see how it works, and then the experience helps me to refine my idea, reworking the code accordingly. I have already learnt that the AI is greatly aided by having the game entities defined in XML. For XML is easily machine-readable; I can just teach the AI to read the XML to build "process trees". It goes something like this;

1. The AI plans to go hunting for big game. The XML for hunting task tells that it requires some tools like skis and a spear. The AI proceeds to check if it has all the required tools.
2. Suppose the AI find that they are missing a spear. So, it goes to the XML definitions to find out how to produce a spear.
3. The XML says that to make a spear you simply attach a spearhead to a shaft. OK, the AI checks if they have a spearhead. No. Then how to produce one?
4. Again the XML tells that to produce a spearhead you apply task FORGE, you need tools bellows, pliers and hammers. The task consumes raw materials iron ingot and charcoal.
5. So, the AI checks the task forge and the XML says that it is only applicable at a furnace. So, again check the XML to see how to make a furnace
6. And so on, traveling the XML node by node until the AI arrives at simple one-step tasks which don't have further requirements

That kind of process creates "a path" comparable to a 2D spatial path produced by A* or a similar path-finding algorithm. Then, of course, there will always be alternative paths, like "go to the market event, barter furs for a spearhead". So, each path needs to be given a relative score based on how much time and resources they take. With such a formula the AI would probably decide that it is easier and faster to barter for a spearhead instead of going through all the steps to construct a furnace and to produce an iron ingot from freshly harvested limonite.

After several test runs with my current algorithm I've started to think about a system where the AI evaluates those alternative paths, and has some kind of book-keeping. Like, eventually it would realize that each and every year a dozen of tasks would require a forge - that would make the AI to add "construct a forge once time allows" to a list of mid-term plans. And then from a year to another always checking if they are in a good position of having enough resources to secure the immediate survival, so that they can pursue mid-term plans to make something which doesn't immediately yield a reward, but will eventually make things easier in the long run.

So, I think what I try to say is something like this; I feel that if I had just kept on planning with a pen and paper, I would still be running in circles not having a full idea on how to design an AI system capable of planning tasks to craft items. If I had to give plans for a team of coders to implement, my plans would be all to vague to be worked on. But in the safety of the solitude I can just get my hands dirty, writing code to see what happens. And that way the big vague problem starts to get a more organizes shape, smaller manageable sub-tasks emerge, and instead of overwriting my plans on a paper I just rework a piece of code and have an immediate access to the new iteration of the algorithm.

Of course this kind of approach can easily lead to an inefficient mess if applied in a group of coders with not enough time to communicate clearly. And also when working alone some coding tasks obviously benefit if there are clear solid plans carefully written down on a piece of paper. As usual, I think we need different tools to solve different problems. To solve a big problem I think in many cases a good productive approach is "design by coding" - you just remember to keep your mind open and be ready to rework a lot of code.

This reminds me of a discussion I had back in the days when I was studying Philosophy at the University. We were discussing the philosophy of science; if there is a solid, reliable, infallible method to establish positive empirical facts. And mr J.Haikonen expressed something like a pragmatist approach, using a metaphor of hand-brain co-operation. That we use our hands to craft tools, and then we use those tools to craft new tools. Often the innovation happens when encountering practical problems in need of new solutions. Or, the point is - the brain alone in some sort of isolated sphere of abstract conceptual thinking easily gets locked in the ivory tower of theories about other theories. And the handcrafts alone easily is just repeating the old patterns. It is the hand-brain co-operation which bears fruit in the form of new creations and innovation. If my memory serves right, at the very moment we all have had a bit too many beers to go through the details of what the metaphor means in the context of philosophy of science.

So, more than 25 years later I think about that discussion. And my own interpretation is that the metaphor applies particularly well in the context of software development. Sometimes (or oftentimes) it can become a burden and an obstacle if you have too rigid method on how to solve problems. Your own presuppositions and assumptions can obstruct an obvious solution. And, obviously, you can't do anything if you have absolutely no idea on how to solve a problem. So maybe start with a hypothesis, write a quick draft even when you already know that your initial idea won't work to solve the problem. But just writing the code and running it will give more feedback for your brain, and it is this dialogue between brain - writing code which can solve problems your brain couldn't handle alone.

Hehe, but it must be said that at the time of writing this I can't yet say if my work-in-progress idea of AI will bear fruit, or if I will stumble into problems I fail to solve, or if some non-coding problems will hinder my development. Such is life. I will be writing more code tomorrow.