Currently, games can only be activated. It is up to external automation to decide what activated means and does, e.g., start or stop a game. However, in cases where a game crashes, there is not a way for the automation to decide whether to start the game or restart the game. As an example, starting a game may do more than simply start the game, such as turning on the TV, game device, etc., while restarting only needs to restart the game process.
For this reason, there is a need to allow games to be started (activated), stopped (deactivated) and restarted as independent MQTT messages. This also means that this state persists in the database.
[x] Given a game is not activate, the user can start the game from the details view
[x] Given a game is active, then the user can restart the game from the details view
[x] Given a game is active, then the user can stop the game from the details view
[x] Given a game is active, then the user can start the game on a different platform from the details view
[x] Active state is reflected in game details, regardless of what page (home, browse, etc.)
[x] When changing a releases' active state, then the UI reflects this change without needing to refresh
Currently, games can only be activated. It is up to external automation to decide what activated means and does, e.g., start or stop a game. However, in cases where a game crashes, there is not a way for the automation to decide whether to start the game or restart the game. As an example, starting a game may do more than simply start the game, such as turning on the TV, game device, etc., while restarting only needs to restart the game process.
For this reason, there is a need to allow games to be started (activated), stopped (deactivated) and restarted as independent MQTT messages. This also means that this state persists in the database.