TL;DR:
-
Mods in Age of Empires II: Definitive Edition remain functional but require repeated structural updates after game patches.
-
The core issue is lack of fine-grained data inheritance, not complete mod breakage.
-
I propose a partial data override system (delta-based mod layer).
-
This could significantly reduce long-term maintenance cost and improve forward compatibility for legacy mods.
1. Problem Context
Hello everyone,
I’d like to share an idea regarding long-term mod compatibility in Age of Empires II: Definitive Edition.
This is a commonly discussed topic within the modding community, especially among long-term mod authors.
This is not about mods becoming unusable after every update.
In most cases, mods remain functional. However, as the game’s data structure evolves over time, legacy mods gradually fall behind the latest architecture. While still usable, they often cannot naturally benefit from new data structures, improvements, or additions introduced in later updates.
2. Current Limitations
- Mods often rely on full or large-scale data replacement.
- Structural changes can require manual re-alignment even if gameplay intent is unchanged.
- Lack of fine-grained inheritance leads to increasing maintenance cost over time.
- Legacy mods diverge from current data schema even when functionality remains valid.
3. Proposal: Partial Data Override Model
One possible direction would be to introduce partial data overrides (field-level inheritance / delta-based modding).
Instead of replacing entire data objects, a mod would:
- Override only the fields it modifies
- Inherit all remaining values from the latest official dataset
Conceptually:
Base Game Data + Mod Delta Layer = Final Runtime State
4. Expected Benefits
- Reduced long-term maintenance cost for mod authors
- Improved forward compatibility across updates
- Better sustainability for large or long-running mod projects
- Clear separation between gameplay intent and underlying schema evolution
5. Risks and Considerations
- Increased complexity in data merge logic
- Need for clear rules on mod stacking and conflict resolution
- Potential runtime performance considerations
- Schema evolution management across versions
6. Open Questions
- Should overrides be strictly field-level, or support partial object patches?
- How should multiple mods interact in stacking scenarios?
- Should schema versions be explicitly exposed for compatibility targeting?
- Would a declarative diff system be preferable to implicit inheritance?
7. Closing
I understand that the game must continue to evolve and that internal data structures may need to change over time. This proposal is not intended to restrict future development, but rather to explore whether a more modular data model could reduce long-term mod maintenance costs while preserving flexibility for the development team.
I’d be interested in feedback from both developers and modders.
Thank you for reading.