Devblog 22: Making Flocking Great Again

Month Eleven

This month Jamie and I were working together to make the terrain creation logic network ready. We encountered various problem which are typical of game development; the player intuitively expects everything to behave sensibly, but each sensible behaviour is actually a collection of many little pieces of logic which have to be strung together.

When it came to the question of how exactly do units create new terrain, the answer had to involve code to tell units to flee from the construction site before any work can begin. And that fleeing behaviour must itself be intelligible, units must flee the shortest distance to the nearest available safe space.

With Jamie left to mud wrestle network code, I returned to flocking. The most obvious issue was that groups of units suffered from jittery movement when they were close to an obstacle, be this another unit or a wall. The solution was twofold.

First, the order of execution changed, so that groups are ordered by distance from the destination, and then moved in that order. This increases the odds of units moving in the right direction, and thus moving with less jitter. If a group is told to move and a unit in the middle moves first, this causes problem because there is no space to move into. Second, after units have been moved by the flocking algorithm, their position is adjusted. This adjustment ensures that any movement into an obstacle is corrected immediately. The result was that jitter is less and group movement is smoother.

Another concern is ordering the impossible: when a player tells units to move to somewhere inaccessible. This could be because the player has told their units to move inside of or on top of a space they cannot reach, because there is no doorway or ramp to access that space. As it was, such an order would break the code.

The solution was to implement another part of Elijah Emerson’s flow field design. The map is composed of square sectors, but not all sectors connect. For example, if a player creates new terrain, the sectors on top and inside are inaccessible from the surrounding terrain. Each inaccessible group of sectors is stored as an ‘island’. Islands provide a useful metaphor, and enable much quicker searching to find the next best location units should move to.

Traffic jams also existed. The naïve solution is to find the fastest path to the destination, which works fine for individual units. But for groups this falls apart, because units begin to snag on corners, limiting the number who can move around a corner simultaneously. If the terrain didn’t have sharp edges this may not be a problem. The solution is to force groups to path down the middle of sectors, thus for the most part avoiding edges and traffic jams.

One of the last obvious additions will be to add a line-of-sight (LOS) pass to the process. This ensures that if the goal can be seen, then the unit will ignore the flow field completely and aim directly for the destination, which is the most optimal outcome. In order to efficiently calculate LOS Bresenham’s line drawing algorithm is required.

If all goes well, next week pathfinding will be relatively complete, and Jamie will have done the same with networking. That should put us in a good position before the two week Christmas break, prepared to begin the new year with refreshed enthusiasm.