You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 2, 2023. It is now read-only.
The Game service documentations suggests that sending a start game request while the game is already running, 'nothing will happen'. Doing so ended the simulation. It created a panic with the following message:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: AlreadyInState', game\src\systems\change_app_state.rs:15:47
It looks like the offending line sets the state without checking whether it matches. I would think that a mutable variable could handle being set to the same state, but that does not seem to be the case.
I intend to change the logic such that my client does not try to start the game while it is running. But, it is still appropriate to either change the documentation or resolving the command robustly.
The text was updated successfully, but these errors were encountered:
Uff that's definitely not the right way to handle the situation. Not sure if something changed in Bevy or if I was just lazy when writing this code path...
If I remember correctly, I wanted to keep the business logic out of the API layer. That's why the API simply forwards the command, and let's the game deal with it. The downside of this approach is that the API cannot return a meaningful error, which is a problem I never solved.
As a user, what would you expect to happen here? Error message? Restarting the currently running game?
I uncovered this discrepancy by inflexibly sending a start the game request whenever a view client connected to my game playing agent (specifically, when I refreshed the webpage), which is not a use case I expect nor desire. That is why I mentioned changing my client logic, independent of a resolution here.
I prefer the documentation's suggestion, that starting a game should be idempotent. Stopping a game (to restart it) feels like a separate concept. I acknowledge that a client with a poor network experience could miss the original message and would expect to still receive a StartGameResponse, even for a running game.
<2023-01-11 edit corrects the link from unrelated software to a library that imitates a bad network connection.>
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The Game service documentations suggests that sending a start game request while the game is already running, 'nothing will happen'. Doing so ended the simulation. It created a panic with the following message:
It looks like the offending line sets the state without checking whether it matches. I would think that a mutable variable could handle being set to the same state, but that does not seem to be the case.
I intend to change the logic such that my client does not try to start the game while it is running. But, it is still appropriate to either change the documentation or resolving the command robustly.
The text was updated successfully, but these errors were encountered: