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

Room preview from clicking on minimap now will have access to the current game's state variables (in a safe way). #61

Merged
merged 2 commits into from
Sep 28, 2020

Conversation

EvidentlyCube
Copy link
Collaborator

The original code would only set stats field of the temporary current game, which is immediattely overwrrited by the left-empty statsAtRoomStart. Happened in a call to CCurrentGame::SetTurn(0), followed by CCurrentGame::SetPlayerToRoomStart() followed by this->stats = this->statsAtRoomStart.

The new solution will instead set statsAtRoomStart to the current game's statsAtRoomStart effectively exposing the variables in the previews.

…rent game's state variables (in a safe way).

The original code would only set `stats` field of the temporary current game, which is immediattely overwrrited by the left-empty `statsAtRoomStart`. Happene in a call to `CCurrentGame::SetTurn(0)`, followed by `CCurrentGame::SetPlayerToRoomStart()` followed by `this->stats = this->statsAtRoomStart`.

The new solution will instead set `statsAtRoomStart` to the current game's `statsAtRoomStart` effectively exposing the variables in the previews.
@EvidentlyCube
Copy link
Collaborator Author

EvidentlyCube commented Sep 28, 2020

What I could do instead is set the temporary game's statsAtRoomStart to current game's stats. The benefit would be that you'd see the room preview in exactly the state you'd see it as if you just went there, which could be meaningful when you did something in a room that you knew triggered a variable changed and would be able to inspect some other room and see how it was affected immediately.

The downside of this solution is that in some extremely rare cases this could be used to get to some knowledge early. Like maybe a room where after causing the variable change you can still get stuck. But is it really a risk? I don't think so.

The more I think about it the more I am convinced it should actually be changed to:

pTempGame->statsAtRoomStart = this->pCurrentGame->stats;

It avoids awkwardness when you KNOW that something should be changed and everyone accepts it, but the player will see a stale preview until they bother to leave the room.

In other words, because I feel like I made a word salad, there are two ways to approach this:

  1. The one I implemented - room preview acts with variables as if nothing yet happened in the room the player is in right now.
  2. The other one - room preview acts as if the player visited the previewed room right now.

I think ultimately the second option makes slightly more sense.

@EvidentlyCube
Copy link
Collaborator Author

EvidentlyCube commented Sep 28, 2020

Relevant Thread.

@mrimer
Copy link
Member

mrimer commented Sep 28, 2020

I think ultimately the second option makes slightly more sense.

I agree with your reasoning. Let's go with the second option.

RPG does a similar thing (or should, anyway), where when you preview another room, the monster stats and combat resolution in that room are based on the current game state, as opposed to showing for the point in time when you entered the current room.

… current stats, so that the minimap room preview shows the room in a state it'd be as if the player teleported there right now, rather than with the state from the time the current room was entered
@EvidentlyCube
Copy link
Collaborator Author

Updated PR!

@mrimer mrimer merged commit 72e0c2c into CaravelGames:master Sep 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants