Skip to content
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

Closed

Conversation

ender-titan1
Copy link
Member

@ender-titan1 ender-titan1 commented Sep 10, 2023

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.

  • PR author has checked that this PR works as intended and doesn't
    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)
  • Initial code review passed (this and further items should not be checked by the PR author)
  • Functionality is confirmed working by another person (see above checklist link)
  • Final code review is passed and code conforms to the
    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.

@hhyyrylainen hhyyrylainen added this to In progress in Thrive Planning via automation Sep 10, 2023
@ender-titan1
Copy link
Member Author

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:

Screenshot (108)

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.

@hhyyrylainen
Copy link
Member

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.

@ender-titan1
Copy link
Member Author

I think this is ready for review now

@ender-titan1 ender-titan1 marked this pull request as ready for review September 14, 2023 17:55
@hhyyrylainen hhyyrylainen requested review from a team September 15, 2023 11:06
@hhyyrylainen hhyyrylainen added this to the Release 0.6.4 milestone Sep 15, 2023
@buckly90
Copy link
Member

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.
I'm a little worried this might make it a bit more oppresive to new or casual players though...
We'll need to discuss this among the team to determine how to handle it in relation to difficulty and complexity.

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.

@GameDungeon
Copy link
Contributor

I was going to suggest a toggle in the new game settings as well. For something like this, I think that is pretty critical.

@hhyyrylainen
Copy link
Member

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.

@ender-titan1
Copy link
Member Author

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.

@hhyyrylainen
Copy link
Member

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.

Copy link
Member

@hhyyrylainen hhyyrylainen left a 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.

Comment on lines +198 to +199
Visible = visibilityState != MapElementVisibility.Undiscovered;
questionMarkLabel.Visible = visibilityState == MapElementVisibility.Unexplored;
Copy link
Member

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();
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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; }
Copy link
Member

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[]>();
Copy link
Member

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;
Copy link
Member

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;
Copy link
Member

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
Copy link
Member

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()
Copy link
Member

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.

@ender-titan1
Copy link
Member Author

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

@ender-titan1 ender-titan1 marked this pull request as draft October 2, 2023 17:55
@revolutionary-bot
Copy link

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.

@hhyyrylainen hhyyrylainen moved this from In progress to started but stuck (help wanted) in Thrive Planning Dec 8, 2023
@ender-titan1 ender-titan1 mentioned this pull request Dec 14, 2023
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Thrive Planning
  
started but stuck (help wanted)
Development

Successfully merging this pull request may close these issues.

Add fog of war for the patch map
8 participants