Re-architect System Map to operate on Object Tracks #5607
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
Part one of a general decoupling of the map rendering from game logic. The map consumes a list of Projectables ("object tracks"), but is only responsible for generating and rendering SystemBody tracks for the current system being displayed.
Any external system (e.g. Sensors) can push tracks and orbits into the map to be displayed, including "fake" object tracks (e.g. sensor ghosts, e-war interference, etc.) using a unified interface.
Responsibility for understanding and rendering the contents of an unknown object track is reserved for the consumer of the final screenspace-positioned Projectables. This allows the map to be used in the context of the current game system, rendering cartography data on an unloaded system, or in an editor context.
SystemView is now responsible for only game-related functionality, and the SystemMapViewport is a reusable system inspector which can be used and embedded in various places. - Added surface distance metric to prevent zooming inside of a planet's surface. - Nothing in SystemMapViewport depends on the Pi:: architecture. - Ships and associated orbits are now pushed by the SystemView class instead of the map itself.
Make the system map icon group heuristic a reusable function taking a list of special objects.
|
Sounds fantastic! |
impaktor
reviewed
Aug 23, 2023
|
I keep forgetting we technically still use doxygen. I'll try to write up a long header comment at some point to document the way the map is intended to be used and any gotchas that might need to be avoided. |
I've never seen anyone actually use it. But it's there at least. |
|
Thanks for the documentation strings 👍 |
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 PR redesigns the way the System Map generates and consumes Projectables to allow external systems to push (nearly) any kind of sensor contact data into the map to be rendered and inspected as icons. The SystemView is now responsible for providing the game glue code, while the SystemMapViewport is only concerned with visualizing SystemBodies and operating on the abstract interface provided by a list of Projectables.
This has a secondary benefit of being able to integrate the system map into other contexts such as an editor, in addition to improving the technical possibility of adding additional sensor-based gameplay.
There should be no (or almost no) change to the end-user experience of using the SystemView, but the developer experience is much improved.