This is actually two entirely separate problems, but the good news is that there is an easy fix for the first part and an intensely difficult and technical fix for the second part!
There is already a switch in the engine to turn off animation, although I am not sure how it was meant to be toggled originally. It would be relatively simple to add a button to the settings panel for that.
The pause you see during the AI movement selection is actually a much harder fix because that is actually how long it takes for the AI to choose a move. There are several causes:
1) every AI unit performs a check of the current and predicted future positions of every other object before choosing its maneuver. So if you play 2v2 with 6 asteroids the AI ships each check 9 positions and 3 future moves (or 24 checks), but if you play e.g. 6v6 that shoots up to 17 checks each ( or 102 checks total). And each predictive pass on another ship runs a number of position checks itself.
2) The positional checks are naive, redundant, and un-optimized - not to denigrate the work of the original Dev, it's better to get things working before optimizing code. But these checks call the same code used to see if bases overlap, which means checking four corners at a minimum for every single possible position. And some of those checks also check for collisions even if all we need to know is whether it would be on or off the board.
3) the geometry checks all utilize Snap.svg calls. I would assume Snap.svg geometry code would be highly optimized for speed, but I have no idea if we're using the right calls - there may be opportunities to have Snap.svg do more work for us, or we might write our own WebGL-accelerated functions that trim some fat to get maximum speed. I honestly haven't investigated this yet, and I don't think anyone else has either.
1 can be solved with partitioning, caching projected moves, and some vector checks. No need to worry about an asteroid that is too far away to collide with, or an enemy that is flying away from your back quadrant - at least as far as collisions go.
2 means doing faster center point-center point checks first, and using bounding circles, and any number of other multilevel optimizations from 2D game engines.
3 means leaning a lot more about Snap.svg and running some tests, but I do have some existing code that I might be able to implement quickly if it turns out Snap.svg is not the fastest code.
This is actually two entirely separate problems, but the good news is that there is an easy fix for the first part and an intensely difficult and technical fix for the second part!
There is already a switch in the engine to turn off animation, although I am not sure how it was meant to be toggled originally. It would be relatively simple to add a button to the settings panel for that.
The pause you see during the AI movement selection is actually a much harder fix because that is actually how long it takes for the AI to choose a move. There are several causes:
1) every AI unit performs a check of the current and predicted future positions of every other object before choosing its maneuver. So if you play 2v2 with 6 asteroids the AI ships each check 9 positions and 3 future moves (or 24 checks), but if you play e.g. 6v6 that shoots up to 17 checks each ( or 102 checks total). And each predictive pass on another ship runs a number of position checks itself.
2) The positional checks are naive, redundant, and un-optimized - not to denigrate the work of the original Dev, it's better to get things working before optimizing code. But these checks call the same code used to see if bases overlap, which means checking four corners at a minimum for every single possible position. And some of those checks also check for collisions even if all we need to know is whether it would be on or off the board.
3) the geometry checks all utilize Snap.svg calls. I would assume Snap.svg geometry code would be highly optimized for speed, but I have no idea if we're using the right calls - there may be opportunities to have Snap.svg do more work for us, or we might write our own WebGL-accelerated functions that trim some fat to get maximum speed. I honestly haven't investigated this yet, and I don't think anyone else has either.
1 can be solved with partitioning, caching projected moves, and some vector checks. No need to worry about an asteroid that is too far away to collide with, or an enemy that is flying away from your back quadrant - at least as far as collisions go.
2 means doing faster center point-center point checks first, and using bounding circles, and any number of other multilevel optimizations from 2D game engines.
3 means leaning a lot more about Snap.svg and running some tests, but I do have some existing code that I might be able to implement quickly if it turns out Snap.svg is not the fastest code.