RPG Character System Project¶

from abc import ABC, abstractmethod

class Character(ABC):
    def __init__(self, name, health, attack):
        self.name = name
        self.health = health
        self.attack = attack

    @abstractmethod
    def special_ability(self):
        pass

class Warrior(Character):
    def special_ability(self):
        damage = self.attack * 2
        return f"{self.name} uses Power Strike for {damage} damage!"

class Mage(Character):
    def special_ability(self):
        damage = self.attack * 3
        return f"{self.name} casts Fireball for {damage} damage!"

class Healer(Character):
    def special_ability(self):
        heal = self.health // 2
        return f"{self.name} uses Holy Light, healing for {heal} HP!"

def use_ability(character):
    # No type checking — polymorphism handles dispatch
    print(character.special_ability())

for c in [Warrior("Conan", 100, 15), Mage("Gandalf", 60, 25), Healer("Mercy", 80, 8)]:
    use_ability(c)

use_ability works because all subclasses implement special_ability() — the ABC guarantees it. The caller does not need if isinstance(...) checks. This is polymorphism: same interface, different behavior based on type.

With inheritance, 10 more types means 10 more subclasses — each duplicating the same __init__ boilerplate and differing only in special_ability() and stat growth. This is the inheritance explosion problem.

Composition-based alternative:

class Ability:
    def __init__(self, name, multiplier, description):
        self.name = name
        self.multiplier = multiplier
        self.description = description

    def use(self, character):
        damage = character.attack * self.multiplier
        return f"{character.name} uses {self.name} for {damage} damage!"

class Character:
    def __init__(self, name, health, attack, defense, ability):
        self.name = name
        self.health = health
        self.attack = attack
        self.defense = defense
        self.ability = ability  # Composition

    def special_ability(self):
        return self.ability.use(self)

# Create characters by composing different abilities
power_strike = Ability("Power Strike", 2, "A powerful melee attack")
fireball = Ability("Fireball", 3, "A devastating fire spell")

warrior = Character("Conan", 100, 15, 10, power_strike)
mage = Character("Gandalf", 60, 25, 5, fireball)

Adding a new character type now requires only a new Ability instance, not a new class. This is data-driven design.

class Character:
    GROWTH_RATES = {}  # Subclasses override

    def __init__(self, name, health, attack, defense):
        self.name = name
        self.health = health
        self.max_health = health
        self.attack = attack
        self.defense = defense
        self.level = 1
        self.experience = 0

    def level_up(self):
        rates = self.GROWTH_RATES
        self.level += 1
        self.max_health += rates.get("health", 0)
        self.health = self.max_health
        self.attack += rates.get("attack", 0)
        self.defense += rates.get("defense", 0)
        print(f"{self.name} leveled up to {self.level}!")

class Warrior(Character):
    GROWTH_RATES = {"health": 10, "attack": 3, "defense": 2}

class Mage(Character):
    GROWTH_RATES = {"health": 5, "attack": 5, "defense": 1}

w = Warrior("Conan", 100, 15, 10)
w.level_up()
print(f"HP: {w.max_health}, ATK: {w.attack}, DEF: {w.defense}")
# HP: 110, ATK: 18, DEF: 12

Benefits of data-driven design: growth rates can be loaded from a JSON file, changed without touching code, and tested independently. Game designers can rebalance characters without developer intervention.

A Battle is not a kind of Character — it does not have health, attack, or a special_ability(). Using inheritance here would violate the is-a test and the Liskov Substitution Principle: you could not pass a Battle to any function expecting a Character.

Battle has a "uses" relationship with Character — it receives two Character instances and orchestrates their interaction. This is composition/association:

class Battle:
    def __init__(self, char_a, char_b):
        self.char_a = char_a  # Uses, does not own
        self.char_b = char_b

    def fight(self):
        # Orchestrate turns between char_a and char_b
        ...

This illustrates the Single Responsibility Principle: Character is responsible for its own stats and abilities, while Battle is responsible for combat rules and turn order. Neither knows about the other's internal implementation.