Back To Hub

CapTale 4+1 Architecture View

This page organizes the software architecture using the 4+1 model, so structure, implementation, runtime behavior, deployment setup, and key user journeys can be reviewed in one place.

Logical Development Process Physical Scenarios

Logical View

  • CapTaleSystem is the top-level controller.
  • Cap is the shared player state.
  • Lobby is the hub that routes to scene modules.
  • Each city module handles one gameplay domain through its own update and render responsibilities.
  • Scene selection follows a clear boundary: Lobby decides destination, while each city owns internal gameplay rules.
  • Cap acts as a cross-scene domain object for energy, currency, and progression continuity.
  • MessageManager provides shared notification support.
  • MessageManager is reused across modules to keep feedback behavior consistent and decoupled from city logic.
  • Timer supports time-based behavior in messaging and Space Shooter.
  • State transitions are centralized in CapTaleSystem, reducing coupling between city modules.
  • The logical model separates concerns into orchestration, shared state, scene routing, gameplay modules, and utilities.

Reference Diagram: Class Diagram (Functional Modeling)

Development View

  • main.cpp contains the application shell and state machine.
  • headers/cap.h contains the shared player object.
  • headers/lobby.h contains lobby logic and room detection.
  • headers/message.h contains the message subsystem.
  • headers/customCity.h contains cap selection.
  • headers/pongCity.h contains Pong gameplay.
  • headers/carCity.h contains Car City gameplay.
  • headers/atmCity.h contains ATM logic.
  • headers/earningCity.h contains Earn City quiz logic.
  • headers/energyCity.h contains Energy City logic.
  • headers/spaceShooter.h and headers/sprites.h contain Space Shooter and its entity hierarchy.
  • headers/custom_timer.h contains the reusable timer utility.
  • headers/settings.h and headers/spaceShooterSettings.h define constants.

Reference Diagram: Class Diagram (Implementation Details)

Process View

  • The system runs a single frame-based game loop.
  • Each frame follows a deterministic pipeline: input handling, state update, collision/timer evaluation, then rendering.
  • CapTaleSystem dispatches behavior based on the current scene state.
  • Scene modules execute internal logic independently while following the shared frame contract.
  • Timers are evaluated during updates to trigger delayed effects, cooldowns, and time-based events.
  • Collision checks run inside scene updates and immediately feed score, energy, and game-over conditions.
  • State transition checks occur after updates, allowing controlled scene switching without mid-frame inconsistencies.
  • Audio and visual feedback are synchronized with state outcomes in the same frame cycle.
  • Raylib handles real-time keyboard, mouse, drawing, and audio operations.

Reference Diagrams: Activity Diagrams and Sequence Diagrams

Physical View

  • Execution environment is a Windows desktop machine.
  • The game runs as a native C++ executable.
  • Raylib provides graphics, audio, and windowing support.
  • Assets are loaded from the local filesystem relative to the project folder.
  • Save data is read from and written to characterData.txt in the project root.

Reference Diagram: Deployment Diagram

Scenario View

Representative end-to-end user journeys that validate the architecture in action. Reference Diagram: Use Case Diagrams

Step 1 Entering a city from the lobby.
Step 2 Playing Pong, Car City, Space Shooter, Earn City, ATM City, or Energy City.
Step 3 Managing tokens through room entry and ATM conversion.
Step 4 Managing energy through movement drain and Energy City item collection.
Step 5 Saving progress on exit and restoring progress on next run.