Content Data #

Studios can use the Content Data system to create and interact with game content managed by the platform.

Types of game development content #

Game development content fits into two major categories:

  • in-game content managed by game engines–these are binary assets like textures, meshes, animations, sound effects, and VFX
  • platform content managed by a backend engine

These two categories share an identifier, but store different kinds of content; for example, a game client may have the concept of a unique ID called a “hat.” In the game’s codebase, this would have animations and textures for hats. On the platform side, there would be hat attributes, such as numerical bonuses.

Pragma Engine doesn’t manage the first type of data, but following platform content best practices supports excellent player and developer experiences.

Platform content #

There are several cases where data should be stored on a platform:

  • Entitlements: live-service microtransactions often need the platform to authoritatively store if a player has access to a specific item
  • Cross-platform: ownership data can be stored on the platform to maintain content across consoles
  • Hot-patching: attributes for in-game content stored on the platform allow for quick changes to content without needing to cut a new game client binary, game server, certification, and publication, all of which interrupt players with a new deployment
  • Progression systems: frontend UI often relates to data sourced from the platform. This content can be authoritatively owned by the platform to serve player-specific content such as XP or level in a battlepass

Data migrations for live games #

Game designers typically author content in JSON files, which are packaged up and deployed by a backend engine. The code an engineer writes to use the content data is called live data, which is data spawned on behalf of the player into a database. It’s important to consider how live data is managed, and the implications of designer content when it comes to the live data that has been spawned on behalf of players.

In a development environment, it’s easy to wipe the databases every time a design change is made. However, in a live environment, live data must be preserved and migrated, so a Content Handler must be used to translate database data for players to fit the new design. For more information on implementing Content Handlers, check out Defining Content Handlers.

Example: Iron Sword specifications

As an example, let’s take a look at a situation where a weapon called “Iron Sword” has a damage attribute that is randomly rolled between 5-10. The data for the weapon’s damage, rolled between 5 and 10, can be specified by a game designer using content data.

Once a player wants to acquire an Iron Sword, Pragma Engine can run player data Operations defined by the developer to create the Iron Sword for the player. This operation can then utilize logic to determine the sword’s damage based on the weapon’s content data definitions. The sword, along with its id and its rolled damage attribute number is then stored in the database on behalf of the player.

However, if the game team ever changes the design of Iron Swords from having generic a damage attribute to having three categories: stab, slash, and crush, the data for the Iron Sword stored on the database is no longer accurate because the generic damage attribute no longer exists.

Registered Content handlers are then used in these situations to load the old version and new versions of data, run a translation, and then update the database on behalf of the player so content data can be updated and changed by the game team with little friction.

Versioned content #

Pragma Engine also handles content versioning to make data migrations possible.

Tools are typically built up against a database to allow designers to update JSON blobs which are then stamped onto a database; however, this destroys records of the old data. Pragma Engine relies on Git as a version control system.

The Pragma Engine Operator Portal simplifies version control using the Content Catalogs Editor. Designers can edit an attribute, apply the changes, and test the changes in staging. This allows for live updating shards on demand for quick iterations. Note that at this point, changes will be stomped by the next package deployed.

Once the content is ready to be committed, use the Export button to get a packaged zip file with all the JSON files which is versioned and immutable. Content can then be committed by an engineer to Git, which builds and deploys versioned data.

Read more about the Content Catalogs Editor on the Game Operator Portal page.

Game Data
Content Data Architecture