A Post-Mortem on Age Of Gatherers




This project was a 5-week project that’s of an AI environment, the goal of this project was to demonstrate the ability to implement a variety of features (Those features being: Pathfinding (preferably AStar), Obstacle Avoidance, Procedural Generation and Group AI Behaviours) All of these features were areas that I hadn’t previously worked with. In this project, I manage to get all of those features implemented, make something cool and learn a lot in the process. In this post-mortem, I’ll be detailing the development process.

Planning/Designing The Project

Since the project was filled to the brim with stuff I've never done before and wouldn’t know how to implement, the first thing I did in the documentation was just outlining some ideas of how I wanted it all to work once the project was completed. 

I listed out the behaviours I wanted from the agents, I then listed how I wanted my terrain to entail and look like and then how my agents would path through this terrain. Later on, I’d come back and start to detail the more technical aspects once I did some research and/or tested an idea. This process was helpful in deciding what things I wanted in the project but it wasn’t much of a document that I could fall back on and read when I come across something in the game that I didn’t know how to do.

I’m getting over having to program a project without planning it out fully in the tech spec, it ends up being a document I never open during the project (other than to update it) and because of that my code suffers for it. I need to first put more effort into documentation. Documentation isn't completely useful on a small scale project (it’s useful for understanding all the elements in the project and finding elements you didn't think of during brainstorming), but as I start to take on more ambitious projects that take longer to complete, I need something to remind me what I exactly want in each section of the project; I need something I'm able to reliably open up when I have questions about the project.

What’s stopping me from achieving this is the unknowns in the project and I don't know where I'm even going to start with implementing them in project until I'm in script (as soon as I’m in front of a script I know where to start but in front the tech spec I'm lost).

I need to start approaching planning in different ways, maybe start scribbling thoughts and ideas onto paper and if I think that might do it, I’ll get it into the document. I also should try approaching my thought process of planning differently (at the moment I just think of ‘if I was programming this, what would I try?’), I should try breaking it down a bit more, maybe I should write down my goal and a list my potential actions that all achieve this goal and chose the most effective one.

What steps I need to take moving forward;

  • Put more effort into documentation by putting in more detail and linking or implementing notes on the research of the topic and making sure I get it done moving forward.

  • Try scribbling rough ideas onto paper.

  • Take a more detailed approach to find solutions. By breaking down each potential solution to a problem to find the most effective and efficient solution.

Pathfinding Implementation

The process of finding paths for agents was relatively straightforward on a flat plane. The issues came with getting the pathing to work on the generated terrain. I didn't have a detailed tech spec to fall back on but I did do a bunch of research into the subject to get a grasp of how the A-Star algorithm works and how I might go about implementing.


The use of researching and familiarising myself with the A-Star algorithms was a helpful process that made the implementation a breeze. My only issue here was that I very much should have written the research down somewhere rather than relying on my memory to implement it effectively.


I also had an issue with the node generation for the pathing. They ended up being an easy fix, but thanks to a lack of structured planning I was making stupid mistakes when trying to get two tools that worked perfectly together on their own but when I tried to merge them together It was a mess.


In the future, I should definitely get my gathered knowledge down in a document to both make the implementation process better and it would be something valuable to return back to and read.

What steps I need to take moving forward;

  • Write down my research findings.

  • Plan my code out more through laying out what exactly I plan on making in a tech spec and from when I start to code it I need to comment what I want a function to do before I write etc.

Terrain Generation

The process of implementing the terrain generation was smooth and straightforward I made use of researching other implementations and implemented based on those and got the base of the terrain generation up and running quite soon.


The thing that got away from me in this section of the project was the Inspector for the tool for this terrain generation. After iterating how the objects generate multiple times the inspector for the tool started to get quite lengthy and confusing to people that see that haven't made it themselves. This was made very evident when a friend of mine, Ben Phillips, wanted a terrain in his game and didn’t want to go through and manually implement everything so I offered help and showed him my terrain tool and tried explaining how it works that didn’t go well so I just gave him the script and he gave up on it and went with the manual option anyway. This was because of how the inspector is very filled with variables to change that had horrible and rushed names, I made no use of things such as tooltips, headers etc, to help whoever is using the tool. Although I knew everything that each variable did and I made it work quite well with my project, but when handed off to a different project it's hard to get working.


In future, I need to both take my time on planning how I'm going to make scripts with how they’re going to work as a tool in mind.

