Appearance
Appearance
The Metaplay SDK provides a set of tools and libraries for implementing online-enabled games using the Unity game engine. It can be used to develop anything from simple single-player games with state persisted on the server, all the way to full real-time games with complex social interactions.
Metaplay-enabled games consist of the following components:
Metaplay is designed for top-grossing mobile F2P development, meaning that the underlying architecture choices and programming patterns are fundamentally scalable to tens of millions of players.
Nowadays in most mobile games, social features are an integral part of the game itself. Even most single-player games are run from servers to ensure that the developer can balance, update, and protect games from cheating and hacking. Developers need a lot of technology, tools, and logic in the background to enable the development and operation of these types of games.
Here is where Metaplay comes in. Developing technology is no small undertaking and in many cases requires an entirely different skill set than what goes into developing games. This is the reason why game engines like Unity 3D and Unreal are so popular; it's far easier and faster to take a ready development environment with all the tools than it is to build something from scratch.
Metaplay is highly flexible in the types of games that it is easily adapted for:
Single-player games with server-side persisted state and cheat-proof game logic
Examples: puzzle games, idle games, high score attacks, casino games, etc.
Games with deep meta or social features like guilds and live events
Examples: city builders, card collecting games, MMOs, etc.
Server authoritative real-time games
Examples: builder games with RTS battles, card games, arena brawlers, etc.
Basically, Metaplay does not have specific limitations on what kind of game interactions can be developed, instead, we invite you to invent something new that pushes the boundaries of what is possible in games today. We focus on making it as easy as possible to develop your own online game in a scalable and robust way from the first prototype to global deployment and years of further development.
While Metaplay is customizable for many needs, there are some areas where other alternatives should be considered:
One of Metaplay's core features is the ability to write game logic code in C# and then use the same code in the client and the server. Thus, there is no need to double-implement features, once on the client and again for the server.
Code sharing can be used to great effect when developing server-authoritative games where checking every action’s validity introduces undesired network lag. The client can handle the player's actions with immediate feedback by predicting the server’s answer via shared code, which the server can then validate after-the-fact.
There are also some limitations introduced by code sharing. Any game logic code always needs to produce identical results on the client and server for validation to be possible. Most often this means replacing floating-point numerics with fixed-point ones, ensuring that any random number generation is seeded identically on both ends and that any value collections used to provide a consistent iteration order (eg, using SortedDictionary<Key, Value>
instead of Dictionary<Key, Value>
).
Both the client and server source code should reside in a shared source repository to make it easy to ensure whether a client connects to a server built from the exact same version. During the development of a game, it is best to only allow exact versions to talk to each other to avoid spending time dealing with versioning conflicts. In staging and production, a more lenient versioning policy is often desired.
Metaplay SDK includes a simple mock server that is embedded into the game client. This enables most development of the game to be done without having any kind of external service, local or cloud-based. In practice, this means that the daily development flow is very similar to regular Unity game development.
The main reason for using the offline mode is to keep the bulk of development as rapid as possible: there is no need to rebuild or restart the server, leading to faster iteration times. As it is the exact same code that gets compiled to the server as well, the developed features usually work with a real server without further modifications.
Typically, a new feature can be implemented fully, or almost fully, using the offline mode, followed by testing using a locally deployed server. With more complex features, additional work may be needed to support the feature in the mock server. For example, implementing a battle game with a matchmaker requires having a mock matchmaker in the mock server.
While most game development typically happens in offline mode, more server-related features do require building and running the real server. With Metaplay, the server is a standard C# .NET Core project with minimal dependencies, which can be run directly from Visual Studio or using the .NET command-line tools.
When running the server locally, standard C# development tools can be used. For example, C# debuggers and profilers built into Visual Studio work as expected.
The local server can be configured to use either an embedded SQLite database (which works without installing any external dependencies) or a locally installed MySQL.
Metaplay comes with tools for easily ingesting data from .csv files, as well as (optionally) fetching those .csv files directly from Google Sheets directly from inside Unity. When working in Offline Mode, it is even possible to fetch and load any updated .csv files while the game is running.
The config file importers use powerful reflection-based parsing, which is able to import game-specific data structures without writing a single line of code. This keeps the workflow as lean as possible, as data types can be added, modified and removed without any extra effort spent on updating the config importer.
Metaplay ships with full support for deploying the game servers into the public cloud. All required infrastructure is provisioned in the game developer's own account, meaning that all game data remains under the developer’s control.
Currently only AWS is supported as the leading cloud provider for games, but support for other cloud vendors may be added in the future.
Metaplay uses modern cloud-native technologies which aim to minimize manual operations work. Self-healing technologies are used to automatically recover deployments from most error scenarios. Industry-standard monitoring and alerting tools included in every deployment help catch any errors requiring manual intervention as early as possible.
The infrastructure provisioning is built using Terraform. Metaplay ships with built-in infrastructure modules for easy deployment of small development environments as well as larger production environments. The infrastructure modules themselves are built from smaller component modules, which can be used to customize deployments further with custom game services as needed.
Game servers are deployed as docker containers into a managed Kubernetes cluster. Managed MySQL databases (eg, AWS Aurora RDS) are used for persisting the game state.
TIP
Some familiarity with backend technologies is required to be able to use Metaplay efficiently beyond internal development. At least basic working knowledge of AWS, Terraform, Kubernetes, MySQL, and monitoring of live systems should exist within the team when going into production.
Metaplay SDK includes a bot client framework for building bots specific to the game. The primary purpose of the bot client is to act as a load- or simple automated QA tester for the game. Using automated tests regularly helps build confidence in the game backend's correct behavior and performance at scale before deploying the game to production.
Bots can be modified to simulate the behavior of real players as closely as desired. This enables load tests to be reasonably representative of real-world scenarios.
Scripts and infrastructure components for deploying bots are included with Metaplay. They are deployed into a separate short-lived ECS Fargate cluster so no extra testing infrastructure needs to be managed by the development team.
Bots are usually developed and tested locally before deploying to the cloud for load-testing. They can also be run locally during development for other types of automated testing.
The Metaplay SDK includes a LiveOps Dashboard out of the box. The dashboard is a website (or an SPA in the modern web development lingo) that can be used to view and control the overall state of the server, and to view and manage users of the game.
The dashboard is intended to be extended and customized to every game's specific needs. As new features are added to the game, it is often useful to expose those features via the dashboard as well. For example, a weekly event inside the game could be made configurable directly from the dashboard.
As the dashboard talks to the server directly, tight integration of data with the game itself is made easy. This makes it possible to ensure that the dashboard only accepts values that are actually valid game data. For example, if a designer wants to add an item to the loot table of a boss, it is possible to validate that the specified item actually exists in this game version’s config data.
The dashboard is built with industry-standard OAuth authentication and authorization. This makes it easy to securely grant access to internal and external customer support teams.