Pragma is designed as a backend game engine. This means giving studios full control and customizability of their platform. This post will describe some of the features and characteristics of the engine approach, and will compare and contrast this to a managed online services offering.

The engine approach #

Full control #

Video games are a deeply creative and technical effort. Every game seeks to innovate in some way, whether that’s in art style, graphical fidelity, gameplay, social, metagame, or live systems. Studios need the flexibility to build out features that are custom fit to their needs. 3D game engines such as Unreal or Unity don’t build a game for you, instead they provide a rich set of tools, systems, and workflows that provide the building blocks for developing games. Currently studios striving to ship a live service game must build their platform stack from scratch, or hope that their needs are met by a managed service.

Pragma’s objectives are to provide:

• A massively scalable architecture (we’ve shipped some of the largest games in the world).
• Rich integration patterns that include configuration, code plugins, and fully custom backend services.
• Source code access for studios that need to modify the engine itself.

Core services #

Live service games are a living product that run 24/7 to provide a compelling experience for players. This includes running a game economy, selling content, running events, and building a vibrant social ecosystem.

Pragma comes equipped with a cross-platform accounts service, a server based matchmaker that can power social and competitive games, content management features including data versioning and migration, and a rich data pipeline. Pragma comes equipped with the core services necessary to ship and support a successful live service game. These services serve as a foundation and are designed to be customized to a studio’s needs. We don’t believe there are one-size-fits-all solutions to live services given the unique needs of every game. The core services include:

• Accounts

• Game Loop

  • Lobby
  • Matchmaking
  • Game Allocation
  • End of Game Processing

• Player Data

  • Inventory
  • Progression
  • Loadouts

• Data + Telemetry

  • Metrics and monitoring
  • Telemetry and big data

• Store

  • Real Money Purchase + Fulfillment
  • Entitlements
  • Battle pass and events
  • In-Game store and currencies

Game Economy #

In order to support an in-game economy, transactions and game content must be managed on secure servers that adhere to security best practices and prevent players from exploiting loopholes to gain unauthorized access to game content.

Pragma is designed as an authoritative platform, deployed to all major cloud providers, that comes equipped with the tools needed to accept payments, manage game content, and support live player data and transactions. 

Managed solutions #

Some services offer online APIs designed to offer online capabilities without the burden of managing infrastructure or building custom platform features. Examples include Steamworks, Epic Onlines Services, and Playfab.

These solutions are easier to get started with, don’t require that studios manage their own cloud infrastructure, but offer a more limited feature set with less customizability.

API-based #

What’s nice about a managed approach is that the infrastructure is hosted by the service provider, which means studios just need to sign up and start utilizing the available apis directly.

One inherent restriction however is that studios are bound to only the apis available by the service. If your game needs a feature that isn’t available, the only option is make due without, or else start building your own custom platform stack. As soon as you do this however, you’ve now shifted to the self managed, custom platform approach.

Client authoritative #

Because your studio doesn’t operate its own servers, the api must trust the game client. This makes it easy for players to fake their accomplishments, for example Steam achievements are famously easy to grant without completing the in-game challenges that are supposed to be completed in order to unlock the achievement badge.

There are a couple of options available that can help make features more secure, but each has its own limitations. One example is cloud scripting features, in which studios can upload code to the managed service to be executed on the provider’s platform. While this can work for simple use cases (such as retrieving a player’s inventory and making an update), it doesn’t allow for optimized workflows and makes testing and data migration difficult.

With regards to optimization, many techniques for writing scalable game services rely on in-memory concurrency patterns that achieve orders of magnitude better performance than distributed locking or shared storage patterns. These techniques are not available to cloud scripting solutions.

With regards to testing, cloud scripting prevents any kind of local development workflows. This means testing various configurations, data models, or patterns oftentimes impacts an entire studio sharing one managed environment. In addition, live data migrations are some of the hardest systems to build robustly. Within the context of a managed service, performing data snapshots, rollbacks, and creating rigorous patterns for testing refining these patterns are unavailable due to the nature of not having access or control of the underlying data store and systems.

Use cases #

Despite these restrictions, using a managed service can make sense in a number of contexts.

First, for studios who plan to sell their game upfront for a fixed price, they may not need the ability to manage a live service economy. In this case, client authoritative patterns are fine because players who abuse this are simply cheating themselves of the experience of playing the game.

Second, early in development using a managed service may allow a studio to spin up quickly and focus on core gameplay features. However care must be taken not to over-invest in the managed solution, otherwise when the studio grows out of it, they may find themselves facing a daunting path to rebuilding everything themselves on a custom stack. Ideally the studio can transition off of the more limited managed service into a more robust offering such as the engine approach when they are ready.

Summary #

The engine approach to live services gives studios full control, customizability, and the confidence that they can implement any feature they dream up. This necessitates building some platform knowhow within the studio while avoiding the need to build an entire platform and operations team from scratch.

The managed services approach offers a quick and easy start with a limited feature set and little customizability. For teams primarily focused on single player games with some limited multiplayer features, this may do the trick. If the objective, however, is to build a rich live service game, care should be taken to not over-invest in a managed platform without first planning a clear transition path to an engine based offering or custom stack when the team grows out of the managed service’s limited feature set.