New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add fog of war to the patch map #4462
Conversation
The basic implementation of this has been completed, including a cheat to reveal the entire map. However, I'm still unsure about it aesthetically. Currently, the map looks like this: I don't know whether or not to include region borders with regions that only contain unknown patches. If I leave the borders, players will know how big neighbouring regions are before actually entering them, however, without the borders the patches look very disjointed from the rest of the map. |
I'd leave out the region border, like as you said otherwise the player will see the size of the region without having explored it. |
I think this is ready for review now |
Seems to work perfectly well with no appearant errors. Excellent job! I love the mystery that this provides, and the risk of entering an unknown patch to figure out what conditions are present makes for interesting gameplay. In the mean time, I'd say this is good to go as is, though it may be helpful to implement a toggle for this feature. |
I was going to suggest a toggle in the new game settings as well. For something like this, I think that is pretty critical. |
Regarding the problem of this not updating when loading a save on the map screen, I can't immediately tell what has gone wrong. Next I'd need to use a debugger to see what's the normal map update and rendering flow (using breakpoints) and then compare that to what happens when a save is loaded. I'm pretty busy so I'm hoping someone else can do that. I'll help out there as a last resort. My guess as to what is wrong is that the editor tab swap logic is slightly flawed when loading a save which hasn't been a problem before but now with these changes is a problem. That's where I'd start investigating if the method call sequence when normally swapping tabs and when loading a save match or not. |
Co-authored-by: Henri Hyyryläinen <henri.hyyrylainen@gmail.com>
…nto fog-of-war
I have managed to fix that one edge case I mentioned, where now multiple connections between the same two regions will be accounted for when creating paths. However, the way I implemented it (and what looks to be the easiest way to do so) came with a side effect. Some of the links leading to unexplored regions will be repositioned and change sides when said region is explored. I don't know if that is ok to leave in or if should it be fixed, so I'm just putting it out here. |
I haven't tested this yet, but I think it should be a pretty important goal to ensure the links or whatever don't visually jump around a lot when the player is switching patches. Otherwise it might look weird to the player to see the world changing shape as they move around. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't understand the map drawer fully before this PR and I still don't fully know it, so here's basically as full review of this PR as I can do.
Visible = visibilityState != MapElementVisibility.Undiscovered; | ||
questionMarkLabel.Visible = visibilityState == MapElementVisibility.Unexplored; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't these two lines be in a method that can be called if the state needs to change? And for example the comparison against a specific enum value done in VisibilityState setter would also benefit from calling such a method to ensure that one of these places isn't accidentally updated when the other isn't. Doing that also requires the questionmarklabel to be nullable to ensure the method doesn't run if it is called before _Ready is called.
@@ -6,4 +6,6 @@ public interface IEditorWithPatches : IEditor | |||
public Patch CurrentPatch { get; } | |||
|
|||
public void OnCurrentPatchUpdated(Patch patch); | |||
|
|||
public void UpdateReportTabPatchSelector(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name here is not changed yet.
@@ -898,7 +898,6 @@ visible = false | |||
visible = false | |||
|
|||
[node name="NewGameSettings" parent="." instance=ExtResource( 18 )] | |||
visible = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just commenting again to add this (and my previous comment) to my current review.
@@ -29,6 +29,7 @@ | |||
[sub_resource type="StyleBoxEmpty" id=1] | |||
|
|||
[node name="NewGameSettings" type="Control"] | |||
visible = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The diff still shows this line existing...
@@ -40,6 +41,9 @@ public enum RegionType | |||
Predefined = 3, | |||
} | |||
|
|||
[JsonProperty] | |||
public MapElementVisibility VisibilityState { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see the existing code is not following the property order rule for JSON very well, but could you move this down to be after ID
(but before Adjacent
)? That'd make this change correct even if the older code was not correct...
@@ -443,6 +546,67 @@ private Vector2[] GetLeastIntersectingPath(PatchRegion start, PatchRegion end) | |||
probablePaths.Add((new[] { startCenter, intermediate1, intermediate2, endCenter }, -i)); | |||
} | |||
|
|||
// Discard all paths intersecting patches in partially discovered regions | |||
var pathsToDiscard = new List<Vector2[]>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be worth it to make this into a field. That way the list can be reused for separate calls of GetLeastIntersectingPath to save on a lot of object allocations (just need to remember to Clear this list after the discarded paths are deleted).
} | ||
|
||
if (IgnoreFogOfWar) | ||
return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is return correct here or should this be continue
instead?
@@ -753,12 +992,26 @@ private void RebuildMapNodes() | |||
foreach (var entry in Map.Patches) | |||
{ | |||
var node = (PatchMapNode)nodeScene.Instance(); | |||
|
|||
if (IgnoreFogOfWar) | |||
entry.Value.Explored = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it required that the map drawer changes the state of the patch here? I really think that the map drawer shouldn't change the state of the map at all. Can this be safely removed? And potentially other code adjusted that doesn't know about ignoring the fog of war.
/// A link between two <see cref="PatchRegion"/>. | ||
/// Used in <see cref="AdjustPathEndpoints"/> | ||
/// </summary> | ||
private class RegionLink |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a slight feeling that this could be redone with a struct to save on memory allocations. Could you add a TODO remark here about investigating that?
Points = points; | ||
} | ||
|
||
public (Vector2[] Points, int Endpoint, int Intermediate, float Distance, Int2 Id) ToTuple() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the purpose of making a tuple out of this class? I see just using this to read a few variables. I think that just makes unnecessary data copies. I'd convert that code to just directly reading the fields of this class to avoid unnecessary complexity and data copies.
I'm kinda in the process of a big refactor to the drawer to solve a lot of issues I'm having, so I'll convert this to a draft until I think this new version is ready |
As we only want to draw multiple lines if one of the regions is unexplored
as it was unnecessary
We have recently refactored the entire microbe stage to use an Entity Component System architecture. Due to the extreme amount of work this conversion required, the change has already been merged to master. However, not all features are bug free or even work at all yet. Hopefully this does not cause too much disruption to other people's work, but some PRs depending on now broken functionality may need to wait. Also the CI checks may not pass even on master. Before that is fixed PRs that don't add new errors can be merged even with failing checks. Any help with reimplementing / fixing the entire game back up again is extremely welcome. The next Thrive release is planned to be at the end of November 2023. Before that happen the game has to be at least close to as functional as before. Note that the setup instructions have a new section on the native library which is required to be able to run Thrive at all in the future. Any improvement suggestions to the instructions or the compiling scripts are also welcome. |
Brief Description of What This PR Does
This PR hides unexplored patches and regions from players
Related Issues
Closes #3602
Progress Checklist
Note: before starting this checklist the PR should be marked as non-draft.
break existing features:
https://wiki.revolutionarygamesstudio.com/wiki/Testing_Checklist
(this is important as to not waste the time of Thrive team
members reviewing this PR)
styleguide.
Before merging all CI jobs should finish on this PR without errors, if
there are automatically detected style issues they should be fixed by
the PR author. Merging must follow our
styleguide.