Simplified movement logic in the GSP #145
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The new function checks whether or not it is just a principal direction (although perhaps multiple unit steps) from one coord to another. This will be used in a simplified movement code.
Instead of spacing the waypoints by their distance (using the wpdist argument), space them such that there is a principal direction between each pair of waypoints. This is what the GSP will need after the next change, which will simplify the consensus-relevant movement code to not use path finding itself.
This adds a new helper method to the Character class in the integration tests, which does a findpath call to obtain the path towards a given target and then sets it as waypoints. This decouples test logic that just needs to do some movement (without caring about the real specifics) from how the waypoints need to be specified (e.g. in principal directions).
This revamps how the consensus-layer movement logic works in the GSP: Instead of doing path finding in a local range, we expect the waypoints to be set in principal directions from each other (but with arbitrary distance). Then we simply try to step along that path. This implements the idea described in #135 and will make movement processing (which has been the main bottleneck in the past two competitions) much faster in the consensus code. (Path-finding still needs to be done, but only client side to come up with the waypoints to send in a move.)
domob1812
added
game
domob1812
added a commit
that referenced
this pull request
Jul 7, 2020
Simplified movement logic in the GSP
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements the changes to movement logic suggested in #135. Instead of doing path finding in the GSP, waypoints set in moves must be in one of the six hex principal directions of each other, and then the GSP just moves along that straight line.
Related to this, the character gamestate JSON object no longer holds the
steps, as they are not needed anymore. ThefindpathRPC method has nowpdistargument anymore, and instead outputs waypoints such that they are in principal directions rather than with a certain spacing.This change should have only a minor impact on gameplay, but it shifts path finding entirely to the client (one of the effects is that paths will not be planned around other characters, while they previously were to some extend; only when the blocking characters were stationary, though). It improves movement performance by about 4x according to the benchmarks, which should greatly help wtih syncing performance (the new bottleneck of movement code is now the database update for moved characters).