Appearance
Appearance
MetaReward
type). They can be pre-filled based on IAPs for convenience and can also be deleted from the LiveOps Dashboard. Have a look at Implementing In-Game Mail for more information!MetaplayConnection.Config
has new fields for configuring the client-side session timeout.A new attribute [MetaBlockedMembers(tagIds..)]
was introduced to avoid accidentally recycling old, removed [MetaMember(tagId)]
tagIds, which can cause deserialization to fail, or even more subtle bugs to appear. When removing previously serialized members, do add them as blocked to avoid future problems, like this:
[MetaSerializable]
[MetaBlockedMembers(7, 8)] // Deprecated members: NumGems, NumGold
public class BroadcastMessage
{
...
}
The initial version of the Metaplay Kubernetes operator was released and currently supports GameServer
Kubernetes resources via the metaplay.io/v1
Kubernetes API. These resources can be used to control the deployment of game server pods and are capable of doing coordinated deployments and updates of sharded game server setups for faster deployments in larger-scale setups. metaplay-gameserver
Helm chart was updated to optionally use the new GameServer
resource type using the experimental.metaplayOperator
flag in the chart.
In-game mails have been refactored to new base classes. All mail types should derive from MetaInGameMail
and we also added MetaInGameGenericPlayerMail
for convenience so you don't necessarily have to implement your own mail type at all. A lot of the previous game-specific code regarding mail handling is now generic 🎉
MetaReward
attachments. Our implementation is not backwards compatible with old mails. We tried our best to test the mails from as many angles as we could in your project, but please properly review the implementation before deploying to production!New MetaReward
base class to describe game-specific things that the players can gain, like experience, gold, or items. Any game-specific rewards that derive from MetaReward
can be sent as mail attachments. The long term intention is to make MetaRewards the main data-driven way to describe all rewards in the game, like IAPs, to power future LiveOps Dashboard features.
MetaReward
s, you will need to define your game-specific reward types. We implemented a few rewards in your project to get started. Have a look at Implementing MetaRewards for a complete guide to adding new ones!Player Export/Import was in preview in Release 6, but we changed and updated the data format for Release 7.
We have updated the metaplay game-server Helm chart (0.0.14) to support multiple game server ports with the .Values.service.ports
parameter. This deprecates the .Values.service.port
parameter.
.Values.service.port
before, then everything will continue as is. Otherwise please update to using the new port configuration structure, as illustrated in the default values in the metaplay-gameserver chart.The new clients using robust game sessions won't be compatible with old servers; thus, new servers should be deployed before releasing new clients.
Robust game sessions may cause extended times during a game session where the game may seem to continue seamlessly even though there's no connection.
MetaplayConnection
now has support for tracking application pauses and reacting in certain ways when resuming from a long pause.
MetaplayConnection.OnApplicationPause
from your game. Please see Connection Management for more information. Note: we may have already added this call during the release 7 merge.A few new error states have been added to ConnectionStates
.
Google Play refunds requires initial setup and need to be configured before using.
A new entity shard type DiagnosticTool
has been introduced. For non-singleton server configs, it needs to be added to your Helm chart as the first item in the shards.entityKinds
array for every shard type.
shards:
...
entityKinds:
- DiagnosticTool
- GlobalStateManager
- GlobalStateProxy
A new method PlayerModel.FastForwardTime()
was added to handle scenarios where PlayerModel.Tick()
was not called and player time progression may have been unaccounted for. This only applies to progression that was dependent on Tick()
getting called.
FastForwardTime()
also moves the logic forward. If you have no such logic, there's no need for action.Dashboard file and import structure has been refactored for a cleaner user land / core split. Core code now lives in the metaplay_core
folder with game specific code in game_specific
. All modifications to files under metaplay_core
should be tagged with // METAPLAY_CHANGED
for easier tracking.
Human players and bots now have separate EntityId value ranges. The first 4 billion (32 bits) of the id range are reserved for bots and the rest for humans. A new server config variable AllowBotAccounts
has been added to only allow bots in non-production environments.
Parts of Game.Server.ClientConnection
has been refactored into the new SessionActor
. Most game-specific session-level server functionality should now be implemented in SessionActor
.
SessionActor
, if possible.Parts of PlayerActor
has been refactored into a game-agnostic PlayerActorBase
base class, while making PlayerActor
a derived class and keeping game-specific code there.
PlayerActor
, if possible.The [MetaMessage]
attribute now more strictly requires specifying its parameters: the MessageDirection
parameter is required for all MetaMessage
s in order to prevent cheaters from sending server-internal messages from the client. Furthermore, the MessageTargetActor
parameter is required when the direction specifies that the message can be sent from the client to the server.
MetaMessage
types will need to specify these previously-optional parameters in their attributes as described above.Metaplay games can now connect to the server on multiple ports, in order to circumvent potentially blocked ports in restrictive networks.
In order to enable the multi-port listen, ensure that the relevant Helm charts have all the ports specified:
service:
...
ports:
- name: game
port: 9339
targetPort: 9339
tls: true
- name: game-443
port: 443
targetPort: 443
tls: true
- name: game-1863
port: 1863
targetPort: 1863
tls: true
- name: game-5061
port: 5061
targetPort: 5061
tls: true
- name: game-3724
port: 3724
targetPort: 3724
tls: true
Also, add the following to Assets/Resources/DeploymentConfig.asset
for the matching environments. This causes the client to use alternative ports when connecting.
BackupGateways:
- Id: alt-port-https
ServerHost:
ServerPort: 443
EnableTls: 1
- Id: alt-port-1863
ServerHost:
ServerPort: 1863
EnableTls: 1
- Id: alt-port-3724
ServerHost:
ServerPort: 3724
EnableTls: 1
- Id: alt-port-5061
ServerHost:
ServerPort: 5061
EnableTls: 1
New Connection Errors have been added to Metaplay SDK and the game client should add proper error handling for the new error states as described in Connection Management Error List. In particular, the new SessionForceTerminated
error is TransientError
. However, in case the SessionForceTerminated.Reason
is a SessionForceTerminateReason.ReceivedAnotherConnection
, the game most likely should not immediately reconnect, but instead, prompt the user. Otherwise, a user logged in on two devices at the same time will immediately get logged out as the competing reconnects kick each other out.
To support the new Metaplay Kubernetes operator in your own infrastructure, you will need to manually add the Metaplay CRDs to your cluster. You can do this by obtaining the metaplay-services
Helm chart, extracting it, and applying the CRD to your cluster:
wget https://metaplay-charts-stable.s3-eu-west-1.amazonaws.com/metaplay-services-0.0.10.tgz
tar -zxf metaplay-services-0.0.10.tgz
kubectl apply -f metaplay-services/crds/metaplay-operator.yaml
All runtime database accesses have been ported to use Dapper. Previously, the queries used EFCore, which was detected to use blocking socket IO in the underlying database library. This could lead to thread pool starvation (see, eg, this article). Dapper uses only async IO, which avoids these problems. Initialization-time queries, such as database migrations, still use EFCore.
The Entity-to-Entity PubSub communication has been rewritten to be simpler and more robust. This fixes issues where messages could previously leak from already unsubscribed channels. The change also gets rid of Akka.NET remote watches, which caused instability when nodes tried to reconnect after network issues.
MetaBlockedMembersAttribute
, which can be used to block retired MetaMember tag ids to be used in the future, to avoid accidental migration problems.MetaReward
base class that can be used to easily attach rewards to thing like in-game mail, events, quests, etc.ShuffleInPlace(T[])
, ShuffleInPlace(List<T>)
, and extension method IEnumerable<T> Shuffle<T>(this IEnumerable<T>, RandomPCG)
.MetaplayConnection.Error
s: NoNetworkConnectivity, FailedToResumeSession, SessionForceTerminated, SessionError, SessionLostInBackground.MetaInGameGenericPlayerMail
class with sensible default members (title, body, attachments) to make adopting in-game mails easier.ConfigureAwait(false)
in many more places to improve scheduling of Tasks.MetaInGameMail
.MetaMessageAttribute
now more strictly requires specifying its direction and target actor parameters.EnableSystemHttpServer
and SystemHttpPort
.ServerRuntimeConfig.ClientPort
has been replaced with ServerRuntimeConfig.ClientPorts
-- multiple listen ports can now be defined instead of one.EntityActor.AllowShutdown
is removed in favor of EntityActor.ShutdownPolicy
which allows for more precise automatic entity shutdown.PlayerModel.FastForwardTime()
, which is called by PlayerActor when actor is live, but client doesn't progress the game clock.