# Algorithm Grouping NPCs

## Recommended Posts

Hey folks,

I'm about to start work on a system that involves grouping NPCs located within a certain distance from the player in to cells; eventually each cell may exhibit different behaviors based on the 'mood' of the contained NPCs, although the NPCs themselves will have control over their own position & orientation (so no flocking).

Before I begin work on this system I wanted to reach out and see if there are any algorithms that I should check out with regard to creating the NPC cells.

At the moment my plan is pick a random NPC from a list of those around the player, and search within a small radius (from the chosen NPC) to find other nearby NPCs and create a cell. For each NPC added to a cell I repeat this radius check until there are no more valid NPCs for the current cell. Then repeat the cell creation process for any remaining NPCs in my list of those around the player:

So is that a reasonable approach to take?

Thanks for the advice!

##### Share on other sites

This sounds like a canonical example of where a clustering algorithm would be used. One example might be hierarchical clustering, combining NPCs into clusters, merging them together until the remaining clusters are sufficiently far apart to be considered separate. Whether that is fast enough for your game, I don't know.

##### Share on other sites
On 27.11.2017 at 9:49 PM, Capoeirista said:

So is that a reasonable approach to take?

In principle: yes. Although the condition "grouping NPCs located within a certain distance from the player in to cells" need yet to be considered in the algorithm.

In the following I assume that clustering is a somewhat dynamic process.

If you have many entities to cluster, performance may benefit from temporal coherence. I.e. 2 particular entities that are in the same cluster for the previous time frame are likely also in the same cluster for the current / next frame. However, the benefit will occur only if the sole "is still member" computation is noticeably less expensive than "is new member" computation.

The above thought brings another topic to my mind: Depending on how the clusters are used in the end, it may happen that somehow noticeable behavior swapping in and out may occur. E.g. if an entity moves close to the border of a cluster, then it may happen that it is inside for one time frame, outside for the current, and again inside for the next. Because this entity is itself a seed for clustering, this means that also entire clusters may appear and disappear in a more or less fast pace. So, as soon as the behavior of the entities is computed from the cluster's population, the behavior may alter in the same rate. Something like this should be avoided (e.g. by using a hysteresis for entering and leaving, what again calls for clustering not be done each time from scratch), because it usually looks dumb.

##### Share on other sites

Hey haegarr, Kylotan,

Thanks for the responses - and apologies for the late reply, been out of town for the last week.

I'll have a maximum of around 50 NPCs to sort in to groups for any given frame, so I will probably have to do most of the processing in separate thread. This shouldn't pose too much of a problem though; the results of the clustering don't have to be precises and individual NPCs swapping from cluster to cluster will have a negligible effect.  This system is going to be driving audio events so there are plenty of things I can do to mask any small changes in the data being generated.

I'm not sure I can use a hierarchical  clustering algorithm in this case, as the distance between each NPC from other NPCs in a given cluster is more important to the grouping than the distance from the player... I'm doing a simple radius-around-the player check to find any NPCs within range, and then grouping those NPCs in to clusters based on their proximity to each other.

The clustering is definitely a dynamic process.

Thanks for the advice!

##### Share on other sites

I struggled with a same problem recently.  I decided to create initial groups at spawn since that was when NPCs are guaranteed to be clustered.  Specifically I make a group controller who then spawns the NPCs.  If these controllers periodically update their location to the center of mass of their respective NPCs.  If these controllers get too close, they merge.  If after some merging, the group is too large for calculations (I set an arbitrary limit of 10 simply because of how I'm handling the more complex AI), it gets split evenly and the groups try to split apart physically.

It keeps my calculations low, but as I said, the primary driver was so I could better coordinate small group tactics.

##### Share on other sites

Hey feorang,

Yeah that sounds like a reasonable approach, unfortunately I have zero control over the actual spawning of the NPCs. I have to execute a search around a particular position with a given radius, and operate on the returned array of NPCs. At least I can specify a max count to return though

Cheers!

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account

1. 1
Rutin
42
2. 2
3. 3
4. 4
5. 5

• 18
• 20
• 14
• 14
• 9
• ### Forum Statistics

• Total Topics
633374
• Total Posts
3011552
• ### Who's Online (See full list)

There are no registered users currently online

×