Appearance
Appearance
The Metaplay SDK's Game Events systems allow you to implement in-game features activated for players based on schedule, segmentation, or both. These Events can then be added and configured without code updates. The Metaplay SDK provides a generic foundation on which you can implement new Events, leaving the details of what aspects of the Event are configurable to the game logic.
The SDK has two separate systems for implementing Events: the config-driven Events and the LiveOps Events system. It's important to understand the differences between the data models, the exposed APIs, and the features provided between these systems when choosing which one to base your Event implementation on. The config-driven Events system is a more mature part of the SDK and provides more features out of the box, while the newer LiveOps Events system is easier to integrate and more flexible.
Good To Know
We expect the LiveOps Events system to be a better choice for most use cases, and in time, we intend to provide all of the functionality currently available with config-driven Events in the newer LiveOps system and eventually deprecate the older one.
In the config-driven Events, all configurations related to all Events available (now or in the future!) are described in the shared game config. The lifecycle state of an Event for a given player can be resolved from the game config both by the client and the server at any time, and it is up to the shared game logic to trigger changes in the lifecycle state by periodically resolving the state given the current player time and state. The client and server don't explicitly communicate state changes to one another but rather mutate the Event-related state individually in a deterministic fashion.
Here's an example of declaring an Event in the configs:
HappyHourId #key | DisplayName | Description | Item | CostFactor | Segments | Schedule.TimeMode | Schedule.Start.Date | Schedule.Start.Time | Schedule.Preview | Schedule.Duration | Schedule.EndingSoon | Schedule.Review | Schedule.Recurrence |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
FridayHappyHour | Friday Happy Hour | Sword's cost is decreased 75% on Friday evening | Sword | 0.25 | LevelAtLEast5 | Local | 2021-05-28 | 18:00 | 1h | 4h | 30m | 15m | 7d |
And adding the corresponding class to the game configs:
public class SharedGameConfig : SharedGameConfigBase
{
[GameConfigEntry("HappyHours")]
[GameConfigEntryTransform(typeof(HappyHourSourceConfigItem))]
public GameConfigLibrary<HappyHourId, HappyHourInfo> HappyHours { get; private set; }
}
The benefit of this model is that no additional communication is needed to keep the Event state in sync between client and server. Still, the drawback is that the full set of all future Events for all players needs to be declared in the game config and any updates to the Event configuration require updating the shared game config globally.
In the LiveOps Events system, the global set of Events is maintained exclusively on the game server, and Events are only communicated to the clients on-demand when an instance of an Event becomes active for a player. The server similarly drives state updates for client-visible Events and explicitly communicates them to the client rather than the client independently evaluating the lifecycle state changes based on the Event configuration.
The Liveops Events can therefore be created and edited from the dashboard without any client, server or config updates. Because of this, LiveOps managers can orchestrate events in a live game easily and at any time!
Now you might have an idea of what path you want to follow when implementing your Game Events.
One of the ways to target players for Events is by dividing them into Segments. You can find out more about player segmentation in Implementing Player Segments.