Player-Friendly Atomic Game Modding

Like many game devs, I got my start making mods for other games. And if your experience was anything like mine, you'll recall brilliant creative highs punctuated by long tedious slogs sorting through obscure and poorly documented data formats, unless you were really unlucky and reduced to directly hacking binary files themselves. Modding is often difficult and error-prone both for the user and the consumer, but it gets even worse if you try combining mods.


This is a companion discussion topic for the original entry at http://www.fortressofdoors.com/player-friendly-atomic-game-modding/

The one question at the fore-front of my mind while reading this article was … “I wonder if they’ve tried using ECS (Entity-Component-System architecture?” You should really look into it (or if you already have, give it a second glance), its as data-driven as game-architecture can possibly get. ECS lends itself well to modding since game state is stored as components that house only data. All logic is handled by systems. It goes against OOP conventions but its well-suited to game development.
I imagine the team is too far along with DQII to make such a big paradigm shift but I hope its something you consider for future projects.

@dimumurray:

I’ve absolutely thought of ECS, but the design ship has sailed for the TDRPG engine (which powers the Defender’s Quest series). This code base dates back at least six or seven years now (first line of code was written circa 2010, first shipped in 2012), and there’d be no way to switch to ECS without rewriting the whole thing from scratch.

In practice we have something not totally unlike ECS, but it’s not really a true Entity Component System architecture. Maybe for my next game engine!