DEV Community: Pedro Fontoura

Battle royale technical breakdown: Safe zones

Pedro Fontoura — Thu, 30 Mar 2023 20:38:10 +0000

This post is the first of a series about common technical challenges you may face while developing a battle royale game.

I've made all the demonstrations for this article in FiveM, a Grand Theft Auto V modding platform, but you could easily apply them to your game.

Safe zones are one of the most fundamental concepts of the battle royale genre. They dictate the rhythm of the match, force players into combat, and can make things very stressful, especially when they are right behind your back.

So, what are the challenges involved in creating a system like that?

Generating random safe zones

From the adrenaline rush of crossing the map to enter the safe area to the calming moments of searching for a good spot inside, the randomness of the safe zones is what makes this system special.

Lucky for us, we can use some basic trigonometry to calculate a new safe zone inside an existing one:

local function degreesToRadians(value)
    return (value * math.pi) / 180
end

local function getNextSafeZone(safeZone, radius)
    assert(safeZone.radius > radius, "Next safe zone radius must be smaller than the current one!")

    local auxiliar = { center = safeZone.center, radius = safeZone.radius - radius }

    local degrees = math.random(0, 360)

    local x = auxiliar.center.x + math.cos(degreesToRadians(degrees)) * auxiliar.radius
    local y = auxiliar.center.y + math.sin(degreesToRadians(degrees)) * auxiliar.radius

    return { center = vector3(x, y, 0.0), radius = radius }
end

The code above selects a random point on an auxiliary circumference with a radius equal to the difference between the radiuses of the current and the next safe zone to be the center of the next one. The following not-so-accurate scheme represents this logic.

Network sync

As a crucial gameplay feature, we must sync the safe zone with all the clients of the match. Otherwise, some players would have an unfair advantage over others.

How do we achieve that, considering network latency and players using different hardware setups?

Low-level or manual sync, using a time factor, is our answer. The technique is very straightforward: Given two subsequent server states, the client performs a smooth transition between those states, respecting the moment each one of these states occurred.

onStartSafeZone

A safe zone is essentially a circumference that transitions its center x and y coordinates and radius from an initial value to a final one. This behavior can be easily replicated with the following information:

Safe zone start timestamp
Safe zone duration
Safe zone initial state
Safe zone final state

Here is an implementation of the start safe zone handler, where we simply receive the server signal telling the client to start the safe zone locally.

local function onStartSafeZone(networkStartTimestamp, durationInMs, start, target)
    if safeZone then return end

    -- Use local timestamp
    safeZoneStartTimestamp = GetGameTimer() + (networkStartTimestamp - GetNetworkTime())
    safeZoneDurationInMs = durationInMs

    safeZone = start
    safeZoneTarget = target

    -- Creates the safe zone minimap indicator
    safeZoneBlip = AddBlipForRadius(safeZone.center.x, safeZone.center.y, safeZone.center.z, safeZone.radius)
    SetBlipColour(safeZoneBlip, 1)
    SetBlipAlpha(safeZoneBlip, 128)

    -- Similiar to StartCoroutine in Unity
    Citizen.CreateThread(onSafeZoneTick)
end

The onSafeZoneTick function is responsible for performing all the calculations and rendering the safe zone. It's where the "magic" happens.

Clamp and Lerp

Before talking about the onSafeZoneTick function, I must introduce you to clamp and lerp, which stands for linear interpolation. Both are very useful concepts in game development. If you're already familiar with them, you can skip this section.

The clamp function limits a value to the range defined by the min and max values, while lerp interpolates two values given some factor.

Here is an example of their implementation:

local function clamp(number, min, max)
    return math.min(math.max(number, min), max)
end

local function lerp(a, b, t)
    return (1 - t) * a + t * b
end

onSafeZoneTick

All right, now let's break the "magic" down:

local function onSafeZoneTick()
    while safeZone do
        local interpolation = clamp((GetGameTimer() - safeZoneStartTimestamp) / safeZoneDurationInMs, 0.0, 1.0)

        local x = lerp(safeZone.center.x, safeZoneTarget.center.x, interpolation)
        local y = lerp(safeZone.center.y, safeZoneTarget.center.y, interpolation)
        local radius = lerp(safeZone.radius, safeZoneTarget.radius, interpolation)

        -- Render the safe zone
        SetBlipCoords(safeZoneBlip, x, y, 0.0)
        SetBlipScale(safeZoneBlip, radius)
        DrawMarker(1, x, y, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, radius * 2, radius * 2, 400.0, 255, 0, 0, 128, false,
            false, 2, false, nil, nil, false) ---@diagnostic disable-line

        -- Yields the coroutine for ... seconds
        Citizen.Wait(0)
    end
