Content Data Key Concepts #

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:

• Orders/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

Versioned content #

Pragma Engine 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.