What steps I need to take moving forward;

  • Plan how I’m going to make the tool useful

  • Make sure to keep the use of potentially foreign terminology to a minimum, in hopes to not confuse the user.

  • I need to make use of requiring components and making them when the user doesn't have one.

  • Do more custom editor stuff, because it’s cool.

AI Behaviours

When planning the project, I knew that I wanted to make use of goal-action-oriented-planning (GOAP) for my agents because for one, it was something I've never done before and I wanted to try it out and through research of the topic, it interested me. I also thought that the use of GOAP could lead to some interesting behaviours coming from the agents - with the use of GOAP I can easily layer on actions onto an agent and hand it a goal and they then do plan what they think is the best plan, and this ended up being the case.


When constructing the system after a rather large amount of reading articles and looking through example implementation of GOAP, I didn't create a simple error catching system which leads to some bugs that were time-consuming to handle.


With my GOAP system actions, goals, effects and preconditions are being passed around a lot and if it breaks it returns to the same function and sends out the same error that doesn't really help. To get to the bottom of each issue I had to debug and step through the system which can take awhile. Having a complex debugging feature to go along with the behaviour system would have made the process of adding each behaviour a lot smoother.


On top of that, I should have taken the time with this system especially to comment as I went. During the creation of GOAP system, I wanted to get it up and running as quick as possible and I didn’t write comments on most of the scripts that when into this system. Because of this and how large it was, it was hard to rely on my memory of how it worked - I quickly forgot what scripts did what and how. This all leads to me not knowing why certain things were happening in with my behaviours and during those long debug sessions I had to re-remember/figure-out multiple times what script, functions etc were doing to help get to the bottom of my bugs.

What steps I need to take moving forward;

  • Comment code (the complex stuff at a minimum).

  • Take the effort to identify what areas that have a lot going on that you can't really see visually and make debug systems that help see them visually to help with debugging.

Obstacle Avoidance

The obstacle avoidance system in this project wasn’t a complex one. I thought I would, at least for now, just use potential fields for the avoidance of just other agents for now so that the humanoid agents don't collide or run through each other. Later I would like them to avoid rocks and trees etc, but just the agent was good enough.


The main issue I had with the obstacle avoidance itself was just that initially, I had them moving toward each other rather than away - this was because I didn’t think out the code enough I just wrote it and thought it would work, and it didn’t. I need to check my code makes sense and plan it out through documentation or through commenting the code. Typically in similar scenarios, after writing code and I'm not sure if it makes sense or if it will work, I will step through the code and write down as a comment what each line of code dose before compiling it.


The other issue I had with the avoidance wasn’t the code but rather how I had the spawning set up. I had the agents spawning upon the generation of the town hall all on top of each other and when I added a rigidbody and a collider it sent them flying, I initially thought this was the cause of the obstacle avoidance and was super confused.

What steps I need to take moving forward;

  • Through planning in documentation and commenting on the script to help think more about what I'm going to write. Once I have a certain idea of how it’s going to work and what it is going to take to make it - I then should start actually writing the code.

Director AI

This project was being produced ahead of schedule and that meant I could add in some bonus features, this includes a director AI that lets the agents know if they should switch to a berry gatherer or a wood gatherer, and later I can make the switch to other roles.


Initially, with this system, I started out by trying to calculate the average gathering of berries and the average consumption. To get this working I had to calculate stuff like the average distance to every berry bush, the average appetite of the agents and from there increasing and decreasing the spread between the berry gatherers and wood gatherers. This system was, I think, close to completion and I decided to go ahead and switch to a simpler system which would make use of animations curves of which I was looking for an excuse for the past few months to use and learn them. So I scrapped the old version and started a new.


This new way of doing it was quite simple, I calculated a few things including; the per cent of gatherers that are berry gatherers and the percentage of how full the berry storage is. From there I set up and animation curve that had how much in a percentage I think the split between berry and wood gatherers should be at a certain storage capacity and when a gatherer finished a goal, it asks the director AI if it should switch to the other gathering role and if it should.


Although the more complex system would have been a more robust and accurate method, it would have been a hassle to balance with all of the variables. I like how I saw an opportunity to learn something new and useful in game development and took the opportunity.

What steps I need to take moving forward;

  • Keep making more decisions like these to learn new and/or challenging things.


In conclusion, I have a bunch of skills that I need to refine for future projects and get a start on that in the next project