Designing Combatant Data Structures

Hello! Welcome back to our journey into building a JRPG combat system.

In our last lesson, we designed the architectural "flow" of combat using a Finite State Machine (FSM). We now have a blueprint for managing the different phases of a battle: starting the fight, taking input, executing actions, and checking for victory or defeat. However, this state machine is currently just an empty shell. It knows what to do, but it doesn't have anyone to do it to or with.

Today, we'll breathe life into our system by defining the combatants themselves. This lesson focuses on our next learning outcome: Create a data structure for combatants (actors and enemies) with core stats (HP, MP, ATK, DEF, AGI). We will design the data "models" that represent our heroes and monsters, a task that should feel familiar given your experience with data modeling in web applications.

1. The "Database": The Heart of JRPG Data

In tools like RPG Maker, and in the design of many classic JRPGs, game data isn't hard-coded. Instead, it's stored in a collection of data files, collectively called the "database". This is conceptually similar to using a set of JSON files or a NoSQL database to define the entities in a web app.

This database contains definitions for everything: items, skills, and most importantly for us today, actors and enemies.

As you can see, actors and enemies are just two types of data within a larger, interconnected system. Today, we'll focus on designing the structure for these two specific types.

2. Core Combatant Stats: Quantifying Power

At their core, both player characters (Actors) and monsters (Enemies) are defined by a set of numerical attributes, or "stats". These stats govern their effectiveness in battle. Let's look at the standard set used in many JRPGs.

As the video explains, the most common stats are:

• Max HP (Hit Points): A combatant's health. If it reaches 0, they are knocked out.
• Max MP (Magic Points): The resource used to cast spells or use special skills.
• ATK (Attack): Governs how much physical damage a combatant deals.
• DEF (Defense): Reduces incoming physical damage.
• Magic Attack (MAT): Governs the power of magical spells.
• Magic Defense (MDF): Reduces incoming magical damage.
• Agility (AGI): Determines who acts first and can influence evasion.
• Luck (LUK): A wildcard stat that often influences critical hit rates, evasion, and the chance of inflicting status effects.

These eight stats provide a solid foundation for any classic JRPG.

3. Designing the Actor Data Structure

Actors are the characters in the player's party. Their data structure needs to hold not only their stats but also information about their identity, progression, and appearance.

In a system like RPG Maker, this is often split into two parts: the Class, which defines stat growth and learnable skills, and the Actor, which ties a name and visual representation to a Class.

Let's see how the documentation lays this out.

Based on this, we can envision a JavaScript class or JSON object for an actor's "definition" in our database:

// Example: In our database/actors.json
{
  "id": "actor001",
  "name": "Reid",
  "classId": "class001", // Link to a class definition
  "initialLevel": 1,
  "maxLevel": 99,
  "faceImage": "path/to/reid_face.png",
  "characterSprite": "path/to/reid_char.png",
  "battlerSprite": "path/to/reid_battler.png"
}

// Example: In our database/classes.json
{
  "id": "class001",
  "name": "Swordsman",
  "expCurve": { /* ...parameters... */ },
  "paramCurves": {
    "maxHp": [/* value at lvl 1, value at lvl 2, ... */],
    "atk":   [/* value at lvl 1, value at lvl 2, ... */]
    // ...and so on for all 8 stats
  },
  "learnableSkills": [
    { "level": 5, "skillId": "skill010" }
  ]
}

This structure separates the constant definition (the class) from the specific instance (the actor). During gameplay, your engine would create an instance of an actor that also tracks their current HP, MP, status effects, and equipped gear.

4. Designing the Enemy Data Structure

Enemies share the same core combat stats as actors, but their data structure is simpler in that they don't typically have levels or classes. Instead, their stats are fixed. They do, however, have unique properties related to the rewards they give upon defeat.

The Final Fantasy - Game Mechanics Guide provides an incredibly detailed look at how the original Final Fantasy defined its enemies. This is a perfect reference for the style of game you want to build.

