Hey, everyone! I’m Bill “LtRandolph” Clark, a League of Legends gameplay engineer. Many Rioters in engineering focus on the delivery of awesome content directly to players—a couple of my recent favorite examples include the newest champion, Jhin, and the support item reworks. My team, on the other hand, works to make that process faster and easier.

We have a simple goal: to allow Rioters on gameplay projects to create twice as much content for any given LoL patch. That’s easy to say, but it’s a challenging task.

Today, I’ll discuss the foundation that we’re laying down to power this acceleration: the Riot Game Data Server (GDS). While this will be a technical article, I’m going to keep the commentary at a fairly high level. If you’re an engineer working with data spread across a number of systems, I hope this will be of particular interest.

Game Data Let’s start with some background. Working on LoL, there are two types of game data: key-value pairs called property data (e.g. Black Cleaver HP bonus is 300), and blobs of opaque binary data (e.g. textures, animations, and sounds). In this post, I’ll only be discussing property data and will leave binary data for a potential future post. For all of LoL’s history, property data has consisted of a bunch of loose files sloshing around in a big bucket of a folder called DATA. Within that folder, we stored the data primarily in .ini files (yes, the Windows .ini file format). It looks like this: Not the prettiest interface