Month Eight

For strategy games, with potentially hundreds of units running about at once, nearest neighbour searching is a non-trivial problem. This is when a unit must check who its neighbours are as efficiently as possible to make decisions about movement and combat.

If there are only ever going to be a handful of units in the game at any one time, then a linear search is probably fine. A linear search is when code examines a list of items, one by one, until it finds what its looking for. This is fine for a shopping list, but not necessarily for checking hundreds of units multiple times a second. If 100 units are checking 100 units every time, that’s a lot of checks!

To investigate, I created 300 units, noting frame rate as a heuristic for code performance. When collision detection was switched off the simulation fluctuated around 90 Frames Per Second (FPS). Not bad. However, when collision detection was activated, using a linear search, this reduced the frame rate to 10. Clearly something had to be done.

The ideal solution is spatial partitioning, using an octree. This means that the game world is encompassed by a huge box (octant), and that box contains eight smaller boxes, and each of those boxes is divided recursively into eight more, etc. Each octant logs which units are contained within, adding units when they enter the box, and removing them when they exit.

This solution allows recursive searching up and down the tree, to find the boxes relevant to the space being searched. This is especially powerful with a dynamic octree, meaning octants only exist where units exist, significantly reducing the number of octants that need to be searched. Instead of checking a three hundred item list, we just check the contents of a dozen or so boxes.

In the below image octants are visualised using cyan and magenta. The dynamic octree must prune itself, and so when an octant has no units inside it is placed on a list of vacant octants. Vacant octants have a timer, and after a few seconds of disuse are deleted. This ensures the octree never gets too big, and allows octants to be reused where units are most likely to move again.

The proof is in the pudding. But in this case, the pudding is code, and the metaphor is broken. Regardless, it shouldn’t be hard to improve upon a measly 10 FPS. The octree was applied to all unit movement and combat neighbour checks. The latest results are as follows:

1 unit 270-280 FPS
10 units 250-260 FPS
100 units 130-160 FPS
200 units 90-110 FPS
300 units 70-80 FPS
400 units 50-60 FPS
500 units 30-40 FPS

These figures can undoubtedly still be improved, and they demonstrate the efficacy of spatial partitioning, compared to a naive solution like linear search. The octree also provides the foundations upon which a deterministic raycaster can be built.

One optimisation has been to sort units inside octants by team, and to push those lists up the tree recursively. What this means is that units searching for nearby enemies may only have to check up the tree, until they find the octant which encloses their maximum range. If there are no units belonging to a hostile team inside that octant, then the search is resolved. The alternative is suboptimal: to move up and then down the octree, searching every unit in every octant for whether they belong to a hostile team.

Month Seven

Last month a pathfinding solution was created. This month a Flocking solution was required. Flow Fields generate a route from A to B, but this doesn’t tell us how units should move along that path in relation to each other.

Flocking was first coined by Craig Reynolds in 1986. Simply, flocking algorithms enable moving agents to adjust their heading relative to nearby agents. The agents are referred to as “boids”. Legend has it that flock agents are called boids because this is how birds are pronounced with a thick New York accent.

The bespoke modified flocking algorithm works to an extent, though it still needs refinement. In the below image we can see both a group of boids moving past obstacles to get to their destination, and what this looks like from a pathfinding perspective.

In other news, I am delighted to announce that Norn Industries has hired its first employee. I have never recruited anyone before, so this is a bold adventure for both of us. I am excited and confident that together we are in a much stronger position to deliver the best possible product. Two programmers are better than one.

Month Six

This month has been consumed by automated testing and pathfinding.

It is difficult to create units which are unique and balanced. This is important for a multiplayer game, and being a solo developer I have to make tools to test the design assumptions I have created.

In generic software development automated testing allows programmers to quickly check their code is returning the right data. In an environment as complex as Real Time Strategy games, where soldiers navigate a 3D environment in real time, there are so many variables to consider, that the only way to investigate is to run gladiatorial test matches.

I created a user interface to easily customise tests. Each test places a number of units at either side of a small map. The number is determined by their cost (value). The units immediately rush to attack the other team, until one side has none left. The code then calculates who has won, and by how much, and saves that to a text file. This means I can run hundreds of tests overnight and examine the results in the morning, providing a rough measure of whether a unit type is too strong or too weak.

In any game it is unlikely that battles will just be between individual units, so each test creates multiple units, and places them at random locations. Each pairing is then repeated a number of times to provide an average result, which should be more accurate.

