Perf impact of libcampaign and group management

For porting of the campaign to javascript discussions
Post Reply
User avatar
Berserk Cyborg
Code contributor
Code contributor
Posts: 663
Joined: 26 Sep 2016, 19:56

Perf impact of libcampaign and group management

Post by Berserk Cyborg » 03 Nov 2018, 21:43

The group management of enemy units is kind of... intense. Even for one group. It's probably the worst part of the campaign library in terms of performance and can cause stuttering in Warzone. A good test case to see this with is on the Alpha 7 mission (defend the plateau). Now, this is not something most people would take notice of with normal gameplay (unless there are lots of groups), however setting game speeds at 10x+ will reveal it clearly by watching the mission timer at those speeds.

In __camTacticsTickForGroup() there are three areas of suspect for this:
1. Regrouping logic.
2. Target choosing (__camPickTarget()).
3. the large for-loop and the end of the function.

1 and 3 seem to be the problem areas. 2 does not seem to have much of an impact as the others and can easily be cached and throttled over a few seconds without affecting the groups much.

I have tried throttling each of those areas for a few seconds and it does help to an extent, but I observe moments of smooth gameplay followed by a repeating hiccup that becomes more and more noticeable as more groups are made. :hmm:

Once I did a test where I replaced the cluster analysis with a super simple group average and a distance check from that average. It emulated the cluster analysis well enough for me to conclude that the cluster analysis is a big part of the problem, but still I saw that hiccup albeit not as long lasting anymore.

So, the performance issue lies mostly with the cluster analysis and that for-loop. Or it's somewhere else and I am missing it, but I think I have it pegged down to those two areas.

Regrouping
Cool in theory. In practice, it does not seem viable... at least for now, so I seldom choose to enable regrouping. I have observed some weirdness with it, though. Commonly, I see an issue where "close but far to path" coordinates are chosen for the regrouping point (think: group is very close to the bottom of a hill and now some units must move to the top of it which takes minutes to get to).

Other times I have seen it get defeated due to the coordinate where the group is supposed to regroup at is unreachable (pits and mountains that nothing but a VTOL could get to, water tile where the group is land only propulsion). Thus causing the whole group to remain motionless forever until something forces some of the units to move elsewhere.

Alpha 7.zip
(54.58 KiB) Downloaded 12 times

User avatar
NoQ
Special
Special
Posts: 6204
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: Perf impact of libcampaign and group management

Post by NoQ » 24 Nov 2018, 11:05

Clustering code is copied almost without change from NullBot. I spent a huge amount of iterations before coming up with the current regrouping algorithm and i doubt it can be simplified significantly for the purposes of a general-purpose AI, but it can probably be simplified significantly for specialized groups in the campaign.

The main problem with the group's average coordinates method is that it makes the whole group retreat back to base for a short time whenever a newly produced unit is added to the group. It is just one unit, but it is veeery far away, so this is enough to cause the group to be completely unable to move forward as long as new droids keep being added. So, for instance, if no new units are being produced, group average coordinates is a good enough clustering method. It is also fine when a factory produces death squads that are replaced rather than reinforced. But when a group is being continuously reinforced from a factory, a good regrouping method is essential.

Moving the cluster analysis (or some other formation code) to C++ is definitely an option.

The large for-loop can be separated into smaller loops for small chunks of the group queued into different game frames in order to avoid stuttering. There are probably a lot of actual optimizations that can be implemented there.

Post Reply