This topic will be documentation about diagnosing the different causes, effects, and potential solutions to lag. Lag, for the contexts of this topic, will either be delays between the server and the player or a reduction of frame rate and thus game speed. For most mods, the information here will not be particularly useful, however, if your mod is demanding on performance then you'll probably benefit.
Tests will be conducted specifically towards mitigating lag within
my own mod. For context, there are often several hundred entities on the field with a lot of animator actions being played. This, of course, results in large amounts of lag and input delay making the mod unplayable in multiplayer during certain circumstances after 30 minutes or so.
Processing Speed
The game time is determined by the amount of FPS a player's computer can handle. If a game is performance heavy and the player's FPS drops then the game time will become slower than real time ex. the game's clock vs a real clock. I don't know what the minimum frame rate is to prevent this but ideally you would want more than 30 FPS.
Netcode
The netcode of CoH2 is, quite honestly, bad especially for a competitive game. In Relic's defense the circumstances that would lead to the specific issue of input delay would be extremely hard to do in vanilla gameplay unless if the player had an underpowered comptuer. Multiplayer games are hosted on a server with no checks for desyncs. The server will always use real time to track the game's progress but players will desync if their frame rate is too low. Desynced players will see a past version of the game. Input delay occurs because player actions are instantly logged but because their game is slower than the server's it appears as if their actions are delayed.
Therefore to prevent input delays we should try to keep mods as performance efficient as possible.
Player internet connection does affect lag but since we can't fix it with mods it will not be covered.
Causes of Lag
- Effects Effects such as particle effects, physics, sounds, etc. will affect performance.
- Rendering A lot of things on the screen at once will cause lag.
- Entities There are many different types of entities with varying impacts on performance. Squads will take up more computing power as opposed to environmental objects like buildings or trees.
- Pathing Pathing, like in most games, takes up a large chunk of computing power.
- AI Because the AI isn't limited by APM it can potentially cause more lag than a player would.
- Other Some other cause of lag such as memory leaks or something not mentioned above.
Of course a game without any of these elements wouldn't be a game at all. Instead we will be testing for how much each of these impact performance and the best way to mitigate lag caused by them.
Setting Up Tests
Because each testing session will be roughly 40 minutes long and because we want reliable results it's best to make testing conditions as consistent as possible. This means removing any random elements within the mod as well as the human element. Within my mod I have random spawning so I'll change the timers to spawn on consistent intervals. I'll also modify the starting HQ to have a make_dead aura to kill any enemies that come near it, this will ensure that AI behavior will be more or less the same every game.
Editing the sight_ext on the HQ to let it have map-wide vision would be useful to make sure that the AI behaves as it should. If the AI gets units stuck from incorrect pathing this may negatively affect the accuracy of your tests.
It will also be useful to log FPS and related computer statistics. I'll be using MSI Afterburner to log FPS and relevant graphics related data.
On the in-game side of things it would be best to have a single map to test on and even a camera location to prevent effects and such from lowering FPS. A map like Hill 400 will be chosen as it's relatively clear with no bridges and sparse buildings. The camera will be placed in a corner zoomed in at max to ensure that rendering will remain consistent.
Objectives & Hypothesis
The main objective of my testing would be to eliminate input lag. Secondary objectives would be to increase FPS rates and improve ai/pathing. As all of these are somewhat interconnected, if I can diagnose and resolve input lag the other objectives should be improved as well.
In my mod the lag is map dependent. On some maps the mod runs as intended, albeit with lag, and on others it becomes unplayable due to input lag. This inconsistency between maps leads me to believe that it's related to AI and/or pathing.
All avenues, however, will be explored to improve performance in general. The results of which will be compiled at the end of the post.
Control Tests & Results
Hill 331
4x Zombie opponents
The first test will be done with the same settings as my mod would be albeit within the confines of our testing criteria.
The Ultimate Resources Gamemodes win condition is enabled on annihilation with 2x resources and 200 popcap. Each session will run for around 45 minutes and I'll average out the data from 3 sessions to give an accurate picture of what I'm dealing with and check for how consistent frame rates are between sessions.
Hill 331
4x OST opponents
The second test will be the optimal baseline for what the game can run at. This is to just ensure that there isn't something inherently wrong with my mod or the game itself. It will also serve as an ideal goal to reach although I doubt I can achieve it.
Red Ball Express
4x Zombie opponents
The third test will have the same settings except on a different map with faulty pathing, at least with my own AI.
Red Ball Express
4x OST opponents
The fourth test will use the same settings as above only on Red Ball Express.
Sittard Summer
4x Zombie opponents
The final test is to check the hypothesis that pathing issues may arise from many obstructions and chokes. Sittard Summer was chosen because of the large amount of buildings and bridges which would affect the amount of routes pathing would need to calculate.
A number of conclusions can be inferred from the results listed in the image above. There is no significant framerate difference between different sessions. This means that subsequent tests can be limited to only one session to give an accurate log of framerate. During the second control test my computer went to sleep because of inactivity, which paused the game. However this shouldn't matter much.
It seems that lag is not dependent on the duration of the game. The FPS for OST opponents are fairly consistent throughout. This point is only a possibility but subsequent tests will check its validity. If true, sessions can be reduced in length to only a few minutes.
Game time and real time delay is dependent on the framerate as previously mentioned. The Red Ball Express has a noticeable delay but since it wasn't multiplayer there was no input delay. The Hill 331 delays may be attributed to me alt-tabbing as this pauses the game.
RAM usage showed no irregularities so memory leaks may be ruled out.
The large drops in FPS from the 30 and subsequent marks are probably caused by units spawned at these times.
Overall these are promising results. The framerates for the OST tests are decent and because they are using the same AI as the zombies, I probably wont have to test different AI configurations which would be rather lengthy. Furthermore, even on these maps with poorer pathing, getting decent framerates should be achievable.
Findings
Initially I was going to document every test that I did but this soon turned out to be infeasible due to the sheer amount of testing required. Below are my findings on the impact that the listed systems have on performance. At the bottom of this post will be a table of some of the tests and their efficiency.
Threat Map
ai_settings\ai_settings_bag\should_update_threat_map
The threat map allows the AI to remember the units its seen after the fog of war has covered them up. This setting both causes large behavioral changes as well as a great loss in FPS. Because the AI on a team all share the same vision, they share the same threat map as well which will tend to cause them to clump units into one area instead of distributing them in their own respective 'lanes'.
Pathing
ai_settings\ai_settings_bag\pathing
This pathing refers specifically towards the pathing section in the ai_settings. Enabling these options will cause a small decrease in FPS as the AI will have to calculate which areas to not go.
Attack/Defend Importance
ai_settings\ai_settings_bag\skirmish_settings\attack_importance
ai_settings\ai_settings_bag\skirmish_settings\defend_importance
These settings tell the AI what to do with their army. They should probably not have identical priorities between the both of them. You should give higher priorities (100+) to what you want your AI to do. Giving your AI non-conflicting priorities will result in a moderate increase in FPS.
I'm not sure if the hq_structure actually works as despite putting it at the highest priority the AI wont send any squads or just a couple squads. To fix this behavior, which is present within the base game as well, you can utilize the defensive_structure attack_importance instead. Having an entity with the defense_building type and a weapon that deals damage will result in the AI sending a couple squads to attack it. By stacking multiple of these onto the HQ building you can have them attacking the HQ directly instead of loitering around resource nodes.
Tasks
ai_settings\ai_settings_bag\skirmish_settings\tasks
These are self-explanatory. The default AI only has at most 5 tasks per option. If your mod uses a large amount of squads it's better to increase this. Increasing tasks will result in a little decrease of FPS but potentially allow for greater FPS overall as units will spread out and have better flow rather than just becoming a massive blob. If there are many squads that move at once this will result in a large decrease in FPS as units often get stuck on each other and have to readjust pathing multiple times.
Squad Loadout
sbps\extensions\squad_loadout_ext\unit_list
The number of entities within a squad heavily correlates to decreases in FPS. Keep squad sizes below 10. One squad of 20 is several times worse than four squads of 5. It seems the optimal squad size would be around 4 to 6 entities.
Win Conditions
Different win conditions probably do not have a significant effect on FPS other than the increase of units that it may bring.
Auras and Modifiers
These seem to have negligible if any impact on performance.
Map
Maps have a large impact on performance. Maps with a lot of assets or incorrect/inefficient pathing will be detrimental to FPS. There's no way to know if a map is laggy or not other than testing it.
Effects
This is mostly pertaining to effects generated from animator_set_action. There is a direct correlation to how many, the type, and when an effect is generated on FPS. Effects only affect FPS when on-screen. Smoke effects seem to be the most demanding. Sounds seem to have a negligible effect on performance.
If you want to have persistent effects, such as something being on fire, it's best to space out when the action fires instead of them all firing on the same frame. For example, an interval_action with a randomized delay is much better than just an interval_action by itself.
Interval Action
The interval_action has a large impact on performance. Shorter intervals result in larger amounts of lag. If possible, intervals should be used with longer duration.
If for some reason an interval needs to be run at every frame use an always_on ability instead. For whatever reason this is much less performance intensive although it will result in a sizable amount of lag.
Requirement Actions
If instant_requirement_check is false it will check every frame as it is described. If a lot of entities have requirement actions this would therefore add a lot of checks per frame and thus negatively impact performance. An example of a particularly heavy requirement is required_near_entity as the executor will have to scan in an area around itself. An example of a lower impact requirement is required_in_state as the executor will only have to check itself.
If you do need to use a high impact requirement you can put it under an interval_action and set instant_requirement_check to true. This enables the requirement to only check once per interval which is much better than every frame.
Targeted Abilities
Targeted abilities have a large impact on performance presumably because the AI has to scan for potential targets. This applies for both offensive and defensive abilities.
Formations
Formations have a small impact on performance. Having entities in flanks are marginally worse than having all of them in the core. Presumably this is because of the additional pathfinding calculations needed to keep the flanks oriented with the squad.
Conclusions
The conclusions reached are by no means concrete as they were formulated from testing conditions. In actual practice results will vary and you'll have to tweak settings to best fit your own mod. Performance impact detailed is amplified simply because of the large amount of squads and entities but should give a general idea of its affects. Below is a list of the above results and the impacts of performance.
In summary, you should strive to reduce the number of requirement checks and scans per frame that the game has to run. AI settings should also be considered if your mod uses AI and deals with a lot of entities. Hopefully the information documented here can help you troubleshoot and solve any lag issues that your mod may have.
By optimizing and removing several of the systems within my mod I was able to get a significant performance increase despite having approximately the same number of entities on the field. The averages are well above the target goal of 30 FPS.
Relic Entertainment
cblanco ★ 
보드카 중대 
VonManteuffel 
Heartless Jäger 
