A Pattern Born for Live-Service Games

Most games on Roblox are developed as live-service games. They are also called games as a service or simply live games. Regardless of the term we use, it just refers to games that use a recurring revenue model. Development doesn't stop after launch; the product is continuously upgraded and sold. This usually means that a decent chunk of development time will be spent creating content for the game: new cosmetic items, gameplay areas, storylines, promotional events. A lot of this work is done by artists and designers, and not necessarily programmers.

So, one of the top concerns for a live-service game is the frequency and regularity of its content updates. But there's a problem: players in multiplayer games talk to each other. They share personal knowledge and secrets of the game. which is good for community effects, but can have the unfortunate side effect of players consuming content much faster than they otherwise would. The problem gets worse the larger and more intertwined a game's community becomes. How easy is it for artists and designers to get their content into the game (and working)? How often can they do it without needing a programmer?

New game content often requires a part of the game logic to change or work with another part in unanticipated ways. Other times players have discovered a game-breaking strategy that demands a change to an integral part of the game logic. The code must be easy to change and debug: requirements that cut right across engineering concerns are inevitably introduced ("can you make me a gun that shoots swords?"), and it's important that the programming model doesn't resist change or fall apart in fundamental ways when it does happen. Different components of the game logic need to easily compose in a loose, decoupled way.

As experiences grow larger and more complex, there is an ever-increasing amount of data to worry about persisting. This may bring to mind things like players' storyline progress, collectibles, stats, and lifetime achievements, but it also includes things like item types, ability types, and even different areas and zones in the game. All of this data may one day be important for a live-service game. It needs to be kept in a format that's easy to store, inspect, and transform.

Content is data. Properly planning for it can have outsized impact on ease of development. ECS allows almost everything to be data-driven, from the schema of the game objects, to the various component parts of the game logic. Scott Bilas discovered this in 2002's Dungeon Siege; now, we're rediscovering it for Roblox.