Server state and client effects in online games

News about the Cafu Engine. Subscribe to the related ImageCafu News feed to stay informed.
User avatar
Site Admin
Joined:2004-08-19, 13:46
Server state and client effects in online games

Post by Carsten » 2014-01-19, 17:53

As explained in my previous news post, I am currently migrating the old DeathMatch game code to the new Component System architecture. Just this afternoon I finished dealing with the "hand grenade" entities in the new system, and I found that they're noteworthy in many regards:
  • Hand grenades are both dynamically created during the course of a game (when the player throws them) and dynamically removed again (after they have exploded and their traces have gone). This makes them different from many other entities that are defined in map files and often exist from the beginning to the end of the map.
  • Hand grenades employ more components than other entities in order to implement their functionality:
    • Model (the hand grenade model as thrown through the map),
    • Physics (for computing the flight path and dealing with collisions, e.g. with walls and the floor),
    • Script (for controlling the details, e.g. letting the detonation timer tick and implementing the explosion effects),
    • Light (for the flare when the hand grenade explodes),
    • Sound (for the sound at the time of the explosion),
    • ParticleSystem (for the smoke and spark particles at the explosion).
  • They very well demonstrate the distinction between Server State and Client Effects.
It is the last point that I would like to highlight in this post, because a good understanding of it is crucial for game development with Cafu:

Server State

The server state is characterized by the following properties:
  • It is synchronized via the game server to all clients,
  • every player (client) sees the same results and consequences,
  • server state is relevant for gameplay.
Typical examples are drawbridges, the position and state of elevators and doors, details about opponents, etc.
As a side note, events are often a result of a change in the server state, and transferred to the clients as such.

Client Effects

Client effects can be triggered by some event in the server state, but besides that, they:
  • run independently of each other on the clients only,
  • are often used for eye-candy,
  • it's ok if not everyone sees exactly the same (not relevant for gameplay).
Examples include particle effects such as smoke, sparks and small pieces of debris, many fade or transition effects, model animation frames, etc.

Having both

An important insight is that we sometimes need both server state and client effects combined.

For example, consider a light source that illuminates an otherwise pitch black part of a labyrinth. Whether the light source is on or off clearly makes an important difference for players who try to navigate the labyrinth, and so the state of the light source is managed as a part of the server state.

However, there are also other kinds of light sources, e.g. those that are on, but steadily flicker or pulse. This is often a means to create a specific atmosphere to a map, but the exact amplitude of the flicker or pulse is really not something that needs synchronization over the network.

In fact, as a combination we may wish that the light source's on or off state is synchronized to everyone, and if it is on, have it have a client-side flicker effect for eye-candy.

This is exactly what we can (starting with commit d11c6a9) achieve with the light source components, and what I now employ with the hand grenades: When a hand grenade explodes, the related light source is turned on in order to mimic the bright flare of the explosion. However, the exact details of how the bright light fades, changes its color from white over yellow to red, shrinks and eventually disappears (all in about half a second), needs not be synchronized over the network.

Instead, a very simple script method is used to implement this. Here is its entire code:

Code: Select all

local clTime = 0.0
local Duration = 0.5

function Light:ClientEffect(t)
    if not self:get("On") then
        clTime = 0.0
        return false

    clTime = clTime + t

    if clTime >= Duration then
        return true, 0, 0, 0, 0

    local Amount = 1.0 - clTime/Duration

    return true, Amount, Amount*Amount, Amount*Amount*Amount, 400.0
Well, this is one of the reasons why I love the new component system! :loveit:
Best regards,
User avatar
Site Admin
Joined:2004-08-19, 13:46

Re: Server state and client effects in online games

Post by Carsten » 2014-03-06, 11:59

Client effects with: state, state changes and events

As an addendum to my above text, we should also consider another facet of server states: state changes and events.

In the example with the light source, the client effect (flicker, pulsing) was coupled to the state (on or off) that the light source has at the server. The server state is propagated by the Cafu network layer to the clients, and if the light source is on, clients add the flicker effect as shown above.

There are, however, two other options that the client can use to add custom effects to a game world: state changes and events.

Clients can become aware of server state changes whenever an incoming network message updates the variable of an entity to a value different from the previous value. For example, whenever a platform starts moving, its velocity changes from zero to a non-zero value, and vice-versa when it stops. The state of a door may change from locked to unlocked to open to closed, then back to locked. The number of shells in an opponent player's inventory decreases when he fires a weapon. It is quite obvious that clients can use such state changes to trigger effects, too, e.g. the playback of sounds, the emission of particles, etc.

However, not always is a state change available to indicate that something interesting has happened. If an opponent player fires a weapon that consumes no ammo, or if a grenade's timer is not explicitly synchronized to the clients, there is no associated state change from which the client could learn that the application of further effects is indicated. Therefore, the Cafu engine also supports explicit events. Events originate in the server state, and are propagated from the server to the clients. (As a technical detail, note that our events are fully predictable: they work well even in the presence of client prediction.) A client that receives an event can use it to trigger additional client effects as before.

In summary, client effects can be associated with:
  • the state itself,
  • state changes,
  • explicit events.
Note that each of these approaches has its relevance: there is no single choice that is universally "best". A designer who creates a new entity often has the free choice which of these "hooks" to use to implement the desired features.
Best regards,

Who is online

Users browsing this forum: No registered users and 2 guests