As you can see from the FF guide and the RPG Maker documentation (in the "Enemy Settings" section), an enemy data structure needs:

• Core Stats: HP, MP, ATK, DEF, MAT, MDF, AGI, LUK.
• Rewards: How much Experience (EXP) and Gold the party receives.
• Drop Items: A list of items that might be dropped, each with a specific probability.
• Action Patterns: A list of skills the enemy can use. (We will design the AI for this in a later lesson, but the data belongs here).
• Elemental/Status Traits: Weaknesses and resistances.

A JSON representation for an enemy in our database could look like this:

// Example: In our database/enemies.json
{
  "id": "enemy001",
  "name": "Slime",
  "battlerImage": "path/to/slime.png",
  "stats": {
    "maxHp": 20,
    "maxMp": 0,
    "atk": 8,
    "def": 15,
    "mat": 5,
    "mdf": 5,
    "agi": 10,
    "luk": 10
  },
  "rewards": {
    "exp": 5,
    "gold": 10
  },
  "dropItems": [
    { "itemId": "item001", "chance": 0.1 } // 10% chance to drop a Potion
  ],
  "actionPatterns": [ /* ... to be defined later ... */ ]
}

{
  "id": "enemy002",
  "name": "Goblin",
  "battlerImage": "path/to/goblin.png",
  "stats": {
    "maxHp": 45,
    "maxMp": 0,
    "atk": 20,
    "def": 12,
    "mat": 5,
    "mdf": 8,
    "agi": 18,
    "luk": 12
  },
  "rewards": {
    "exp": 12,
    "gold": 20
  },
  "dropItems": [
    { "itemId": "armor005", "chance": 0.05 } // 5% chance
  ],
  "actionPatterns": []
}

5. An Alternative Design: Primary vs. Derived Stats

The model we've discussed, used by Final Fantasy and RPG Maker, can be called a Direct Stat Model. Stats like ATK and DEF are fundamental values that grow directly upon leveling up.

There is another common approach: the Derived Stat Model. In this design, you have a smaller set of primary stats, and the combat stats are calculated from them.

In a derived model:

• Primary Stats: Strength (STR), Agility (AGL), Intelligence (INT), Vitality (VIT). Players often allocate points into these on level-up.
• Derived Stats:
  • Max HP might be VIT * 10 + BaseHP.
  • ATK might be BaseWeaponDamage + (STR / 2).
  • Evasion might be directly based on AGL.

Which model to choose?

• Direct Model (our current plan): Simpler to balance and understand. The effect of a level-up is very clear. This is authentic to the FF1-5 and BoF1-2 style you're aiming for.
• Derived Model: Allows for more complex character builds. A player might create a "Strength-based Mage" who uses a magical sword whose damage scales with STR. It offers more player choice but is harder to balance.

For our project, we will stick to the Direct Stat Model as it aligns perfectly with our JRPG inspirations. However, knowing this alternative is a key piece of RPG design theory.

Conclusion

We have now defined the "nouns" of our combat system. We have a clear plan for the data structures that will represent both our heroes and our enemies.

Key Takeaways:

• Combatants are defined as data objects within a larger game "database".
• Actors (player characters) and Enemies share a set of core combat stats: HP, MP, ATK, DEF, MAT, MDF, AGI, and LUK.
• Actor stats are often defined by their Class, which dictates their growth over levels via parameter curves.
• Enemy stats are typically fixed and include additional data for rewards (EXP, Gold) and drop items.
• We are using a Direct Stat Model, where stats like ATK and DEF are fundamental, which is authentic to classic JRPGs like Final Fantasy.

Preview of the next lesson:
Now that we have combatants with an Agility (AGI) stat, we can use it. In the next lesson, we will begin implementing the logic of our combat FSM, starting with one of its most critical jobs: "Implement a turn-ordering system based on character agility." We'll explore different ways to decide who goes next, from simple turn-based rounds to more dynamic systems.