Skip to content

Class Hierarchy

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

Class Hierarchy

The Class Hierarchy defines the object-oriented architecture of Adventure-Game. The project follows the fundamental principles of Object-Oriented Programming (OOP), including inheritance, encapsulation, abstraction, and polymorphism, to create a modular and maintainable codebase.

Instead of implementing all functionality in a single class, Adventure-Game separates responsibilities into specialized classes that work together to create the gameplay experience. This architecture improves code organization, reduces duplication, and makes future expansion significantly easier.

This page explains how the classes are related, why inheritance is used, and how different systems interact throughout the project.

Table of Contents

Overview

Adventure-Game is built around a collection of independent classes, each responsible for a specific part of the game.

Examples include:

  • Character management
  • Inventory management
  • Weapons
  • Armor
  • Potions
  • Chests
  • Save system
  • Game menus

Each class performs one primary responsibility while collaborating with other systems through clearly defined interfaces.

Design Philosophy

The project follows several important software engineering principles.

Single Responsibility Principle

Each class has one main purpose.

For example:

  • Character manages player data.
  • Weapon manages weapon information.
  • Potion manages consumable effects.
  • MyInventory manages stored items.

Modularity

Gameplay systems are separated into independent modules.

This allows individual systems to evolve without affecting the rest of the project.

Reusability

Shared functionality is implemented in base classes whenever possible.

This reduces duplicated code.

Scalability

The architecture allows additional gameplay systems to be added with minimal modifications.

Examples include:

  • Quest System
  • Skill Trees
  • NPC System
  • Crafting
  • Trading

Core Classes

The project is organized around several major classes.

Class Responsibility
Character Stores all player information and statistics.
Item Abstract base class for all collectible objects.
Weapon Offensive equipment.
Armory Defensive equipment.
Potion Consumable items.
MyInventory Stores collected items.
Chest Generates randomized loot.
ActiveEffect Represents temporary buffs or effects.

Each class focuses on a specific gameplay mechanic.

Inheritance Hierarchy

Adventure-Game uses inheritance to avoid duplicated functionality.

The Item class serves as the common base class for every collectible object.

classDiagram

Item <|-- Weapon
Item <|-- Armory
Item <|-- Potion
Loading

Every derived class inherits the common properties of an Item while introducing specialized behavior.

Item Hierarchy

The Item hierarchy is one of the most important parts of the project.

                Item
                  │
        ┌─────────┼─────────┐
        │         │         │
     Weapon    Armory    Potion

Because every collectible object inherits from Item, the inventory can store all item types using a common interface.

This is a practical example of polymorphism.

Class Relationships

The following diagram illustrates how the major classes interact.

classDiagram

Character --> MyInventory

Character --> Weapon

Character --> Armory

Character --> ActiveEffect

Chest --> Weapon

Chest --> Armory

Chest --> Potion

MyInventory --> Item

Item <|-- Weapon

Item <|-- Armory

Item <|-- Potion
Loading

The Character acts as the central object while other systems provide specialized functionality.

Character Relationships

The Character class communicates with nearly every gameplay system.

flowchart LR

Character --> Inventory

Inventory --> Weapon

Inventory --> Armory

Inventory --> Potion

Weapon --> Character

Armory --> Character

Potion --> Character

Chest --> Inventory
Loading

This architecture keeps gameplay organized while avoiding unnecessary dependencies.

System Responsibilities

Each gameplay system owns its own responsibilities.

Class Responsibilities
Character Player statistics, equipment, progression
Item Shared item interface
Weapon Attack-related equipment
Armory Defensive equipment
Potion Consumable effects
MyInventory Item storage and management
Chest Loot generation
ActiveEffect Temporary stat modifiers

No class attempts to perform the work of another.

Object Ownership

Ownership is organized hierarchically.

Character
│
├── MyInventory
│      │
│      ├── Weapon*
│      ├── Armory*
│      └── Potion*
│
├── Equipped Weapon
├── Equipped Armor
│
└── Active Effects

This ownership model keeps data organized while clearly defining which objects are responsible for managing others.

Why Use an Abstract Item Class?

Without inheritance, the Inventory would require separate storage for every item type.

Example:

Weapon weapons[100];
Armory armor[100];
Potion potions[100];

Instead, Adventure-Game stores pointers to the abstract Item class.

Item* inventory[];

Advantages include:

  • Cleaner code
  • Less duplication
  • Easier expansion
  • Better maintainability
  • Support for polymorphism

This design allows new item types to be introduced with minimal changes.

Encapsulation

Each class stores and manages its own data.

For example:

  • Character manages statistics.
  • Weapon manages attack values.
  • Potion manages effects.
  • Inventory manages stored items.

External classes interact through public member functions rather than modifying internal data directly.

Polymorphism

Because every collectible inherits from Item, the Inventory can work with different object types without knowing their exact class.

For example:

Item* item = new Weapon(...);
Item* item = new Armory(...);
Item* item = new Potion(...);

This allows all collectible objects to be treated uniformly while preserving their specialized behavior.

Benefits of the Architecture

The current class hierarchy provides several advantages.

  • Clear separation of responsibilities
  • Easy maintenance
  • Reduced code duplication
  • Improved readability
  • Better scalability
  • Easier debugging
  • Simpler testing
  • Reusable components
  • Flexible expansion

These qualities make the project easier to develop as new gameplay systems are introduced.

Future Expansion

The current hierarchy has been designed to support additional classes.

Potential future additions include:

Item
├── Weapon
├── Armory
├── Potion
├── QuestItem
├── CraftingMaterial
├── Accessory
├── KeyItem
└── MagicArtifact

Additional gameplay systems may include:

  • Quest System
  • NPC System
  • Trading
  • Crafting
  • Skills
  • Magic
  • Achievement System
  • Save Manager
  • World Manager

Because the architecture is modular, these features can be implemented without redesigning the existing class hierarchy.

Summary

The Class Hierarchy forms the structural foundation of Adventure-Game. By applying object-oriented programming principles such as inheritance, encapsulation, and polymorphism, the project organizes gameplay functionality into independent, reusable, and scalable components.

The use of an abstract Item base class, modular gameplay systems, and clearly defined class responsibilities not only simplifies the current implementation but also provides a strong framework for future development. As new features are introduced, the existing hierarchy allows the project to grow while maintaining clean, maintainable, and well-structured code.

Clone this wiki locally