Data-Driven Game Engines: Clean Pipeline Comparison

A data-driven game engine is one whose content — levels, entities, stats, balancing, even behavior — lives in data files the engine reads and interprets at runtime rather than in compiled code, so a designer can change the game without an engineer rebuilding it. The engines that take that idea furthest in 2026 fall along a spectrum. RPG Maker MZ makes the entire game a JSON database. GDevelop saves the whole project as one JSON file. GameMaker stores rooms and objects as JSON resources. Unity gives you ScriptableObjects and lets you design your own data pipeline. Godot makes its resources human-readable text. At the opposite end sits MonoGame, an honest contrast — a code-first framework with no built-in data model at all.

This comparison ranks those engines by how central data-driven design is to building a game in them, is honest about where each falls short, and keeps two distinctions straight: data-driven design is not data-oriented design, and JSON is only one of several formats that can carry data. For what JSON itself is and why the approach wins, the JSON in game development explainer covers the format; this article ranks the engines.

The engines, compared#

The table reflects the spectrum: from engines whose entire product is data, to engines that hand you the parts and let you decide.

Engine	Data model	Best for	License / cost
RPG Maker MZ	The whole game as a JSON database	Story-driven RPGs, no code	Paid, one-time
GDevelop	The whole project saved as one JSON file	Free data-driven 2D, no code	MIT, free
GameMaker	Rooms and objects as JSON resources (.yyp)	2D with code, polished pipeline	Free non-commercial; $99.99 one-time commercial
Unity	ScriptableObjects — you design the data pipeline	2D/3D teams, custom pipelines	Free tier; paid tiers
Godot	Human-readable text resources (.tres, .tscn)	Open-source, code-centric data editing	MIT, free
MonoGame	None built in — code-first framework	Full control, code-heavy	MIT, free

Now what each is actually like, and where it falls short.

1. RPG Maker MZ — the game is the data#

RPG Maker is the engine that takes data-driven design to its genre limit: an entire role-playing game — actors, classes, skills, items, enemies, tilesets, animations — is a set of JSON files in the project's data/ folder (Actors.json, Items.json, Enemies.json, and so on). You edit all of it through a database screen, never touching code, and the engine interprets that data into a running game. For its genre the payoff is enormous: a complete, balanced RPG with zero programming. The trade-off is the inverse of the strength — the engine is shaped around one genre. The moment you want something the database cannot express, you are fighting the tool rather than using it. Data-driven, but within rigid walls.

2. GDevelop — the project is one JSON file#

GDevelop is data-driven to the root: the entire project — objects, behaviors, scenes, events, variables — is saved as a single JSON file. There is no hidden binary blob and no proprietary database; the game is text you can read, diff, and even hand-edit. For a no-code 2D project that wants maximum transparency, that is hard to beat, and the MIT license adds no revenue caps or royalties. The trade-off is flexibility at the edges. Because the engine is built around its own event system and object model, stepping outside what those describe means working against the grain, the way it does in any highly structured no-code tool.

3. GameMaker — rooms and objects as JSON resources#

GameMaker treats the building blocks of a game — rooms (levels), objects, sprites, sounds — as resources, and its .yyp project file plus the per-resource files are JSON. That makes the project diff-friendly and scriptable, which matters for teams and for any external tooling you build around the pipeline. Pair that with GML, GameMaker's own language, and you get a 2D engine that is comfortable for programmers who also want a clean, data-driven authoring layer. The trade-off is that GameMaker is firmly a 2D tool and that the data layer is designed by the engine's creators — you edit within their resource model, not one you define. Pricing is free for non-commercial use and a one-time $99.99 for a commercial license.

4. Unity — design your own data pipeline#

Unity does not hand you a fixed data model; it hands you ScriptableObjects — data assets you define yourself — and says "build the pipeline you need." You create a Weapon ScriptableObject, give it the fields you want, and instances of it become editable data assets in the project. Add JsonUtility for JSON serialization, and you have a fully data-driven layer whose shape you designed. The strength is flexibility: teams building anything from 2D puzzlers to 3D RPGs can shape the data model to the game. The trade-off is that the design is on you. There is no single right data model, no enforced convention, and a large project can accumulate several inconsistent ones unless someone sets the standard. Powerful, but it does not tell you what to do.

5. Godot — data you can read#

Godot's resources are stored as text — .tres for resources, .tscn for scenes — that are human-readable and built for version control. It is not JSON (Godot has its own concise text syntax, with JSON available as an option), but the principle is the same: the game's content is editable data, not compiled code. You define a Resource type, fill in instances, and reference them across the project. The strength is openness and readability — you can diff a scene change line by line — combined with an engine that treats resources as a first-class concept. The trade-off is that, as in Unity, the resource model is something you design and discipline yourself within; Godot gives you the format, not a prescription.

MonoGame — the honest contrast#

