This branch implements ScrumDo Story 280. It provides a number of optimizations for grid rendering and state updates. It attempts to do the following:
Only send the full wall state when new players have joined or the walls have not yet been sent.
Only save the full wall state at the start of the game.
Only send the state of food if any food items have changed.
Save the full state of food items once per second (to capture maturity changes) and when food has been added or removed.
Eliminate as many nested loops as possible from scoring and collision calculations on the server.
Replace list lookups for food and wall detection with dict lookups on the server.
Add wall_built message to communicate building a single wall, these messages are stored in the DB and sent to the clients to indicate a new wall needs to be added and avoid sending the full wall state.
Optimize wall collision detection on the client using object lookups.
Generate walls in the client view Section without iterating the entire wall list.
Reduce redundant client Section rendering loops.
Reduce duplicate object lookups.
Ignore ego player position sent by server to avoid random jitter from server state unless tremble is enabled.
Use client timings to determine if motion is allowed on server, since message receipt time on server may be unrelated.
Add client logging of average time between state updates.
Note: It's probably not a good idea to try to make a very large and/or sparse maze using this branch, the optimizations in PR #156 are necessary for maze reliability. That PR is based on this this one, so it can be used for testing both sets of optimizations.
This branch implements ScrumDo Story 280. It provides a number of optimizations for grid rendering and state updates. It attempts to do the following:
wall_builtmessage to communicate building a single wall, these messages are stored in the DB and sent to the clients to indicate a new wall needs to be added and avoid sending the full wall state.Sectionwithout iterating the entire wall list.Sectionrendering loops.egoplayer position sent by server to avoid random jitter from server state unlesstrembleis enabled.Note: It's probably not a good idea to try to make a very large and/or sparse maze using this branch, the optimizations in PR #156 are necessary for maze reliability. That PR is based on this this one, so it can be used for testing both sets of optimizations.