Use Cases

Motivating Use Case

1. User chooses a game.
2. User sends URL to friend(s).
3. Users play game.

Use Cases

Quickgame App Use Cases

Index page

A client user:

• sees list of games to select, with rule descriptions.

####Game room A client user:

• who clicks the URL is sent to the same room.
• can text chat.
• can video chat.
• can choose what game role they want.
• can change rule options of the game.
• can start the game if enough players are available by pressing a "Start" button.
• can attempt to play a move in the game.
• can pause a currently playing game.
• can abort a game in progress.
• can switch the type of game being played without creating a new room and re-inviting everyone.
• can choose a computer player to take the place of a missing player.

The quickgame client:

• pauses a game if a player leaves.
• informs a player if a move is invalid.
• at game end, informs the winning/losing players and resets the game state.
• archives the history of the games played.
• maintains a game timer.
• is responsive to mobile devices.

Server Use Cases

• Recovers ongoing games in case of server failure/restart.

Developer Use Cases

These are use cases from the perspective of a developer maintaining the application.

A developer:

• can create a new game type descriptively, without changing the computation logic.
• can easily create a game type without changing the client/server protocol.

Pedagogical Use Cases

These are use cases from the perspective of me using this project as a learning opportunity.

• The computational backend is an Akka actor system.
• The UI uses some reactive library (e.g. Rx, react).