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 inventory databases every time a design change is made. However, in a live environment, live data must be preserved and migrated–in this case, 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: Weapon specs

As an example, let’s take a look at a situation where an item spec determines that a sword can have a damage attribute that is randomly rolled between 5-10. This is content specified by a game designer.

Once the player obtains the sword, the logic is run, and the sword and its related damage attribute number is stored in the database on behalf of the player.

Later, the game team may want to change the design of swords from having generic damage to having three categories: stab, slash, and crush. At this point, the information stored on the database on behalf of the player is no longer accurate, because generic damage no longer exists.

Content handlers are registered at this point to load the old version and new versions of data, run a translation, and then update the database on behalf of the player.

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 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 Portal Provided Functionality page.

Game Data
Content Data Architecture