8000 N23: Dango and CrystalOrb: Clarify the comparison between GGPO and Cr… · ErnWong/rust-gamedev.github.io@45e4089 · GitHub
[go: up one dir, main page]

Skip to content

Commit 45e4089

Browse files
committed
N23: Dango and CrystalOrb: Clarify the comparison between GGPO and CrystalOrb
1 parent 5a95999 commit 45e4089

File tree

1 file changed

+3
-2
lines changed

1 file changed

+3
-2
lines changed

content/news/023/index.md

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -141,8 +141,9 @@ _Interactive [demo][crystalorb-demo] that uses the [Rapier] physics engine._
141141
fast-paced client-server games synchronize their game state across multiple
142142
clients. Just like [backroll-rs] and [GGRS], each CrystalOrb client predicts
143143
the next game state without waiting for other remote players' inputs to arrive.
144-
Unlike backroll-rs's and GGRS's peer-to-peer approach, CrystalOrb relies on
145-
having a server to send snapshots of the entire game state to each client, and
144+
Unlike backroll-rs's and GGRS's peer-to-peer approach which only send input
145+
data between its peers, CrystalOrb relies on having a server to send
146+
authoritative snapshots of the entire game state to each client. In response,
146147
each client unconditionally rolls-back to that snapshot. Although this may lead
147148
to higher network and memory usage, it means that CrystalOrb clients can join
148149
and leave at any time, and games that cannot guarantee full-determinism can

0 commit comments

Comments
 (0)
0