System Design
Systems Architecture Diagram
The system begins when the user launches the executable file, which starts the game. On the main homepage UI display, the user can select what level they want to play, adjust game parameters, and enter the game level, which loads the game scene.
Once the level is ready to be played, a motion input window pops up on the top left of the screen that detects whether a specific body part of the user has entered the designated trigger zone. If the correct input is detected, the frontend sends that information to the backend scripts, converting the motion input into the keyboard input.
The corresponding method is called in accordance with the input received, which is then integrated back into the gameplay scene as live feedback of the input. Once the game terminates, the user returns to the UI for further action.
Design Patterns
Our project primarily follows a clear input-action structure that is common in Unity development, drawing inspiration from the Command Pattern and incorporating elements of State Management.
Command Pattern (Inspired)
User inputs are linked to specific behaviors, keeping input detection and game logic separate for better clarity. Although we don’t use separate command objects, our design still follows the principle of converting user input into clear, reusable actions that are easy to manage and extend.
State Management
We use internal state variables to control when certain actions can or cannot happen. This helps manage cooldowns, timing, and player interaction flow more smoothly.
Overall, this structure helps keep our code clean and organized, making it easier to add new features or update existing ones without breaking the overall system.
UML Diagram
The UML diagram illustrates the overall structure and flow of our game system. The core manager scripts, including GlobalEndgameManager.cs
, PlayerAgainManager.cs
, and SceneController.cs
, are present in all scenes. These scripts handle scene transitions, game state management, and user navigation throughout the experience.
The game starts on a homepage, where the user can select from 8 different levels. Once a level is selected, it runs with a structure like those shown below, using scene-specific scripts to handle key functionalities. Players can also view a tutorial before starting a game.
From the homepage, users can access settings or exit the game. During gameplay, they may pause or complete the level. When the game ends, users can restart or return to the homepage.