Skip to content

Architecture

Jump to bottom
Vladyslav Vytrykush edited this page Jul 14, 2026 · 1 revision

Architecture

The architecture of Adventure-Game is designed around the principles of Object-Oriented Programming (OOP), modularity, and separation of responsibilities. Every gameplay feature is implemented as an independent system that communicates with other systems through well-defined interfaces.

Rather than placing all game logic inside a single file or class, Adventure-Game separates gameplay mechanics into reusable components such as the Character, Inventory, Items, Weapons, Armor, Potions, and Chests. This approach makes the project easier to understand, maintain, test, and extend as new features are added.

Table of Contents

Architecture Overview

Adventure-Game follows a modular architecture where each gameplay system is responsible for a single area of functionality.

The Character class acts as the center of the application, interacting with nearly every other system.

flowchart TD

Player --> MainMenu

MainMenu --> Character

Character --> Inventory

Inventory --> Item

Item --> Weapon
Item --> Armory
Item --> Potion

Character --> Chest

Potion --> Character

Weapon --> Character

Armory --> Character
Loading

Each component has a clearly defined responsibility and can evolve independently without affecting unrelated parts of the project.

Design Philosophy

The architecture is based on several core principles.

Object-Oriented Programming

Adventure-Game makes extensive use of:

  • Classes
  • Objects
  • Encapsulation
  • Inheritance
  • Polymorphism
  • Abstraction

These concepts allow different gameplay systems to work together while keeping the code organized.

Single Responsibility Principle

Every major class has one primary purpose.

For example:

Class Responsibility
Character Stores player information and statistics
MyInventory Manages collected items
Item Defines the common interface for all items
Weapon Represents offensive equipment
Armory Represents defensive equipment
Potion Represents consumable items
Chest Generates randomized loot

Keeping responsibilities separate improves maintainability and reduces code duplication.

Modularity

Each gameplay system functions as an independent module.

Examples:

  • The inventory knows how to store items.
  • Weapons know how to calculate attack values.
  • Potions know how to apply effects.
  • Chests know how to generate loot.

This modular approach makes future development significantly easier.

Core Components

The project currently consists of several interconnected systems.

Character

The Character class is the central object of the game.

It stores:

  • Player information
  • Statistics
  • Equipment
  • Inventory
  • Active effects
  • Gold
  • Level

Nearly every other class interacts with the Character object.

Inventory

The inventory manages every item owned by the player.

Responsibilities include:

  • Adding items
  • Removing items
  • Displaying inventory
  • Dynamic resizing
  • Managing unique item IDs

The inventory owns all collected items during gameplay.

Item

Item is the abstract base class used by every usable object.

It defines the common interface shared by all items.

Item
├── Weapon
├── Armory
└── Potion

This allows the inventory to store different item types using a single collection.

Weapon

Weapons provide offensive bonuses.

Current weapon properties include:

  • Attack
  • Defense bonus
  • Durability
  • Enchantment
  • Equipped status
  • Broken status

Weapons contribute to the character's total attack value.

Armory

Armor provides defensive bonuses.

Properties include:

  • Defense
  • Durability
  • Enchantment
  • Equipped status
  • Broken status

Armor directly affects the player's defensive statistics.

Potion

Potions modify player statistics.

Supported effects include:

  • Health
  • Strength
  • Defense
  • Agility
  • Intelligence
  • Gold

Potion effects are applied directly to the Character object.

Chest

Chests generate randomized loot.

Supported rarity levels:

  • Common
  • Rare
  • Epic
  • Legendary

Each chest contains multiple randomly generated items.

System Relationships

The following UML diagram illustrates how the project's major classes interact.

classDiagram

class Character

class MyInventory

class Item

class Weapon

class Armory

class Potion

class Chest

Character --> MyInventory

MyInventory --> Item

Item <|-- Weapon

Item <|-- Armory

Item <|-- Potion

Character --> Weapon

Character --> Armory

Character --> Chest

Potion --> Character
Loading

Object-Oriented Design

Adventure-Game demonstrates several important OOP concepts.

Encapsulation

Each class manages its own internal data.

Examples:

  • Character manages player statistics.
  • Inventory manages stored items.
  • Weapon manages durability.
  • Potion manages its own effect information.

Other classes interact through public member functions instead of directly modifying internal data.

Inheritance

All usable items inherit from the same abstract base class.

Item
│
├── Weapon
├── Armory
└── Potion

This allows the inventory to work with different item types without knowing their specific implementations.

Polymorphism

The Item class defines virtual functions such as:

  • ShowInfo()
  • Use()
  • GetName()
  • GetType()
  • Reset()

Each derived class implements these behaviors differently.

This enables runtime polymorphism while reducing duplicated code.

Abstraction

The Item class exposes only the behavior that every item shares.

Each derived class hides its own implementation details while presenting a consistent interface to the rest of the project.

Data Flow

The following diagram illustrates how information moves through the application.

flowchart LR

Player --> Menu

Menu --> Character

Character --> Inventory

Inventory --> Item

Item --> Weapon

Item --> Armory

Item --> Potion

Chest --> Inventory

Potion --> Character

Weapon --> Character

Armory --> Character
Loading

The Character object serves as the central point through which most gameplay systems communicate.

Gameplay Flow

A simplified overview of the game's execution.

flowchart TD

Start

Start --> MainMenu

MainMenu --> NewGame

MainMenu --> LoadGame

NewGame --> CharacterCreation

CharacterCreation --> StartingEquipment

StartingEquipment --> GameMenu

GameMenu --> Inventory

GameMenu --> CharacterStats

GameMenu --> Settings

GameMenu --> Help

Inventory --> Equip

Inventory --> UsePotion

Equip --> CharacterStats

UsePotion --> CharacterStats
Loading

This structure separates gameplay systems while maintaining a simple navigation flow.

Memory Management

Adventure-Game makes use of dynamic memory allocation for inventory management.

Current implementation includes:

  • Dynamically allocated item storage
  • Automatic inventory resizing
  • Runtime object creation
  • Pointer-based item ownership

The inventory increases its capacity whenever additional space is required, allowing the player to collect an arbitrary number of items.

Although the project currently uses raw pointers, the architecture could be modernized in the future by replacing them with smart pointers (std::unique_ptr or std::shared_ptr) to simplify ownership and improve memory safety.

Extensibility

One of the primary goals of the architecture is future expansion.

The modular design makes it straightforward to introduce new systems without significantly modifying existing code.

Potential additions include:

  • Combat System
  • Enemy AI
  • NPC interactions
  • Quest System
  • Dialogue System
  • Trading
  • Crafting
  • Skills
  • Magic
  • Multiplayer support
  • Procedural world generation

Because each gameplay feature is implemented as an independent module, new functionality can be integrated with minimal impact on the current architecture.

Why This Architecture?

This architecture was chosen because it offers several advantages:

  • Easy to understand for new developers.
  • Clear separation between gameplay systems.
  • Reduced code duplication.
  • Reusable components.
  • Better maintainability.
  • Scalable foundation for future development.
  • Strong demonstration of object-oriented programming concepts.

The project is intentionally organized to resemble the architecture of larger software projects while remaining approachable for learning purposes.

Architecture Summary

Adventure-Game is built around a modular object-oriented architecture where each class has a clearly defined responsibility.

The Character class serves as the central gameplay object, while systems such as Inventory, Weapons, Armor, Potions, and Chests operate as independent modules connected through well-defined interfaces.

This design makes the project easier to maintain, extend, and understand while providing an excellent foundation for implementing additional RPG mechanics in future versions.

Clone this wiki locally