Pathfinding has been something else. The old system generated one path per unit, which clearly will not scale if hundreds are involved. Instead, I followed the Flow Field design described by Elijah Emerson, published in ‘Game AI Pro’.

Each map is divided into sectors, which contain tiles. Sectors connect to other sectors via portals (green dots, white lines show connections). Red lines show the flow fields themselves. Each tile has a direction, and when units enter that tile they read the direction they should be facing.

The path visualised above shows the directions five units from the top right must travel to arrive at their goal in the bottom left. Each unit starts in its own sector. But there could be five or ten units in each sector, and yet the cost of generating the path remains the same. The advantage is a considerably more efficient means of moving large groups from A to B.

Initially, it took as long as 100 milliseconds to generate a path for one unit moving along that distance. After some optimisation, the worst case was reduced to 1.5 milliseconds.

Month Five

This month, good progress.  Environment art is ongoing, marketing research is complete, and new features are implemented.

The terrain system has been reworked, and the player can now edit individual walls.  There is new a query button, which allows the player to mouse over a unit and see basic information.  The healthbar has been implemented, with new and old styles to choose from.  There’s also a new charge button, which allows the player to order a group of soldiers to launch into melee against the nearest enemy.  There have been many other fixes and much refactoring besides.

I have also been consulting with friends who play strategy games, to try and get a feel for how to implement unique factions.  How many will there be?  How will they be different?  What narratives will guide them?  These questions have been answered for now, and there will be four playable factions, each with a unique identity and distinct mechanics.

The next deterministic problem to resolve will be replacing Unity’s non-deterministic Raycast system.  That will be non-trivial and expensive, but once complete there won’t be too much left for multiplayer to be viable.

A raycaster is an object which creates an imaginary line from A to B, and then checks if this line intersects any triangles (geometry in the game world).  This is used to determine if units can see each other, and if projectiles have impacted walls.  In principle, not too complex.  But the problem is efficiency; the geometry in the game world must be saved so that only the closest objects are accessed.  For example, one such design pattern is similar to a tree data structure, and is called binary space partitioning.  Doing all that well is non-trivial.

Month Four

Perhaps the worst possible fate is a failure of imagination.  While mood varies, that range is usually not debilitating.  Unfortunately, I have brief and recurring periods of destructive lows.  These moments induce a complete failure of imagination, as the strength of emotion is temporarily drained.  This manifests either as a temporary loss of positivity, or a tactical victory for negativity.  Something is either missing or too much.

These moods are like stormy weather.  They come and go, and there’s only so much that can be done while there’s a storm howling outside.  For J.K. Rowling, depression was best explained by the metaphor of the Dementors from Harry Potter; soul-sucking monsters which drain all happiness and energy.

The immediate impact of such feeling is a lack of motivation.  All confidence is absent, and an uneasy distinction emerges between rational and emotional modes of thought.  It is possible in such a state to pause and logically deduce the absurd dysfunction, and quite possible to reason that this feeling isn’t realistic.  But it’s impossible to feel that.  And without feeling there’s no doing.

So that’s partly why there wasn’t a Month Three blog entry.  Another reason is that things always take longer and cost more than one anticipates.

The bad news was that work on deterministic code for the game’s multiplayer hit a wall.  The type of mathematical knowledge necessary (quaternions and four dimensional matrices) was beyond me.  I was lucky enough to find a freelancer who does have this knowledge, and is almost done working on that most essential task.

Concept art has also come a long way, and both characters and weapon explorations have been completed.  Today work begins on environmental concept art, soon the characters won’t be abstract entities disembodied from space-time.

The pause from programming has provided fertile soil for new thoughts, as the terrain and base building systems have to be refactored anyway.  This creates an opportunity to iterate ideas, making the final implementation even better, and to give players more dramatic choices.

Determinism has always been the biggest technical challenge, but progress is being made towards resolving this travesty.  When present deterministic challenges have been resolved (there will be more) work can resume, and focus will be on terrain and base building systems.

Refactoring unit code was a success, and has provided a foundation for further development.  The next tasks will include (in no particular order): computer player intelligence, group unit movement, art integration, fog of war, and GUI concepts.  Combat and networking have already been implemented, but will need more work too.

So there’s cause for optimism.  In the meantime, I’ve been reading Gerald Zaltman’s ‘How Customers Think’.  Like Daniel Kahneman’s ‘Thinking, Fast and Slow’, it is an invaluable book that is unfortunately something of a slow read.  I hope the book will help me to better understand the desires and needs of players as I design game play and direct art.