Rebuilding Pokémon with Object Oriented Programming

Rebuilding Pokémon battle mechanics with object‑oriented design

Purpose and approach

• A tutorial-style design exercise showing how to model Pokémon-style turn-based battle mechanics using object‑oriented principles.
• Top-down design: define how types are used (moves, attempts, effects, conditions, numbers, targets) before implementing internals.
• Emphasis on creating effective abstractions to reduce complexity, make illegal states impossible, and enable future extensibility.
• Tradeoffs discussed:
  • expressivity and ergonomics (domain-specific types) vs minimal/fundamental combinators
  • mutability vs immutability
  • pure object‑oriented approach vs delegates/functional techniques

---

Core type system and responsibilities

IMove

• Interface for moves. A move has a name, element (type), and an IAttempt.
• Moves can be decorated:
  • WithPrecondition(ICondition<Battle>) — checks preconditions and yields “but it failed” messages.
  • WithApplicability(ICondition<Battler>) — checks battler-level applicability and yields “but it didn’t affect the target” messages.
• The decorator pattern is used to wrap moves with conditions.

IAttempt

• Represents a single attempt/execution unit: execute(Battle) → void.
• Types of attempts:
  • Leaf Attempt: contains animation, accuracy (ICondition<Battle>), and onHit / onMiss / after effects (IEffect).
  • Cascade: sequence of IAttempts executed in order but stops when a hit fails (models Triple Kick).
  • Combo: single accuracy roll, then repeated animation + effect N times where N is an INumber resolved from battle context (models Fury Attack).
• Animations live on attempts (not moves) so multiple attempts can have distinct animations.

---

Conditions (ICondition<T>)

• Generic predicate interface: check(T) → bool.
• Combinators: And<T>, Or<T>, Not<T>.
• Probability/Chance condition to model accuracy and other random boolean checks.
• Number comparisons: LessThanOrEqual, GreaterThanOrEqual over INumber.
• Battler conditions examples: HasElement, IsParalyzed.
• Lifting: For (ITarget + battler condition) lifts battler-level conditions into battle-level conditions by selecting attacker/defender via ITarget.

---

Targets (ITarget)

• Selector interface: resolve(Battle) → Battler (examples: Attacker, Defender).
• Used by conditions, numbers, and effects to choose which battler is referenced.

---

Effects (IEffect)

• apply(Battle) → void. Effects mutate the battle context.
• Combinators:
  • Sequence: execute multiple effects in order (always continues).
  • Conditional effect: if/else effect based on an ICondition<Battle> (use a no‑effect default to avoid null).
• Domain effects (examples):
  • FormulaDamage(INumber) — standard Pokémon damage formula (attack/defense, type effectiveness, STAB, RNG).
  • DirectDamage / CrashDamage — bypasses formula; target specified (attacker/defender).
  • OneHitKO, Faint, RestoreHP(INumber), Drain (damage → heal), ApplyParalysis(target), StatChange(target, INumber).
• Null Object pattern: NoEffect used as default instead of null.

---

INumber (deferred / composable numeric values)

• Evaluate(Battle) → double. Allows numbers to depend on battle context or randomness.
• Concrete implementations:
  • Exactly (constant).
  • Between(min, max) — uniform random between bounds.
  • Weighted — choose a value with given probabilities.
  • Domain numbers that inspect targets: MaxHP(target), CurrentHP(target), Level(target), LastDamageDealt (battle-scoped).
• Combinators: Sum, Product, Quotient to combine numbers (enables expressions like maxHP * 0.5).

---

Key domain modeling patterns and rules

• Use the Decorator pattern for move wrappers (preconditions/applicability).
• Build complexity from small pieces using combinators for conditions, numbers, and effects.
• Separate attempts, effects, and moves to support multi-attempt moves (animations per attempt, different effects per attempt).
• Semantics:
  • Cascade: stops on miss.
  • Combo: one accuracy roll, repeated hits based on an INumber.
• Make illegal states impossible by encoding constraints (e.g., lifting battler conditions to battle-level selectors, distinguishing precondition vs applicability for proper message semantics).
• Use constructor overloading and null‑object defaults for convenient instantiation.
• Place RNG and shared context in Battle so conditions and INumber use a consistent random source.

---

Example moves (illustrative instantiations)

• Tackle
  • Single attempt, 95% accuracy, FormulaDamage(Exactly 40).
• Body Slam
  • Single attempt, formula damage 85 plus 30% chance to apply paralysis (onHit includes Sequence of formula damage + conditional paralysis).
• Triple Kick
  • Cascade of 3 attempts (each 90% accuracy), damages 10 / 20 / 30 respectively; cascade stops if a hit misses.
• Fury Attack
  • Combo with single 85% accuracy roll; hits between 2–5 times determined by a Weighted INumber; each hit does FormulaDamage(15).
• Jump Kick
  • Attempt with onHit = FormulaDamage(100) and onMiss = CrashDamage(target=attacker, damage = Product(MaxHP(attacker), Exactly 0.5)) — example of self-damage on miss.
• Thunder Wave
  • Move wrapped with WithPrecondition(Not(For(defender, IsParalyzed))) and WithApplicability(Not(For(defender, HasElement(Ground)))) plus 90% accuracy paralysis on hit — demonstrates precondition vs applicability semantics and decorator layering.

---

Visualizations and code diagrams

• The speaker uses informal object-graph diagrams to show composition: Move → WithPrecondition → WithApplicability → Attempt → Effects → INumber → Targets.

• Emphasizes readability and expressiveness of move definitions using the composed types.

---

Design notes and recommendations

• Keep moves immutable; allow battle/turn to be mutable or support an immutable mapping from Battle → Battle if desired.
• Put RNG and shared context in Battle to make behavior reproducible and easier to test.
• Prefer expressive domain types for ergonomics, but avoid duplication by using composition.
• If the language supports delegates/functional constructs, the implementation could be simplified; this example focuses on purely OO constructs to demonstrate feasibility.

---

Resources

• Speaker references a book: “The Object Oriented Way” (link in video description) for deeper reading.

Main speaker / source

• The video presenter (unnamed in the subtitles) — the same person who promotes the book “The Object Oriented Way.”