Architecture - SC-SGS/surviving-sarntal GitHub Wiki

This section describes the architecture of the game in detail.

Architecture

The game is built using a highly modular architecture that allows for flexibility, scalability, and ease of maintenance. The modular design breaks down the game into distinct components, each responsible for specific functionality as seen in the architecture diagram.

Architectural-Diagramm.drawio

This approach ensures that different parts of the game can be developed, tested, and modified independently, making the overall system more manageable. Below, we describe the general architecture and how different parts contribute to building the game.

The game is initialized through a GameFactory class, which is responsible for building and configuring all core components and dependencies. These components can be categorized into services, game entities, menu systems, rendering pipelines, spawning systems, and the physics engine.

Services

Several core services are initiated within the GameFactory to manage resources, input, and audio:

  • ConfigService: A singleton pattern is used to handle game configuration (including YAML settings), ensuring game constants and configurations are readily available throughout the game.
  • InputService: A singleton service responsible for managing input from various devices, such as gamepads and keyboards.
  • ResourceService: Handles loading and management of game assets such as textures, audio, and other resources. It depends on the ConfigManager to load the assets specified in the YAML file.
  • AudioService: Manages sound effects and background music. It interacts with the ResourceManager to load sound files and handle audio playback within the game.
  • DifficultyService: A singleton service that manages the difficulty progression during the gameplay.

Game Entities

Key in-game entities, such as the terrain, hiker, and inventory, are created and managed by the GameFactory. These entities interact with the world and with each other, providing the core gameplay functionality.

  • Terrain: Generated based on game constants and managed by the Terrain class. It determines the physical environment in which the player interacts.
  • Hiker: The main player character, represented by the Hiker class.
  • Monster: An antagonist entity represented by the Monster class, which adds an element of challenge for the player, acting as a threat.
  • Inventory: Manages the player's items and inventory.

These entities are bound together within the World class, which encapsulates the terrain, hiker, monster, and inventory, managing their interactions.

Spawner System

The game includes a system for dynamically spawning items and rocks during gameplay:

  • ItemSpawner: Spawns items in the world based on configuration from the YAML file (e.g., item spawn rates and types).
  • RockSpawner: Dynamically spawns rocks of various sizes, speeds, and densities during gameplay, adding an element of challenge.
  • Spawner: A unified spawner that manages both the ItemSpawner and RockSpawner. It also initiates the terrain generation.

This modular spawner system allows for dynamic game elements that can evolve based on player progress or difficulty.

Physics and Collision Detection

The game incorporates a robust physics engine to handle movement, collisions, and interactions between entities:

  • Accelerator: Applies acceleration forces to the entities, such as gravity and other forces affecting the hiker or objects in the game world.
  • CollisionDetector: Detects collisions between entities (e.g., hiker and terrain, rocks, or inventory items) to trigger corresponding responses.
  • CollisionHandler: Handles the game logic triggered by collisions, such as taking damage or picking up items.
  • Destructor: Handles the accurate and timely destruction of entities.
  • Positioner: Handles the correct positioning of the entities within the game.
  • PhysicsEngine: The central physics engine that manages all other physics modules.

By abstracting collision detection and handling into separate classes, the game ensures that its physics are flexible and can easily be adapted or expanded upon.

Menus and UI

The game uses a sophisticated menu system to handle the user interface, including in-game menus. This system is composed of:

  • MenuEngine: Responsible for managing the game's various menus, including the start screen, settings, and pause menus. It also handles user input in these menus.
  • FullMenuRenderer: Renders the menu components on the screen.
  • MenuEventProcessor: Handles events that occur within the menus, such as button clicks and navigation.

This system ensures that the menu and UI are distinct from the core game logic, allowing independent development and modification of the user interface.

Renderer

The game rendering is divided into several subsystems to ensure modular and efficient drawing of different elements:

  • PolygonRenderer: Used for drawing polygonal shapes, typically for terrain or other geometric elements.
  • MountainRenderer: A specialized renderer for drawing the mountain and environmental elements in the background.
  • EntityRenderer: Handles rendering of game entities (e.g., the hiker, inventory items, and the monster).
  • HUDRenderer: Renders the HUD, displaying information such as health, score, and inventory status.
  • Renderer: The central renderer that coordinates all these subsystems. It integrates the World entities and renders the terrain, entities, and HUD together.

This modular rendering system separates concerns, ensuring that changes to how entities are drawn, or the addition of new visual elements, can be done without affecting the rest of the game.