⭐Best Practices

For Massive Interactive Live Events (MILEs)

Optimise for the worst case

Unintuitively, in the Morpheus stack we care far more about the realistic worst case scenario performance than we do the average.

Optimisations that improve the average case (or even worse, best case!) may look good during development, but really only hide the impact of the worst case we may see in practice. To that end:

We should keep our best and worst case performance as close as possible.

This gives us predictable behaviour and increases the confidence in our testing. For example:

• Sending RPCs at fixed intervals even without payload

• Sending junk chat messages to always run up to our chat rate limit

This does not mean we do not care about the average case, only that we prioritise the worst. For scenarios longer than a MILE, optimising the average case performance may help for cost saving reasons.

Player behaviour invariance

Game performance is primarily influenced by what players do in the game. The worst case performance is some function of all the different actions players can take in a game.

In order to understand the performance of our games, we need to know and test the worst case player behaviour (see above). This means making the best case and worst case performance due to players as close as possible. To achieve this:

Player behaviour must have as little impact on performance as possible.

This does not mean limiting players' actions or freedom in games; instead, it means that regardless of what players choose to do the system load is similar.

Examples of how we achieve this:

• Every player in Morpheus sees the closest N players regardless of distance

• Every client in Morpheus sends RPCs at 10Hz whether there is data to send or not

Be wary of metres

If you are thinking about designing a system which cares about how far away things are, especially players, it likely isn't density invariant. The worst case performance will be significantly worse than the best case.

For example:

• If players check out other players within 10m of themselves, then every player will see everyone if they all go to the same spot

• If your world is split into grid squares and a player sends a chat message to every player in the same square, then every message will be received by everyone if they go to the same grid square

Use budgets rather than units.

• Check out the nearest 50 players rather than any within 10m

• Send chat messages to the nearest 50 players rather than to others in the same grid square

Project structure

MSquared aims to structure projects as closely to native Unreal Engine as possible and supports development within the project content folder. We encourage new projects to be structured in a way in which:

• The majority of content is stored within the project content folder

• Plugins are used to define libraries of shareable content

This is the project structure used by our internal projects and as such, this structure is the most widely tested and least likely to lead to avoidable issues.

Due to legacy reasons, some older projects may have content entirely within plugin(s) but this is not a current limitation of the platform. Ultimately, the choice for project structure is down to the user.