Lesson 1: Multiplayer Scope Guardrails (Player Count, Tick Rate, and Cheat Assumptions)

Before touching packages or transport settings, lock your multiplayer boundaries. This lesson prevents the most common failure mode in networked prototypes: changing assumptions every two days.

Lesson Objective

Create a one-page multiplayer scope brief that defines:

Player-count target
Tick-rate baseline
Trust model and cheat assumptions
One measurable networking KPI

Why This Matters

Multiplayer scope drift is expensive. A "small" shift from 8 players to 24, or from host-authority to hybrid trust, can invalidate movement code, bandwidth budgets, and test scripts.

Guardrails let your team ship a vertical slice instead of endless experiments.

Step-by-Step

Step 1 - Set a hard player-count target

Choose one target and one stretch target:

Target: 8 players (required for ship candidate)
Stretch: 12 players (nice-to-have only if KPI stays healthy)

Do not plan systems for battle-royale scale in this slice.

Step 2 - Pick your tick-rate baseline

Define one baseline simulation rate for this milestone:

Start with 30 ticks per second for predictable CPU/network cost.
Only move to 60 after profiling proves you have margin.

Document this in your project README so QA and programmers use the same expectation.

Step 3 - Lock trust and authority assumptions

For this course track, default to a server-authoritative gameplay model with client prediction only where needed for feel.

Write down:

what clients are allowed to request
what server must validate
what actions are outright rejected server-side

This becomes your anti-cheat baseline, even in a small prototype.

Step 4 - Define your first networking KPI

Pick one measurable KPI and a pass threshold.

Recommended starter KPI:

Reconnect success rate >= 95% during internal tests with 8 players

Alternative:

Average per-player packet budget <= 20 KB/s during normal gameplay

Keep only one KPI in Lesson 1 so the team can focus.

Step 5 - Publish the scope brief

Your multiplayer scope brief should include:

Player count target and stretch target
Tick-rate baseline
Trust model summary
Networking KPI + pass threshold
Out-of-scope list (for example: matchmaking backend, anti-cheat kernel tools, cross-region relay)

Commit this brief next to your task board before Lesson 2 setup work.

Mini Challenge

In 10 minutes, write your scope brief and get one teammate to challenge it with this question:

"Which assumption here would break first under load?"

If no one can answer, your assumptions are still too vague.

Pro Tips

Keep "out of scope" visible on your sprint board, not hidden in docs.
Tie every new multiplayer feature request to your KPI impact.
If a request does not protect or improve your KPI, defer it.

Common Mistakes

Changing player-count target after systems are in progress
Picking 60 tick by default without profiling evidence
Treating cheat assumptions as "later" work

Troubleshooting

"Our team cannot agree on player count."

Start with the smallest count that still proves your core loop. Vertical slices prove feasibility, not final scale.

"We have no KPI yet."

Use reconnect success rate or packet budget first. Both are easy to observe and useful for early decisions.

"People keep suggesting new network features."

Require each request to include expected KPI impact and implementation cost. If unclear, it goes to backlog.

Recap

You now have a multiplayer scope contract for the slice: player count, tick baseline, trust model, and one measurable KPI.

Next Lesson Teaser

Next you will choose the netcode package stack and set up the Unity project shell with reproducible startup settings.