How Riot’s Game Data Server Streamlines LoL Property Data Management

Bill “LtRandolph” Clark, a Riot Games engineer, describes the goal of enabling testers to create content twice as fast as a typical LoL patch, a task that requires a robust data‑management solution.

Game Data Background

LoL stores two kinds of game data: key‑value property data (e.g., BlackCleaver HP bonus = 300) and opaque binary assets. The article focuses on property data, which historically lived in a loosely organized DATA folder as .ini files.

Problems with the Legacy .ini Approach

Editing with Notepad++ is error‑prone and leads to duplicate or missing fields.

Existing fields lack clear definitions.

No type safety.

Concurrent edits cause merge conflicts.

Multiple parallel versions (Live, PBE, internal) complicate workflows.

Loose file links with short names and hidden search paths.

Introducing the Game Data Server (GDS)

RiotGameDataServer.exe runs on each developer’s machine, exposing a JSON‑based RPC API that tools (e.g., Maya, Photoshop) can call. Swagger generates documentation for the exposed functions.

When a tool requests get?path=Items/BlackCleaver, GDS reads PROPERTIES/Items/BlackCleaver.json and returns the JSON payload. To modify a value, the tool sends

set?path=PROPERTIES/Items/BlackCleaver.FlatHPMod&value=1000

; GDS pulls the file from Perforce, updates it, and returns success or failure, allowing editors like RiotEditor to replace Notepad++.

Property Macros for Type Safety

Macros such as PROPERTY_CLASS, PROPERTY_START, PROPERTY, and PROPERTY_END annotate which class fields are editable and provide memory offsets for runtime loading, automatically inferring types and hiding non‑exposed fields.

Layered Versioning

GDS introduces “layers” – toggleable feature sets (e.g., a new champion, skin, or balance change). Activating a layer creates a parallel .APItemRework.json file that records only the deltas, enabling precise conflict detection when multiple engineers edit the same field.

Layers are grouped into game versions: Alpha (internal testing), Beta (public test server, inherits Release), and Release (live server). Moving a feature between versions is a simple drag‑and‑drop in the layer manager, eliminating massive file moves.

Conclusion

The GDS architecture dramatically improves LoL’s data workflow by providing a unified JSON RPC interface, type‑safe property definitions, and layered version control, solving most of the listed problems except the remaining challenge of loose file links, which warrants a separate deep‑dive.