What the Server Can See

Keyboard shortcuts

×

?

Open this guide

Alt + B

Show or hide the lesson list

Alt + O

Show or fold the lesson outline

Alt + N

Open or close notes

Alt + H

Toggle semantic colours

Alt + D

Toggle page brightness

Alt + C

Toggle code brightness

← →

Move through a focused code trace

Home End

First or final step in a focused trace

Escape

Close this guide or an open panel

Reader shortcuts pause while you type in a text field.

Cheatsheet for Lesson 9.2Key ideas, reference and questions

A one-page summary of “What the Server Can See” you can keep beside your notes. Plain Markdown.

Lesson 9.2 — What the Server Can See: cheatsheet

• Remember: The server receives requests and runs the shared simulation. It can see the accepted position, inventory, cooldowns, and command history.
• Also useful: Ask what the client needs to draw now. Construct that observation on the server before sending it.

Reading map

• Validate an action in the current world
• Bound how much work a client causes
• Withhold information the client does not need
• Replays preserve useful context

Review

• Q: The server knows an enemy position that this observer is not entitled to see. Which design protects that information boundary? A: Exclude that position from this client's outgoing observation
• Q: Which state does the server directly know? A: Its accepted position and inventory

Download cheatsheet (.md)

Download cheatsheet (.md)

The server receives requests and runs the shared simulation. It can see the accepted position, inventory, cooldowns, and command history. It does not directly see what a player was thinking or every program on their computer. Build checks around what the server actually knows.

Validate an action in the current world

Validation checks types, ranges, and current game state before data can change the world. For a movement command, check the input’s finite numeric values and allowed range. Then simulate movement using server-owned speed, collision, and time. A client-reported final position cannot replace those steps.

The permitted range must match the movement being simulated. A knockback, vehicle, or teleport ability changes what movement is possible. Checking only a single speed ceiling can mistake a valid ability for cheating.

A purchase needs the player’s identity, the item’s current price, and their server-owned balance. Apply the debit and reward together. Otherwise, two concurrent requests could both spend the same old balance, like the lost-update problem in the threading lessons.

Bound how much work a client causes

A rate limit bounds work or requests within a period. Limit expensive queries, parser allocation, and accepted actions separately. Receiving a burst after network delay does not mean the player earned extra simulation time.

Lesson 9.1 separated framing, parsing, and permitted messages in each session state. Keep that order here. Reject an invalid length before allocating its claimed buffer. Reject an action in the wrong session state before changing the world. Handle duplicates according to the action’s documented retry behavior.

Record the original server timing as well as the command’s claimed timing. Source’s lag-compensation checks in Lesson 9.10 illustrate why the server must bound and compare those claims rather than accepting arbitrary history.

Withhold information the client does not need

Fog of war limits what a client learns: hide game information until the player is entitled to observe it. A server that sends every hidden enemy position and merely hides the corresponding drawing has already disclosed the data.

In the toy picture, a wall blocks the observer’s sightline. The server knows the enemy’s position but sends none to this client. The enemy moves above the wall. Only after the new sightline clears the wall does its position enter the client’s observation.

The server withholds what the observer cannot seeIn the toy wall example the server knows the enemy position, but a wall blocks the sightline, so it sends nothing about the enemy.

ServerThis client

1. 1

   Alone Enemy position is known here

   Step 1: Server (alone)

   The server simulates the whole world, including the enemy.

2. 2

   Alone Sightline crosses the wall

   Step 2: Server (alone)

   The observer’s line of sight to the enemy is blocked.

3. 3

   Control Send nothing about the enemy

   Step 3: Server to This client

   A hack on this client cannot reveal what the client was never given.

In the toy wall example the server knows the enemy position, but a wall blocks the sightline, so it sends nothing about the enemy.

The position is disclosed once the view is clearWhen the enemy moves above the wall and the sightline clears, the position becomes part of this client’s observation.

ServerThis client

1. 1

   Alone Enemy moves above the wall

   Step 1: Server (alone)

   The world changes on the server.

2. 2

   Alone Sightline is clear

   Step 2: Server (alone)

   Nothing blocks the observer’s view of the enemy now.

3. 3

   Data Enemy position enters the observation

   Step 3: Server to This client

   Only now does the server send the position to this client.

When the enemy moves above the wall and the sightline clears, the position becomes part of this client’s observation.

Filter state before sending the message. This step-by-step trace needs JavaScript. Here is the code and where the run ends.

read the selected inputs
evaluate each stated condition
combine the required conditions
perform the effect only when accepted
otherwise retain the old state
report the result and its limits

Result: the outgoing record has no hidden-enemy position. Client drawing cannot recover an absent field.

Final values: position = 8; wall = yes; line_clear = false; accepted = false; sent_position = absent.

Read every step of the lesson’s example

1. Step 1, line 1. Start with the selected inputs and follow how the next operation changes the state.

   position = 8; wall = yes.

2. Step 2, line 2. The server can retain an entity while omitting its position from this client’s record.

   position = 8; wall = yes; line_clear = false.

3. Step 3, line 3. Accept only when the required conditions all hold.

   position = 8; wall = yes; line_clear = false; accepted = false.

4. Step 4, line 5. The model retains its previous state.

   position = 8; wall = yes; line_clear = false; accepted = false; sent_position = absent.

5. Step 5, line 6. Result: the outgoing record has no hidden-enemy position. Client drawing cannot recover an absent field.

   position = 8; wall = yes; line_clear = false; accepted = false; sent_position = absent.

Watch it happenWithhold the hidden position

A wall hides an enemy until the server finds a clear sightline.

Read the steps

1. The server knows where the enemy is. A wall blocks this observer, so the client has no enemy position.
2. The enemy moves above the wall. The server updates its geometric visibility test.
3. The new sightline clears the wall. This position now qualifies for disclosure.
4. Only now does a position update cross into the client observation.
5. The client draws the received enemy. Hiding a label would not have removed information; withholding the position did.

This toy sightline shows the policy boundary. Production visibility also handles latency and geometry.

Real visibility systems must account for more than this one line. Animation, sound, team information, latency, and other players’ perspectives can make an entity relevant. Reveal it early enough to avoid visible pop-in, but do not disclose unrelated hidden state. Lesson 7.8 applies the same server-owned visibility decision to radar markers.

Alternative: Ask what the client needs to draw now. Construct that observation on the server before sending it.

Replays preserve useful context

A replay records enough accepted state and input to inspect a past sequence. Store the game version and the timing used to apply commands alongside it. A video from one client can omit information available to the server and include prediction or interpolation differences.

Replay review helps distinguish an impossible state from an unusual but legal tactic. It also reveals what a check was unable to observe. A replay that omits raw input edges cannot prove the timing of those omitted edges.

Machine learning fits a model to examples instead of using only hand- written checks. It can rank large numbers of replay segments for review. Its training labels can contain mistakes, and a new game update can change the input distribution. Test on held-out legitimate matches, different devices, and the updated game. A model score is a signal with measured limits, not an explanation of guilt by itself.

🧩

Knowledge check

Before the position is sent

The server knows an enemy position that this observer is not entitled to see. Which design protects that information boundary?

1Exclude that position from this client's outgoing observation2Include the position but omit its visible drawing3Include the position only in an encrypted game connection4Include the position and ask the client to hide it

Check answer

Finished Lesson 9.2?

Mark it done and the lesson list shows a ✓ beside it. A chapter whose lessons are all done is marked done too. Progress is saved in this browser only.

Mark lesson doneLesson done. Mark it not done

Chapter 9: 10 lessons

📝 Notes