Architecture

Data Structures! (Wait, don’t run, this is actually cool.)

There’s a problem in every game like this. You need a way to track minions, enemies, loot, combat states, equipment, and all the horrible things that happen in between.... here is my breakdown 

1. Static Components (The Book of Unchanging Truths)

This is the part of the game that never changes. It’s like the Evil Overlord’s sacred tome of knowledge—etched in dark runes (or, in this case, dark data tables).

• global.UnitTemplates – This contains every unit’s base stats, abilities, and item slots. If I need to know what a goblin is, I ask this list.
• global.ItemTemplates – A list of every item that could possibly exist in the game. Rusty swords? Check. Unholy relics of the damned? Check. A stick? Surprisingly, also check.

These are immutable truths. They do not change. They are the Law of the Dark Realm.

2. Mutable Lists (Where Chaos Reigns)

Here’s where things get spicy. This layer tracks actual gameplay changes—damage, XP, gear, and whether or not your goblin lost his sword in a fit of incompetence.

• global.PlayerParty – The minions under your control, their stats, gear, XP, and emotional baggage.
• global.CurrentEncounter – The enemies currently trying to ruin your day.
• global.Inventory – All the sweet loot you’ve picked up, including things you definitely shouldn’t have.

Everything in this layer can change at will. Your minions take damage, get stronger, or—let’s be honest—die horrifically and drop their items on the battlefield.

3. Runtime Objects (Bringing the Monsters to Life)

These are the actual moving, fighting, spell-slinging creatures that exist during combat.

• obj_minion – Player-controlled minions, animated and battle-ready.
• obj_enemy – The forces of good, complete with holy swords and an unreasonable hatred of your shenanigans.

When combat begins, we summon these objects from the Mutable List, let them fight, then save the survivors (if any) back into the list when the battle is over.

The Transformation Engines

Right, so we’ve got three big categories, but how do we move things between them? Enter the Three Great Machines of the Dark Lord’s Factory:

1. The Minter (Base → Mutable)

• Spawns new minions for recruitment.
• Generates enemy squads for a venture.
• Rolls loot drops and assigns them appropriately.

Example: Rolling a new goblin for your party.

var new_goblin = UnitMinter("goblin", { current_hp: 60 }); ds_list_add(global.PlayerParty.minions, new_goblin);

2. The Factory (Mutable → Runtime)

• Converts minions into combat-ready objects.
• Spawns enemies into battle.

Example: Sending a goblin into combat.

var unit_data = global.PlayerParty.minions[| i]; UnitFactory(unit_data);

3. The Packer (Runtime → Mutable)

• Saves battle survivors back into global.PlayerParty.
• Updates XP, item durability, and emotional trauma.
• Deletes minions who didn’t make it (RIP tiny gremlin).

Example: Saving a minion after battle.

var unit_data = ds_list_find_value(global.PlayerParty.minions,     ds_list_find_index(global.PlayerParty.minions, instance.guid, "guid")); unit_data.current_hp = instance.current_hp;

What This Means for You (The Evil Overlord)

• Minions are persistent. If your goblin survives, he keeps his battle scars.
• Enemies are generated dynamically. No two battles play out the same.
• Loot and XP persist. If you find a legendary artifact, it actually matters.
• The system is expandable. Need a new enemy? Add it to the template. Need a new item? Just define it and let the Minter do the rest.

Next Steps in the Evil Master Plan

📌 Refactor Existing Code: Move all units/enemies into UnitTemplates and ItemTemplates. 

📌 Test The Packer: Make sure dead minions don’t awkwardly resurrect when a battle ends. 

📌 Implement Dynamic Enemy Scaling: Because beating up baby knights isn’t fun forever. 

📌 Save/Load Implementation: Ensure that the game state persists between sessions (nobody wants a reset goblin army every time they quit).