You press jump. Your ninja moves.
Your client starts the move locally. It does not wait for a trip to the server and back before you can react.
Prediction + reconciliationMove now. Make the shot count.
Immediate local movement, precise shot references and server-checked combat. See what the current build does, what the latest tests measured, and where the limits still are.
Your aimThe server’s checkOne shot. One result.
Less waiting. More confidence in the fight.
Netcode is how everyone’s version of a match stays connected. In a game this fast, it has three jobs you can feel.
Your flick belongs to that shot.
A shot keeps the aiming context selected for it. Later mouse movement or a render delay cannot quietly rewrite the attack.
Shot references + historyThe same rules apply to everyone.
The server checks hits, cooldowns, shields and ammo. A client cannot simply announce that it scored a kill.
Server authority128 simulation steps a secondThe server advances the rules every 7.8125 ms and publishes combat scenes at 64 Hz. Your mouse, the renderer and your Internet ping are separate parts of the experience.
Different weapons. The right kind of history.
An instant rail, a flying arrow and a teleport cannot all be treated the same way. Pick one to follow what happens.
Your aim stays with your shot.
When you flick onto a moving ninja and fire, that instant matters. The server checks the aim and recent view attached to that action.
Capture the action
Your game saves where you aimed and which moment of the fight the shot belongs to.
Check the fight
The server checks the target in that allowed slice of history, with strict limits on how far back it can look.
Confirm the result
The result comes back separately from the visual effects. A repeated message cannot count as another shot.
Under the hood
The reference is the eligible scene submitted to the bounded CPU render queue, selected using the input event’s chronology. It is not hardware proof of what reached the display. Issued frame tokens, decoded-scene receipts, life/warp identity, origin history and strict age bounds remain required. An expired reference cannot be silently replaced with a newer one.
The arrow still has to get there.
Projectile travel creates the chance to lead, dodge and use cover. That opportunity must survive a change in frame rate or a late packet.
Launch in the world
Your arrow starts from the position approved by the server.
Follow the flight
Your PC draws the flight. The server checks the whole path between steps to catch contact with moving players and cover.
Resolve the contact
The server ends the flight when it hits or expires. A late message cannot bring an already-finished arrow back.
Under the hood
Ballistics use current-world launch and collision, not the rail’s historical target rewind. Swept relative collision checks the interval between simulation states. Launch and terminal receipts are independent; retained terminal identities prevent resurrection. Projectile travel time is not mistaken for network confirmation delay.
Fast movement. Clear boundaries.
Leaps share the same movement rules on client and server. A teleport is a real change of place, not a ninja sliding invisibly through the space between.
Move immediately
Local prediction begins the move without waiting for the server’s reply.
Agree on the result
The server follows the same movement rules. If it corrects your position, your newer inputs are applied from there.
Cut at the warp
The game starts a new path at your destination. It does not draw or test a collision along an imaginary journey through the gap.
Under the hood
Movement prediction and reconciliation share the controller. Respawn, occupant and warp transitions are explicit. Collision does not sweep a player through the gap between teleport endpoints. Model flips, leans, capes and smoke are presentation; they do not rotate the authoritative hit geometry.
The current build.
Implementation checked against the game source and the completed 26–27 October study. New game, Practice and dedicated-server launches share the same default transport.
- Compatible wire protocol
- 37
- Configured player limit
- 64, including bots
Paged state, readiness-based waits and bounded message scheduling reduce avoidable work. Receipt ownership and a stale input-epoch fix preserve recovery without loosening the server’s combat checks. Read the implementation changes.
64 players in a dense fight
Ironworks with ninja stars passed all three clean confirmations at the normal bandwidth budget. This remains the general reference.
- Weapon-request feedback p99
- 14.40–19.39 ms
- Received-position age p99
- 16.25–16.38 ms
128 players, under specific conditions
Spread-out Highlands FFA, mixed weapon cohorts, net, shadow and chi. This is a conditional research result; it does not raise the game’s limit or establish full Shogun capacity.
- Weapon-request feedback p99
- 21.68–28.67 ms
- Received-position age p99
- 17.66–25.47 ms
| Workload | Measured window | Server tick p99 | Position-age p99 | Request-feedback p99 |
|---|---|---|---|---|
| Ironworks · 64 players Seed 826701 | 40 s | 1.20 ms | 16.38 ms | 18.36 ms |
| Ironworks · 64 players Seed 826702 | 40 s | 1.55 ms | 16.32 ms | 19.39 ms |
| Ironworks · 64 players Seed 826703 | 310 s | 1.40 ms | 16.25 ms | 14.40 ms |
| Shogun Highlands · 128 players Seed 826701 | 40 s | 1.95 ms | 17.66 ms | 21.68 ms |
| Shogun Highlands · 128 players Seed 826702 | 40 s | 1.95 ms | 17.79 ms | 28.67 ms |
| Shogun Highlands · 128 players Seed 826703 | 310 s | 1.95 ms | 25.47 ms | 22.60 ms |
Each position-age and feedback figure is the maximum of individual clients’ p99 values. Feedback measures the software acknowledgement of a weapon request, excluding projectile flight. The long 128-player run recorded 614 late input commands and 13 late actions, despite passing the declared screen.
What the test includes
Synthetic real-protocol FFA clients across two wired-gigabit hosts. Linux Ryzen 7 5800H client generator; Windows i5-12500H server. Rendering, audio and full server-bot AI are measured separately. These runs measure networking and the authoritative FFA simulation. They do not combine full server-bot AI, player rendering/audio and real human input into a qualified match.
The direct-LAN screen required server-tick p99 at most 5.5 ms, tick p99.9 at most 7.8125 ms, and worst-client position-age and feedback p99 at most 50 ms. Generator timing, full acquisition and zero input-buffer handoffs/invalid records were also required. Deliberately delayed paths need their own comparison.
Read the capacity study or download the measurement summary ↓.
Where the higher counts fell short
A connected client is the beginning of a test. Timing, freshness and recovery still have to hold up.
80 players · dense Ironworks
One clean repeat needed two input-buffer handoffs, failing the declared zero-handoff rule. Other long runs overlapped unrelated testing.
160 players · Highlands
Two clean runs passed. A third needed two input-buffer handoffs, so the complete series failed the declared rule.
128 players · dense Ironworks
Twice the normal bandwidth did not establish dense 128-player play. One run missed the feedback and position-age limits; the long run also missed input timing and needed handoffs.
192 players · large-map fixtures
The client generator missed its input interval. Connections and traffic were observed, but this run does not establish the server’s maximum.
Delay, loss and jitter leave different traces
One completed clean 64-player Ironworks star encounter per condition. These are separate live encounters, with the original differences and limitations retained.
| Path | Position-age p99 | Request-feedback p99 | Input-buffer handoffs |
|---|---|---|---|
| Direct LAN | 16.32 ms | 13.89 ms | 0 |
| 40 ms added RTT | 40.19 ms | 58.78 ms | 0 |
| 40 ms added RTT + 1% loss, no jitter | 47.62 ms | 68.09 ms | 0 |
| 40 ms added RTT + 1% loss + ±2 ms jitter | 87.04 ms | 86.53 ms | 2 |
The combined jitter/loss case also recorded 35 late actions. Transport “considered lost” counters include recovery decisions and are not physical packet-drop counts. These observations guide further investigation; no timing or congestion-control relaxation was adopted from them.
A weapon’s cost depends on the fight.
Sixteen active/unused pairs compare eight weapons and abilities on two maps, with 64 players and one seed per pair. The figures below are changes in total server upload for those encounters.
| Weapon or ability | Ironworks | Shogun Highlands |
|---|---|---|
| Rail | +12.84 | +12.71 |
| Bow | +7.94 | +8.17 |
| Ninja stars | +23.93 | +24.10 |
| Grenades | +9.78 | +18.18 |
| Net | +0.77 | +0.50 |
| Shadow warp | +2.74 | +2.48 |
| Chi-jump | +7.38 | +6.89 |
| Melee | +11.79 | +12.25 |
Deaths, respawn ammunition, visibility and movement changed between encounters. These are measured encounter differences, not additive equipment prices or a supported-player calculator. The older fitted model remains available below as an explicitly dated archive.
More room for the fight.
We asked what each repeated byte was doing for the player. Then we measured the changes and kept the ones that preserved the rules.
Less game payload from the server
Less game payload from players
32-client archive · 20–21 October
Measured rates across implementation stages. These percentages describe game-message bytes—not equal gains in FPS, ping or server capacity.
Inspect the counts and timingRemember the outfit.
Your PC already knows the ninja’s look. Repeating the wardrobe would spend bandwidth without improving the fight.
What changed technically
Round-locked appearance moves through an occupant-bound reliable roster. The 20 October archive removes 20 cosmetic/suit/band bytes from owner corrections: 283 → 263 bytes in that pass. Score-only roster changes retain cached identity. Late joiners still receive a complete baseline.
Send the fields this action needs.
The game sends bow-draw details while you are drawing a bow. Other attacks carry the information needed to check that kind of attack.
What changed technically
Typed actions keep FireView on rail/melee and draw dependencies on bow release/cancel. Validated envelope identity is inherited only within the same packet. The archived wire-27 compact owner record is 115–227 bytes. Active draw identity retains its epoch and sequence, including across input recovery.
Pack smaller. Keep the meaning.
Smaller messages leave more room on the connection without rounding away a precise aim or changing how a jump works.
What changed technically
Exact-default masks omit only known bit patterns; nonzero words and negative zero are preserved. Existing canonical actor integers use varint/ZigZag encoding: 21–46 bytes per actor, with a full-frame fallback when compression would grow it. No previous unreliable packet is needed to decode a scene.
Keep the safety net for lost packets.
A dropped packet should not erase a move. Repetition and receipts have a job; we made their representation cheaper.
What changed technically
Recent commands retain their loss coverage. Nonempty acknowledgement windows keep their complete 128-bit gap map. Fresh input can carry due receipts; standalone acknowledgements remain for idle/bootstrap/recovery. QUIC receipt alone is not proof that a full scene decoded.
Share work. Do not queue old fights.
The server can prepare common information once, while keeping each player’s timing and identity separate.
What changed technically
Immutable actor bytes are prepared once per publication. Projectile retention uses bounded deadline indexes rather than scanning everything. Native QUIC send polling resumes when work can produce output. Queue bounds and independent expiry remain in place; enlarging a queue is not treated as an optimization.
Let input keep working between frames.
A display wait should not also become a pause in input, prediction and incoming results.
What changed technically
Those services have an independent owner; rendering consumes immutable publications. A native-resolution scene without FXAA can avoid an extra composition pass. The matched ultrawide fixture improved mean frame time by 8.7%; that renderer result is separate from bandwidth and is not a universal FPS promise.
Use the state the match needs.
A small match should not repeatedly copy storage sized for every possible player or projectile.
What changed technically
Stable, lazily allocated pages retain numeric slots and borrowed references. Simulation, history and presentation follow the constructed extent; reused storage is reset before exposure. This is bounded prefix storage, not an O(active-count) promise for every sparse high-slot case.
Wake when there is work.
The network worker can wait for incoming packets, outgoing work or the next useful deadline.
What changed technically
Native readiness and work notifications replace the unconditional 100-microsecond idle polling ceiling. Urgent messages, fresh scene fragments, durable state and cosmetics have bounded service turns. Congestion control, pacing and authenticated ingress deadlines remain enforced.
Keep retries from queueing twice.
A retry should recover a missing result without repeatedly adding another copy that has not left yet.
What changed technically
One journal receipt owns at most one unsent plaintext attempt across application/native queues. ACK validation requires a submitted identity. Projectile-lifecycle retry timing uses validated RTT samples with a 31.25–250 ms bound; action/hit-result recovery retains 31.25 ms. Already prepared QUIC packets cannot be recalled.
Network traffic. Every byte accounted for.
The explorer starts with real 26–27 October wire-37 captures: three clean 64-player Ironworks runs and three 128-player Highlands research runs, using PicoQUIC/CUBIC across two physical LAN hosts. Change direction, inspect a message or export the counters. Earlier implementation recordings remain selectable as history.
Inspect a recording
26–27 Oct 2026 · wire 37 · 64 protocol clients · Dense Ironworks FFA · ninja stars · 3 clean confirmations. The configured game limit remains 64, including bots.
Received network traffic192.64 kB/sAverage per client · includes transport
Game-message payload167.35 kB/sGame records after QUIC delivery
Network packets380.7/sAverage per client · not game-message count
Bytes accounted for4,956,487,693Raw received IP bytes across the sample
100% = all received IP bytes. Transport overhead is included.
| Message / purpose | Share | Traffic rate | Records / second | Bytes / record |
|---|---|---|---|---|
| 58.35% | 112.41 kB/s | 128.0 | 878.2 | |
| 13.45% | 25.91 kB/s | 57.5 | 450.4 | |
| 8.23% | 15.85 kB/s | 198.2 | 80.0 | |
| 7.59% | 14.62 kB/s | — | — | |
| 5.53% | 10.66 kB/s | 380.7 | 28.0 | |
| 4.24% | 8.17 kB/s | 64.0 | 127.6 | |
| 1.49% | 2.88 kB/s | 16.0 | 180.0 | |
| 0.69% | 1.32 kB/s | 12.9 | 102.6 | |
| 0.20% | 0.38 kB/s | 3.5 | 110.0 | |
| 0.18% | 0.35 kB/s | 8.0 | 44.0 | |
| 0.04% | 0.09 kB/s | 2.0 | 43.0 |
Receiver counter windows
These are recorded receiver-counter windows, including setup/drain captured by each endpoint. Client counters cover about 44/314 seconds; the server covers about 40/310. Rates divide summed bytes by mean receiver duration; per-client rates divide again by population. Counter windows are not the same as the active-play or latency-screen windows.
Selected receiver duration: 402.03 s across 3 recording(s). Current per-record fields below come from the wire-37 instrumentation.
Follow the delivery: queued → sent → received
Smaller traffic is useful only if the right information arrives on time. This flow always shows server → players, even when the table is showing inputs.
Accepted by server transport10.80 MB/sQueued game bytes; not a delivery guarantee
Server sent on the network12.42 MB/sIncludes transport and packet envelopes
Game bytes received10.71 MB/sAll clients; after QUIC delivery
Expired / replaced68 / 3,752Server records during selected windows
These are different accounting points, not a byte-for-byte subtraction funnel. Transport admission is not guaranteed transmission. Receiver and sender sample boundaries differ slightly. Expired/replaced counters describe server records, not lost IP packets.
Compare current and historical recordings
Recordings at this population.
Timing columns show the worst-client p99, or the range across runs. The current physical-LAN workloads and earlier shared-host archives differ in equipment, topology and map state. This table does not isolate a performance improvement between builds.
| Recording | Game payload | Received IP traffic | Scene age · p99 | Action feedback · p99 | Acquisition |
|---|---|---|---|---|---|
| Current build26–27 Oct · 3 sample(s) | 167.35 kB/s | 192.64 kB/s | 16.26–16.38 ms | 14.40–19.39 ms | Completed |
| Original archive20 Oct · 1 sample(s) | 27.11 kB/s | 44.20 kB/s | 4,984.90 ms | 57.75 ms | Partial / failed |
| Appearance-cache archive20 Oct | Failed before sampling | ||||
| Compact archive21 Oct | Not measured at this population | ||||
26–27 October: three clean confirmations per current workload. 20 October: one short sample per recorded population. 21 October compact archive: three short samples at 16 and 32 clients. Missing cells mean no recording, not zero traffic.
Counter windows, individual runs and source hashes
Windows i5-12500H server and Linux Ryzen 7 5800H protocol clients over wired gigabit IPv4 LAN. These are recorded receiver-counter windows, including setup/drain captured by each endpoint. Client counters cover about 44/314 seconds; the server covers about 40/310. Rates divide summed bytes by mean receiver duration; per-client rates divide again by population. Counter windows are not the same as the active-play or latency-screen windows.
| Run | Counter duration | Endpoints | Server tick p99 | Scene age p99 | Feedback p99 | Feedback samples | Status |
|---|---|---|---|---|---|---|---|
| Run 1 | 44.01 s | 65/65 | 1.20 ms | 16.38 ms | 18.36 ms | 3,370 | Complete |
| Run 2 | 44.01 s | 65/65 | 1.55 ms | 16.32 ms | 19.39 ms | 3,398 | Complete |
| Run 3 | 314.01 s | 65/65 | 1.40 ms | 16.26 ms | 14.40 ms | 33,250 | Complete |
“Feedback” is a software-measured request disposition, excluding projectile flight. Repeated input/event counters mean an identity was seen more than once; they are not QUIC retransmission counts. The 128-player result is conditional research. Current gameplay remains capped at 64 including bots.
Known IPv4 + UDP overhead is 28 bytes per received datagram. The remainder combines QUIC framing, tags, acknowledgements, recovery and boundary buffering. Ethernet/Wi-Fi bytes are outside the accounting. Decimal units: 1 kB = 1,000 bytes; 1 Mbit/s = 1,000,000 bits/s.
Wire protocol 37 · picoquic · industrial · map hash 3546931156 · 64 clients / 0 bots
out/engine-capacity-20261026/lan-confirm-baseline/industrial-stars-64-seed-826701-eight-workers/attempt-001/metrics.jsonSHA-256 7411fe11e064775fdf760e47fca1b3085423100914e425b19cfdde2991d64e49out/engine-capacity-20261026/lan-confirm-baseline/industrial-stars-64-seed-826701-eight-workers/attempt-001/windows/metrics.jsonSHA-256 07c51558ab014f9399196311b84b72322920c13a25d0492bad9f3d698fdc459cout/engine-capacity-20261026/lan-confirm-baseline/industrial-stars-64-seed-826702-eight-workers/attempt-001/metrics.jsonSHA-256 fbcb1202f4580c6d39b0e14e6d3d2fe4b697829549ab7b16ac2856a1fa1e3f06out/engine-capacity-20261026/lan-confirm-baseline/industrial-stars-64-seed-826702-eight-workers/attempt-001/windows/metrics.jsonSHA-256 98c7eb3c26f0d53401145905358e88789ac06cc326e75ac78c4f1d46c94273beout/engine-capacity-20261026/lan-confirm-baseline/industrial-stars-64-soak-eight-workers/attempt-001/metrics.jsonSHA-256 fd94bff6371a2575592ed467c159986362ff77c3ad343af480d1ed5f17dd7912out/engine-capacity-20261026/lan-confirm-baseline/industrial-stars-64-soak-eight-workers/attempt-001/windows/metrics.jsonSHA-256 a9084f7607cb1770177096f4ff818b3c25c57e68ea4ef1f070348e62ed035f8aEarlier uncompressed snapshot-scaling illustration
More ninjas. More people watching.
Add a player and there is one more ninja to describe. There is also one more connection that needs everyone else’s updates. That is why the cost grows faster than the headcount.
This small calculator recreates the old, uncompressed snapshot arithmetic from the original report. It isolates that scaling effect. It is not the current wire codec or a supported-player calculator.
90.11 kB/sSnapshots for one recipient
23.07 Mbit/sSnapshots sent to everyone
2Fragments per complete scene
Exact arithmetic
Frame = 32 + 40 × players bytes. Fragments = ceil(frame / 1,052). Rate per recipient = (frame + 48 × fragments) × 64 bytes/s. Includes the recipient’s actor, excludes owner corrections, all other messages and QUIC/IP overhead. Input up to 128 is a mathematical illustration; the game limit remains 64.
The current projectile payload calculator.
Wire 37 sends a 96-byte launch and a 64-byte terminal record for each projectile recipient. Explore that known payload directly using the current encoder’s sizes.
Lifecycle payload
8.192 Mbps128.00 kbit/s per receiving client. This covers projectile lifecycle payload only.
160 bytes × receiving clients × launches per second.
One part of the connection
This calculates one launch and one terminal per recipient. Retries, result receipts, movement, scenes, objectives, QUIC/IP/UDP and link framing are outside this arithmetic. The result cannot establish a supported player count or the total cost of equipping a weapon.
The current sixteen encounter comparisons show measured changes under real workloads. Download the current counters and encoder-source hashes ↓.
Earlier fitted equipment model · 21 October 2026
The archived weapon-cost model.
This 21 October study models a fixed 8–12-player class and action schedule. Its fitted costs describe that older build. The current game’s sixteen 64-player encounter pairs are shown separately above; neither study authorizes a player-cap increase.
All outgoing traffic from the server.700.23 kB/s
Fitted estimate · before the study’s allowance
Base population traffic654.99 kB/s
Bow-holder terms39.11 kB/s
Shadow-holder terms6.14 kB/s
Combined bow × shadow term0.00 kB/s
Observed median: 700.85 kB/s. Full observed range: 699.90 kB/s–704.64 kB/s, from 3 runs.
Native estimate + empirical allowance704.94 kB/s700.23 kB/s (terms rounded up) + 4.71 kB/s. This is not a guaranteed peak rate.
Explore the shape of the cost.
Choose a cell to load that class mix. The current shadow-holder count stays fixed. A dot marks an actually measured configuration; other cells are interpolation.
| Population | 0 bow | 1 bow | 2 bow | 3 bow | 4 bow |
|---|---|---|---|---|---|
| 8 players | |||||
| 9 players | |||||
| 10 players | |||||
| 11 players | |||||
| 12 players |
What we learned
In this workload, an additional bow holder adds about 8.69 kB/s of server outgoing traffic at eight players and 13.04 kB/s at twelve.
An additional shadow holder adds about 1.08 kB/s at eight and 1.53 kB/s at twelve. The costs grow differently because the two features produce different traffic.
These are fitted costs for this class/action schedule—not a universal price for equipping a weapon. Rail, stars, shrapnel, melee, nets and chi-jumps do not have isolated prices in this study.
All 14 measured configurations
Click a configuration to load it. Switching the direction cards above changes this table too. Values are observed medians and full ranges across three runs. A fit may sit outside that range; the separate allowance is evaluated below.
| Load configuration | Observed median | Observed min–max | Fitted estimate | Fit − median |
|---|---|---|---|---|
| 381.97 kB/s | 380.98 kB/s–382.45 kB/s | 382.50 kB/s | 0.53 kB/s | |
| 385.82 kB/s | 385.12 kB/s–388.14 kB/s | 386.83 kB/s | 1.02 kB/s | |
| 415.76 kB/s | 415.44 kB/s–415.94 kB/s | 417.26 kB/s | 1.50 kB/s | |
| 421.95 kB/s | 419.67 kB/s–422.27 kB/s | 421.60 kB/s | -0.35 kB/s | |
| 512.14 kB/s | 510.77 kB/s–512.93 kB/s | 509.86 kB/s | -2.28 kB/s | |
| 514.93 kB/s | 514.09 kB/s–515.04 kB/s | 512.47 kB/s | -2.45 kB/s | |
| 535.49 kB/s | 533.96 kB/s–536.25 kB/s | 531.58 kB/s | -3.90 kB/s | |
| 536.76 kB/s | 536.35 kB/s–538.91 kB/s | 534.20 kB/s | -2.56 kB/s | |
| 621.81 kB/s | 620.11 kB/s–623.73 kB/s | 620.31 kB/s | -1.50 kB/s | |
| 652.48 kB/s | 652.11 kB/s–652.81 kB/s | 654.99 kB/s | 2.50 kB/s | |
| 661.47 kB/s | 660.12 kB/s–662.62 kB/s | 661.12 kB/s | -0.35 kB/s | |
| 700.85 kB/s | 699.90 kB/s–704.64 kB/s | 700.23 kB/s | -0.63 kB/s | |
| 708.21 kB/s | 706.27 kB/s–709.89 kB/s | 707.13 kB/s | -1.08 kB/s | |
| 713.55 kB/s | 709.11 kB/s–713.99 kB/s | 713.26 kB/s | -0.29 kB/s |
Model terms, failed first attempt and fresh validation
42 clean runs: 33 primary and nine follow-up. Each used 15 seconds of warm-up and 60 seconds of measurement, on Industrial with the fixed movement/action schedule. The original model underestimated server outgoing rates in two of six evaluation runs, by up to 4,104 B/s (0.575%). Those failures were retained.
The revision added directed player pairs, N × (N − 1). Prior evaluation data became development data; six new final runs used configurations (11, 3, 3) and (12, 3, 4), each with three fresh seeds. The native evaluator agreed with the exported model for all 14 measured configurations.
| Resource | Fresh runs covered | Largest shortfall | Largest excess estimate | Allowance |
|---|---|---|---|---|
| Server sends | 6 / 6 | 0 B/s | 5034 B/s | 4705 B/s |
| Server receives | 6 / 6 | 0 B/s | 4743 B/s | 4562 B/s |
| Busiest client receives | 6 / 6 | 0 B/s | 813 B/s | 830 B/s |
| Busiest client sends | 6 / 6 | 0 B/s | 290 B/s | 314 B/s |
Six successful final runs are a small empirical check, not a peak-rate guarantee or production certification. The original report’s simultaneous upper failure-probability bound is about 69%: this small sample cannot establish a rare-failure rate.
Exact terms for the selected direction
Multiply each driver by its coefficient and add the results, in bytes per second. The native planner rounds each term upward to a whole byte/second before adding the empirical allowance. N = players, B = bow holders, S = shadow holders. A B × S term captures combined class effects; it cannot be assigned entirely to either weapon.
| Driver | Coefficient · B/s | Exact rational coefficient |
|---|---|---|
| 1 (intercept) | 50,760.783024 | 50760783024 / 1000000 |
| N (players) | 25,918.510664 | 25918510664 / 1000000 |
| S (shadow holders) | 183.673653 | 183673653 / 1000000 |
| N × B | 1,086.291830 | 1086291830 / 1000000 |
| N × S | 112.543722 | 112543722 / 1000000 |
| N × (N − 1) | 2,221.227989 | 2221227989 / 1000000 |
The supported study range is 8–12 players and up to four holders of each feature. New maps, weapon timings, class overlaps, firefight densities and player counts need their own measurements. CPU, GPU, burst traffic, queues and Internet conditions are outside this model, so it cannot calculate an overall player cap.
Observed configurations CSV ↓ · Exact terms, validation and source hashes JSON ↓
Trust the rules. Keep the evidence.
A good connection delivers the fight. The server still has to decide which actions are legal.
A connection cannot remove distance. Good netcode can stop wasting time.
Your game starts your movement locally, while the server checks it against the shared rules. Other players are reconstructed from timestamped updates so an uneven flow of packets does not have to become an uneven animation. Confirmed hits, shields and ammo belong to the server.
The goal is a fight you can read and trust. Local response, smooth remote motion and server validation solve different problems; no single tick-rate number replaces all three.
Proven ideas, fitted to SHADOWFRAG
Client prediction, reconciliation, snapshot interpolation and historical hit checks are established FPS techniques. SHADOWFRAG combines them with explicit identities for fast leaps, charged shots, teleports and respawns. Its own timing and combat rules sit above the transport.
Native QUIC carries both time-sensitive datagrams and reliable control data. Datagrams let newer state replace old state without waiting for a missing earlier snapshot. Important action results and projectile lifecycles still have game-level receipts and recovery. PicoQUIC with CUBIC is now the default for new game, Practice and dedicated-server launches. Quiche/CUBIC remains selectable. The current wire protocol is 37; clients and servers need compatible builds. A transport name by itself is not a latency result.
Do useful work, then let the worker wait
Player and projectile storage grows in stable pages. Native socket readiness, outgoing work and useful deadlines wake the network worker. Fresh scene fragments, urgent results, durable records and cosmetic events receive bounded service turns.
Receipt ownership prevents a retry from creating another unsent plaintext copy. Projectile-lifecycle recovery uses a bounded timing estimate; action and hit-result recovery keeps its shorter interval. A stale input-epoch grant is ignored when newer authoritative state has already superseded it. None of these changes relaxes movement deadlines, damage validation or historical hit bounds.
The 26–27 October LAN study keeps the configured shipping limit at 64 players including bots. Three clean 128-player Highlands FFA confirmations establish a conditional research result with synthetic protocol clients. Full Shogun AI, rendering, audio and broader Internet conditions need separate integrated qualification. Read the capacity results and the implementation changes.
For the underlying techniques, read Snapshot Interpolation by Glenn Fiedler, the QUIC transport standard, and the QUIC datagram extension. The measurements on this page come from SHADOWFRAG’s own retained test records.
Fair play starts with the server
The client requests a move or an attack; it does not award itself damage. The server checks equipment, cooldowns, timing, life and target eligibility. Repeated messages keep their identity, and old messages cannot borrow a new player’s identity after a respawn or reconnect. Packet and queue bounds also limit the work an invalid request can create.
Those safeguards matter, but they are not a claim that cheating is impossible. Competitive demo recordings provide additional evidence for review. Read how player and referee demos work.
Still on the test bench
Mode-specific objective updates, safe timer anchors, acknowledged scene deltas and projectile relevance are opportunities to test—not savings included in these charts. Each needs a recovery rule for lost packets, late joins, respawns and changing match state.
No jargon left behind.
The words used in the lab, in plain English.
- Weapon-request feedback
- The time for a software attack request to receive its outcome or acceptance. The current study separates it from projectile flight and contact time.
- Input-buffer handoff
- A coordinated change to the input schedule shared by a client and server. The direct-LAN confirmation screen required zero such changes during a run.
- Research envelope
- The specific map, equipment, machines and conditions under which a test passed. It is separate from the game’s configured player limit.
- Prediction
- Your game starts your movement locally instead of waiting for a round trip to the server.
- Reconciliation
- The client corrects a prediction from the server’s answer, then replays inputs that still need to be applied.
- Snapshot / scene
- A timestamped description of the players, not an image or video frame.
- Interpolation
- Drawing a smooth path between known states, using a small buffer to absorb uneven packet arrival.
- Hit reference
- The eligible scene and aiming context attached to a shot. It is not hardware proof of which pixels reached the monitor.
- Tick rate
- How often the server advances game rules. 128 Hz means one step every 7.8125 ms; it is not your ping.
- p99
- The 99th percentile: about 99 out of 100 samples are at or below this value. It is not a maximum.
- Fanout
- Sending information about many players to many recipients. More players grow both sides of that work.
- Payload / overhead
- Payload is the game’s message. Overhead includes the envelopes and transport work needed to deliver it.
- Packet loss / jitter
- Packets can disappear or arrive unevenly. Redundancy, receipt recovery and smoothing address different parts of that problem.