end

First, we calculate the "progress" of the safe zone by dividing the amount of time past the start by its duration;
The progress is then clamped between 0.0 and 1.0 because we want the safe zone to stop when it reaches the final state;
Next, we use the clamped progress to interpolate the initial and final values of the safe zone's parameters;
The last step is to use the interpolated values. They represent the safe zone at that specific moment. In our case, we are using the values just for rendering.

Security

When developing a multiplayer game, you must protect it from bad actors, especially if it's competitive.

I could talk here about different anti-cheat software options, but I would rather discuss how to design your game's systems to reduce cheaters' impact on the general player experience.

The most valuable lesson I can give you is to never trust the client. That's it.

For example, don't tell the client about all of the game's safe zones in advance. Send only the relevant data, which is the current or next safe zone, to the client.

Details

There is a ton of things you could do to make safe zones more immersive or visually compelling. It's really up to you and what you want for your game.

Here is an unpolished example using screen effects (timecycles for FiveM readers) and animations.

I'll propose a challenge to test the subjects covered in this article. How could we implement the battle royale plane movement using the concepts discussed here, especially in the Network Sync section? Leave the answer in the comments :)

In the next post, we will talk about UI and the math behind a battle royale compass. Stay tuned!

Creating a proper experience system for your game

Pedro Fontoura — Thu, 30 Mar 2023 15:26:20 +0000

What is an experience system?

An experience or "XP" system is an engagement tool for your game that gives players a sense of progression through the gameplay.

This system is used very often in multiplayer games.

Why should I dedicate time to developing a proper experience system?

First, an experience system keeps the players playing your game. If you can not give enough attention while building this system, why should the player stick to your product after it is out there and the launch hype is out?

That is weird

Imagine that you are playing your game and just reached level 2. It took you roughly one hour to go up from level 1.

You continued playing, and now, you are a lot of hours deep into the gameplay, but different from the game start, you can not even see the next level far ahead. That would be very weird and highly demotivating, right? Exactly.

The XP progression of your game MUST make sense. Picking arbitrary values out of your mind to define the amount of experience per level is a no-no.

So, if the experience system needs to follow logic, what is the most logical thing in the world? Math.

1 + 1 = 2

There are infinite math functions that you could use to describe the experience progression curve.
I will not enter the subject of what function or equation is more appropriate or anything in that direction. Deciding which mathematical function to use is something you can discuss with the math guy on your development team.

You need to define a function that takes the level as a parameter and returns the amount of XP for that level, and vice-versa.

For this example, we will be using the following function to describe the curve of our experience system:

If we plot that function on Geogebra, we can visualize the shape of the curve:

Let me see the code

The implementation of this system is pretty simple. There are essentially two base functions: getXPFromLevel and getLevelFromXP, everything else that is needed on a system like this will be built on top of them.

const INITIAL_FACTOR = 25;

const solveQuadraticEquation = (a: number, b: number, c: number): number[] => {
  const root = (-1 * b + Math.sqrt(Math.pow(b, 2) - 4 * a * c)) / (2 * a);
  const root2 = (-1 * b - Math.sqrt(Math.pow(b, 2) - 4 * a * c)) / (2 * a);

  return [root, root2];
};

const getXPFromLevel = (level: number): number => {
  if (level < 0) {
    return 0;
  }

  return (Math.pow(level, 2) + 3 * level) * INITIAL_FACTOR;
};

const getLevelFromXP = (xp: number): number => {
  const roots = solveQuadraticEquation(1, 3, (xp / INITIAL_FACTOR) * -1);

  const level = roots.find((root) => root >= 0);

  if (level === undefined) {
    return 0;
  }

  return Math.floor(level);
};

There is not much to talk about the code because it is highly dependent on which math formula you choose.

A detail that I can point out is that I used an initial factor to adjust the experience values to be more aesthetic (e.g., the amount of XP needed to reach level 1 is 100 instead of 4.).

There is much more involved in an experience system, like level rewards and rewarding XP for interactions, but I will save those for another post. The idea here is to make a brief introduction to this subject.

Motivation

I wrote this post to showcase this way of building an experience system to a team with web development background and counterpoint a database approach that was getting strong support in a technical debate.

While creating a database entry for each level and storing the amount of XP needed to advance that level is doable, it's a far more resource-consuming and error-prone approach.

Educating and showing different perspectives is the best way to help your team make better decisions.