3. Design

3.1 Overview#

The Capoo project adopts an object-oriented approach to structure gameplay logic, data flow, and visual presentation. To facilitate collaborative development and modularity, we designed our architecture around clear abstractions and used UML diagrams to model our system’s behavior and structure. In particular, we utilised a Class Diagram to represent core entities and their relationships, and a Sequence Diagram to model runtime interactions, especially in puzzle-related events such as switch activation and character interaction.

3.2 Class Diagram#

Our class diagram provides a structural overview of Capoo’s object-oriented architecture. At its core, the system is driven by a GameModel, which holds references to key game objects such as platforms, interactable elements, and the player character.

Key Components:#

• GameModel: Serves as the central container for game state and level data. It stores all terrain, interactive elements (e.g., Switches, Keys, ElevatingWalls), and references to the Capoo character.
• Capoo: Inherits from AbstractCharacter, encapsulating properties such as position, speed, and state (e.g., facingRight, isGrounded). It is the player-controlled entity responsible for interacting with puzzles and moving across terrain.
• Terrain & Environment: Classes such as Ground, Trap, Spring, Water, and Climb inherit from AbstractTerrain. These are used to render the static environment and define different gameplay zones with unique physical effects.
• Interactables:
  • Switches: Can be triggered by the player or other entities. Linked to actions such as activating ElevatingWalls.
  • Keystem: Represents collectible or logic-triggering items that influence puzzle conditions.
  • Flag: Represents level goals or checkpoints.
  • Potion, Wizard: Dynamic game objects that can be interacted with or triggered conditionally.
• GameController: Controls the game loop logic including player input, game reset, and interactions. Interfaces directly with the GameModel and processes collision and event updates.
• MapLoader: Responsible for loading and parsing level data into structured game objects.
• UI and Rendering:
  • GameView: Renders the visual interface by referencing GameModel.
  • RenderLogic, SplineLayer, and Cloud: Manage background animations and UI transitions, powered by the THREE.js rendering engine.

This modular structure allows for flexible development and easy modification of individual game systems.

3.3 Sequence Diagram#

To represent dynamic gameplay interaction, we created a sequence diagram that models a typical scenario where the player activates a switch that raises a wall and unlocks a key mechanism.

Scenario Flow :#

1. Player initiates movement using key inputs processed by GameController.
2. Capoo updates its position and interacts with terrain using gravity and collision checks (e.g., canClimb(), isNearPix()).
3. A collision with a Potion or Switches object is detected:
   • For Potion: updates Capoo’s velocity and position.
   • For Switch: triggers wall movement (ElevatingWalls) via setTarget() and updateWallPosition().
4. The game logic updates the visual state (GameView.drawGameScreen()), and the camera updates its position via RenderLogic.
5. Additional UI feedback is managed via the Message class and Utils.showPotion() method.

The sequence clearly demonstrates the flow of control from player input to game logic and rendering, emphasizing how interactions cascade through the system.

3.4 State Machine Diagram#

We created a state diagram for Capoo to map the lifecycle of key game components like GameModel, Capoo, Potion, and others. The diagram illustrates state transitions—such as Capoo moving from Idle to Walking, or the GameModel transitioning to GameOver—which helped clarify the conditions for state changes during development.

For instance, the Potion transitions from Inactive to Active upon pickup, and ElevatingWalls move from Static to Moving based on triggers. This visual representation helped identify edge cases, ensure synchronized game logic, and streamline development, ultimately reducing debugging time.

3.5 Communication Diagram#

The Communication Diagram for the Capoo Game illustrates the interactions between key components. The Player sends inputs to the GameController, which processes them and updates the GameModel. This triggers changes in entities like Capoo, Potion, KeyItem, Flag, and ElevatingWalls. These updates are rendered by RenderLogic and displayed in the GameView.

The MapLoader initializes game levels and parses entity data for the GameModel. Capoo interacts with objects, triggering events that are reflected in the game state. SpineLayer manages character animations, ensuring smooth visuals. Error handling in GameController ensures stability during gameplay.

This structure maintains synchronized game states, smooth animations, and consistent feedback to the player.

3.6 Design Considerations#

During design and implementation, we faced several technical challenges that led to important design decisions:

• Modularity vs. Integration: While we abstracted base classes such as AbstractEntity, AbstractTerrain, and AbstractItem to promote reusability, we needed to balance this with the tight integration required for real-time gameplay response.
• Rendering Separation: By offloading animation and background logic into RenderLogic and SplineLayer, we ensured a separation of concerns between game logic and rendering, improving maintainability and scalability.
• Puzzle System Scalability: Elements like Switches and ElevatingWalls were designed to be easily extendable by assigning ID-based triggers, supporting more complex puzzles in future levels.

3.7 Iterative Development & Diagram Updates#

Consistent with agile methodology, our class and sequence diagrams evolved over time. For example, earlier prototypes had more monolithic controller logic, but we later separated GameController and MapLoader to improve maintainability and testing. Additionally, classes such as Capoo, Potion, and ElevatingWalls saw expanded responsibilities as gameplay mechanics became clearer through playtesting.

3.8 Conclusion#

The UML models we developed played a crucial role in organizing our design and facilitating communication within the team. By combining a strong object-oriented foundation with agile iteration, we built a flexible and scalable game architecture that can accommodate future features such as multi-character control or extended puzzle mechanics.