Skip to content
This repository has been archived by the owner on Aug 2, 2023. It is now read-only.

Starting a running game killed it #211

Open
Nzen opened this issue Oct 6, 2022 · 2 comments
Open

Starting a running game killed it #211

Nzen opened this issue Oct 6, 2022 · 2 comments
Labels
C-bug Report a new bug L-rust Tag the Rust ecosystem

Comments

@Nzen
Copy link
Contributor

Nzen commented Oct 6, 2022

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.

@jdno jdno added C-bug Report a new bug L-rust Tag the Rust ecosystem labels Oct 11, 2022
@jdno
Copy link
Owner

jdno commented Oct 11, 2022

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?

@Nzen
Copy link
Contributor Author

Nzen commented Oct 12, 2022

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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
C-bug Report a new bug L-rust Tag the Rust ecosystem
Projects
None yet
Development

No branches or pull requests

2 participants