System Architecture

Database Table

Sokrobans reliance on a database is very minimal, though crucial. The DB will only need to store the players Username(varchar,NOT NUll), Password(varchar,NOT NULL), HighScore(int), best time(time), and level(int).UserName and Password are the only two fields in the DB that are marked as NOT NULL, due to the simple fact that a user must have an account in order to "save" any data. One table is all that will need to be created in order to store the inforamtion and be utilized to pass data back and forth between the API.

API Diagram

Sokroban will utilize an RESTful API hosted via Azure to pass player data back and forth between the game and the database. A player's high score, best time and level will all be saved.The best time, high score, and level will be updated after every "run" the game will check with the DB to see if any of the fields have been topped and replace update the data in the table. There will also be a leaderboard that will display the table in the database (minus the user password of course) filtered by top score overall.

UML Diagram

At the top of this diagram we explore how classes interact with the UI. Firstly we have different components of the Game UI like Timer, Level Count etc. all interacting with the Game UI interface. We also show how scene managers like MainMenuManager interact with each other and the UI and with the Canvas. The Canvas is where all UI components are displayed.

In the center we focus on the multiplayer and API aspects of our game. The CreateAndJoinRoom and the ConnectionToServer classes handle the connection to Photon and the connection between the players. The leaderboard and AccountHandler, take care of the sign in/login and the leaderboard functions.

At the bottom our classes represent the level generation and how each class works with one another. A lot of the classes derive from another like, Templates deriving from Template, deriving from Cell each class taking care of a smaller part of the larger generation. Then when we reach the Level class we sum up all the calculations of the previous classes and produce a level which the LevelTranslator turn into a playable Unity level

To the right we have the Unity objects. This mainly consists of prefabs like Player, Box, Wall, Ground, and Target. These are what the player will be using to interact and each of these prefabs is very important as they are using by the LevelGenerator to specify where to spawn each prefab. Each prefab also has connected components like Transform (showing position and size), Sprite Renderer (showing what the object will look like), and other classes that might give the object function, like movement and so on.

UML Front-End Diagram

UML Back-End Diagram

Sequence Diagrams

Use Case 1: Player wants to successfully register their account and then exit the game

Use Case 1 Description

1) Player upon opening the application is prompted to create an account or to sign in.
2) Player selects the option to create a new account.
3) Player inputs a username and a password.
4) Upon completion, player logs into account with their credentials.
5) Player enters to the main Menu.
6) Player exits the game by pressing the “X” button.

Use Case 2: Player wants to play Normal Mode (Single Player)

Use Case 2 Description

1) Player selects the Single Player Mode option.
2) Player is viewing the three choices of Single Player.
3) Player selects Normal Mode.
4) A level is generated for the player.
5) Player is now playing the game.

Use Case 3: Player wants to play Challenge Mode

Use Case 3 Description

1) Player selects the Single Player Mode option.
2) Player is viewing the three choices of Single Player.
3) A level is generated for the player.
4) Player is now playing the game without the reset or undo buttons available.

Use Case 4: Player wants to play a game with a friend

Use Case 4 Description

1) Player selects the Multiplayer Mode option.
2) Player selects the Co-op option.
3) Player sets up a lobby by creating a room and tells their friend the name of the room to join.
4) Both players are on the same map.
5) Players are helping each other in order to win the level.

Use Case 5: Player wants to play a game against a friend

Use Case 5 Description

1) Player selects the Multiplayer Mode option.
2) Player selects the VS option.
3) Player sets up a lobby by creating a room and tells their friend the name of the room to join.
4) Players are competing on the same level in a split-screen.
5) Player gets the boxes into the end point faster than their friend.
6) Player won the game.

Use Case 6: Player wants to check high scores

Use Case 6 Description

1) Player selects the High Scores option.
2) Player views high scores.

Use Case 7: Player wins level

Use Case 7 Description

1) Player selects Normal Mode option.
2) A level is generated for the player.
3) Player starts to move the character and push the box by using the arrows on the keyboard.
4) Player places the box onto the target.
5) Player wins the level.

Use Case 8: Player gets stuck and resets the level

Use Case 8 Description

1) Player selects Normal Mode option.
2) Player moves the character and pushes the box(es) trying to win the level.
3) Player realizes that got stuck by pushing a box onto the wall and won’t be able to place the box onto the target.
4) Player resets the level by pressing the reset button.
5) The level resets with the character and the box(es) back to their starting positions.

Use Case 9: Player wants to play with a different character

Use Case 9 Description

1) Player selects Single Player option.
2) Player selects their favorite character from a variety of characters.
3) Player starts playing with the chosen character.

Use Case 10: Player wants to challenge themselves onto a map with complex design

Use Case 10 Description

1) Player selects Single Player option.
2) Player selects from a variety of maps with complex deisgn.
3) Player plays the game with a more complex designed map.