Agent Clustering Movement Strategy

[jfgavin]

Objective

Implement agent movement strategy such that clustering is exhibited by Secure and Pre-occupied agent types.

Analysis

Functional Issue

The original lack of clustering is due to GetTargetPosition(), and its movement strategy derived from the position of the closest agent of the applicable social network or cluster. Using this approach results in unlikely clustering, as local pairs will target eachother, and become "pair-locked", where they touch and become static.

Hypothesised Solution

For agents to cluster, they need wider context of agent positions. An initial approach was to use the mean position of the cluster group/social network, however, this commonly targets the grid centroid when any significant number of agents exist.
An improved approach is to use the weighted mean of the cluster/network position. This allows for emphasis of local context (analogous to field-of-view) and parametrised tuning of cluster strength/behaviour through weighting coefficients.

Implementation

All agent types now indirectly utilise the ExtendedAgent method WeightedMeanPosition() to derive a vector towards/away from their social network/cluster group. This vector is now the return value of each agent type's GetTargetPosition() method. Server-side calculation of the "next step" remains unchanged.

Results

See the attached videos for test runs with varying weights for the mean position calculation.

Linear Weight

$$\frac{1}{4\cdot \text{dist} + 1}$$

4_dist.mp4

Non-linear Weight

$$\frac{1}{dist^2 + 1}$$

dist_squared.mp4

Further Improvement

A downside of the new method is that Fearful and Dismissive agent types will seek to avoid the clusters, and will typically move away from the centroid, accumulating on the edges and corners of the grid. This is perhaps less interesting than their previous naive behaviour, where they would sporadically run from neighbouring agents. Using weights tuned specifically for each agent type could improve this, resulting in varying field-of-view, and a more reactive movement style for these agent types.

Other Problems

There are remaining positioning/movement problems outside the scope of this PR, including:

• Superposition: Agents may spawn on the same tile, or move into the same tile.
• Grave-locked: Agents may spawn on a tile fully surrounded by graves/monuments.
• Obstructions: There is no intelligent method to avoid obstructions, falling back on random movement. This results in progressively less intelligent movement throughout game duration.

[MattSScott]

I have to say that, on inspection of the codebase, this behaviour seems to be handled.

The getStep method in the server normalises the movement to [-1, 1] for dx and dy. Any invalid move (i.e., moves out of bounds) will fall back to a randomised move.

I think that you're confusing the intention of getTargetPosition. The agent only supplies a nominal position (i.e., the position they wish to travel in) and the server handles the mapping of this to a dx, dy in [-1, 1]. This was useful for traveling in a direction directly opposite the cluster centre (vectorially)

I therefore don't believe that agents should ever move out of bounds. Let me know if you want to take this further

[MattSScott]

Try and keep a consistent style