MonoGame is on this list to anchor the other end of the spectrum. It is a code-first framework — the open-source successor to Microsoft's XNA — with no built-in data model and no editor. If you want data-driven design in MonoGame, you build all of it yourself: you define the data, you parse JSON with a library such as System.Text.Json, you write the loader, you decide the schema. That is total control and total responsibility, and it is exactly why a code-first framework is not the same thing as a data-driven engine. MonoGame does data-driven only after you put in the work that RPG Maker or GDevelop give you for free.

How to pick by your goal#

The fastest way to choose is to match the engine to what you are building.

• You want a story RPG with no programming → RPG Maker MZ. The database is the game.
• You want free data-driven 2D with total transparency → GDevelop. One JSON file, MIT license.
• You want a polished 2D pipeline and are happy in code → GameMaker. JSON resources plus GML.
• You want to design your own data model for a larger project → Unity. ScriptableObjects, your way.
• You want open-source, readable data, and code-centric control → Godot. Text resources, MIT.
• You want full control and will build the data layer yourself → MonoGame. Code-first, bring your own everything.

Data-driven is not data-oriented#

This distinction matters because the words are close and the ideas are unrelated. Data-driven design is about authoring: it says your game's content lives in data files a designer edits, separate from code. Data-oriented design is about performance: it says you lay data out in memory — flat, contiguous arrays — so the CPU can stream through it fast. An engine can be data-driven without being data-oriented (RPG Maker's JSON database is the opposite of cache-friendly), and it can be data-oriented without being data-driven. The two solve different problems and often coexist: author content as data, then arrange the hot parts of it for the cache. Do not let the shared word "data" fool you into conflating them.

Common mistakes#

Mistake	What goes wrong	What to do instead
Treating JSON as the architecture	You pick a format instead of separating data from code	Decide data-vs-code first; JSON is one carrier among several
Confusing data-driven with data-oriented	You expect readable data files to also be fast, or vice versa	Author as data for designers; lay out hot data for the cache
No schema and no versioning	A format change silently breaks saves and mods	Validate the data and version it with a migration path
Picking a fixed-database engine for the wrong genre	You fight RPG Maker's data model to build something it cannot express	Match the engine's data model to your game's shape
Building the data layer last, in a code-first engine	Data-driven becomes an afterthought bolted onto compiled logic	Design the data model up front, even in MonoGame

Where Egmatic fits#

There is a pattern across this list. The engines that treat data-driven design as a finished, opinionated system — RPG Maker and GDevelop — are maximally data-driven but rigid within their model. The big general engines — Unity and Godot — give you powerful data tools but leave the model for you to design and discipline. MonoGame gives you nothing and demands you build all of it. Egmatic is built for the gap between them: a 2D-first editor and engine on the MonoGame runtime whose entire architecture is data-driven by construction. The editor authors the game; the engine plays it; and the only thing that passes between them is a versioned JSON contract — no shared code, only the data.

That is data-driven design taken to its cleanest form: the editor and the runtime agree on one data format and nothing else, so the pipeline cannot drift the way it can when code and data are tangled together. For 2D games, where content is the bulk of the work, having the game be data is the point. For the format that carries it, the JSON in game development explainer covers the details, and the scene graph explainer shows how that data describes the world once the engine loads it.

The bottom line#

The engines that take data-driven design furthest are RPG Maker MZ (the whole game as a JSON database), GDevelop (the whole project as one JSON file), GameMaker (rooms and objects as JSON resources), Unity (ScriptableObjects you design yourself), and Godot (human-readable text resources), with MonoGame as the honest contrast of a code-first framework that has no data model at all. Pick by what you build: a fixed database for a genre piece, an opinionated no-code project for transparent 2D, a design-your-own pipeline for a larger team, or a from-scratch layer for full control. And hold two distinctions: data-driven design is about authoring content as data, not about cache performance; and JSON is one format that carries data, not the architecture itself. A 2D-first tool whose editor and engine share only a versioned JSON contract — like Egmatic — is data-driven design at its cleanest.

---

Sources#

1. Data-driven design — gameplay content and parameters defined in data the engine interprets at runtime — Wikipedia: Data-driven programming
2. RPG Maker MV/MZ database — actors, items, enemies, and skills stored as separate JSON files — RPG Maker Wiki: Database
3. GDevelop project format — the entire project saved as a single JSON file — GDevelop wiki: Project manager
4. GameMaker project format — the .yyp project file stored as JSON — GameMaker Manual: Project format
5. GameMaker pricing — free for non-commercial use, $99.99 one-time for a commercial license — GameMaker: Get
6. Unity ScriptableObjects — data assets that let you design a data-driven pipeline — Unity Manual: ScriptableObject
7. Godot resources — .tres and .tscn human-readable text formats — Godot docs: TSCN file format
8. MonoGame — the open-source successor to Microsoft XNA, a code-first framework with a content pipeline — MonoGame docs: Content pipeline
9. Data-oriented design — arranging data layout in memory for CPU cache performance — Wikipedia: Data-oriented design