Inspiration
I wanted to play the complete Baldur's Gate saga solo without losing access to the strategically important systems the game normally distributes across several party specialists. A native Fighter/Mage/Thief covers combat, arcane magic, and thief utility, but it cannot become a Cleric: the Infinity Engine supports no four-class combination, and several Cleric systems are bound directly to native class behavior.
I looked for an existing mod that reproduced the combination I needed and could not find a working implementation, so I began building one for myself.
What it does
Super Agent Core preserves the engine's native Fighter/Mage/Thief multiclass and adds the missing Cleric contribution:
- an XP-derived synthetic Cleric level;
- a complete seven-circle divine spellbook;
- level-based spell circles, memorization slots, and caster behavior;
- normal Wisdom bonus priest-spell slots;
- a functional Turn Undead action driven by the same synthetic Cleric level;
- native Fighter, Mage, and Thief systems left under engine control.
The result is one character that can access the essential combat, arcane, divine, and utility roles Baldur's Gate normally expects a party to split among several characters.
How I built it
The competition build is a WeiDU mod with an EEex runtime layer. It reads the installed game's own Cleric XP table, derives an independent Cleric level from the character's earned experience, and uses that value for divine progression, spell scaling, and Turn Undead.
The implementation is deliberately compatibility-first. Ordinary characters delegate to the exact native caster result, the fourth-class behavior is gated to the Super Agent Core kit, and unsupported executable signatures fail safely.
GPT-5.6 helped me develop the concept, map the engine constraints, compare possible workarounds, and shape the high-level technical strategy.
Codex performed most of the concrete implementation work: investigating engine boundaries, writing WeiDU, Lua, EEex, and Python code, constructing regression and packaging checks, building diagnostics, and iterating from failures observed in the real game. I directed the product goal, requirements, priorities, interactive validation, and architectural decisions.
The key challenge
The first architecture used a native Fighter/Mage/Cleric and tried to reconstruct thief behavior. Codex could make a shop-theft button appear, but the engine would not complete the native theft transaction. A rejected native-hook experiment also demonstrated how dangerous it was to fight the engine at that boundary.
I proposed reversing the architecture: keep the hard-coded thief behavior native and synthesize Cleric instead. That decision produced the current Fighter/Mage/Thief foundation plus the isolated Cleric subsystem.
What works in the release candidate
The submitted Windows release candidate is v0.2.0-rc.1.
- Priest-book access, memorization, rest, casting, and save/reload were exercised in the game.
- The synthetic caster-level adapter passed Core, ordinary Fighter/Mage/Thief, native-Cleric, and forced-fallback controls.
- Armor of Faith produced the expected 25% result at synthetic Cleric level 50.
- The Turn Undead button appeared without reordering the remaining native action bar and repeatedly destroyed verified Skeleton Warriors at synthetic Cleric level 50.
- The frozen release checkpoint passed 108 automated tests, source validation, WeiDU parsing, deterministic package validation, clean installation checks, and GitHub Actions.
What I learned
The important distinction was not between "possible" and "impossible," but between ordinary kit abilities and engine-owned class transactions. A visible interface is not proof that the native class behavior behind it has been reproduced. The successful design minimizes replacement: the engine owns Fighter, Mage, and Thief; the mod owns only the missing Cleric layer.
What's next
The current scope intentionally defers Cleric HLA support, broad Cleric-only quest and stronghold recognition, an exhaustive low-level Turn Undead parity matrix, expanded mod-stack compatibility testing, and displaying a fourth level in an interface designed for only three native multiclass fields.
Platform and installation
The tested route is Windows 10/11 with Baldur's Gate II: Enhanced Edition 2.6.6.0, EET 13.4, and official EEex v1.0.0. EEex and the game are external prerequisites and are not redistributed. Judges can install the prepared ZIP through the included WeiDU installer without rebuilding the project.
Unofficial fan content
This is an unofficial, free fan modification. It is not approved or endorsed by Wizards of the Coast, Beamdog, BioWare, or the respective rights holders. Baldur's Gate, EEex, EET, and their assets remain the property of their respective owners.
Log in or sign up for Devpost to join the conversation.