coherence 1.7 has launched! In this article we'll first take a closer look at what are Simulators and when to use them, then talk about the new features added to the Simulator Authority, and finally provide a list of other highlights in this release. Let's go!
Flexible Authority is a core concept in coherence.
That means that while values like position, rotation, scale, and health of every network object can only directly be changed by its state authority, the state authority can be transferred instantly to any client or dedicated server.
This is extremely useful for a lot of games, especially in peer-to-peer scenarios where the simulation of objects is distributed among the clients.
However, there are many cases where instead of giving clients the ability to transfer this authority at runtime, we need a simulator to take control of all important state changes in the game.
Simulators are dedicated servers, in most cases headless builds of the actual game, that behave much like normal clients, except with no player involved. They have special code that only they run (and not the clients).
To learn more about simulators, visit the docs.
Most co-op / PvE / player vs. environment games don’t need to use simulators. In fact, they often don’t even have to use a hosted Replication Server.
One of the reasons is that these games often don’t use a matchmaking system. Because people play with people they know, the incentivization for cheating and impact on the gameplay is fairly low.
The much simpler development and reduced runtime costs in this case outweigh the benefits of having a central and dedicated source of truth.
While many games can run on Client Authority, this is not the case for all games.
Here are some examples where having a single dedicated source of truth is important:
From the above, we can surmise three main reasons for using simulators:
Games like Counter Strike, Overwatch, Rocket League, World of Warcraft and EA FC all use simulators in one way or another, for one or several reasons listed above.
While simulators have been supported from way before coherence 1.0, we are introducing some important upgrades that allow you to tighten security and protect your games against cheating and player griefing even more.
With coherence 1.7. you can make sure that only simulators can create entities. This way you can ensure that a hacked game client cannot spawn unauthorized networked objects into the world. Client-side entities will get automatically destroyed.
By default, when client connections are active, the CoherenceBridge will automatically create a global query entity on behalf of the client. This can now be prevented and a global query can be created manually by the simulator and transferred to the clients if needed.
We can now restrict who can connect to a room or a world. When this feature is enabled, the simulator will receive a validation request for every connection attempt from the client.
The clients can also be required to send a custom user payload, e.g. an access token or any other data.
The simulator can also send a custom payload back to the client.
Creating rooms in a game using simulators usually goes like this:
The tags and key-value dictionary are public, and any other client can read the data in it.
coherence 1.7 introduces the ability to send a custom simulator payload to the room. This information will be accessible only by the simulator.
Here are some other highlights from coherence 1.7:
For more information, check out the 1.7 Release Notes.
Written By
