CQRS & similarities to multiplayer game networking

[Anders Storhaug]

Hi all,

I was reading through this article, which is about multiplayer game network programming, and I just thought it was interesting to draw a parallel between CQRS+ES and the Client-Side Prediction multiplayer networking architecture. In a multiplayer game that uses this networking architecture, packets contain batches of commands, which are applied immediately on the local client & sent to the server. At some moment later, the client verifies its prediction with the server's response. Here, when the client & server disagree, this is the analog to a concurrency error. This is exactly what Greg describes as a solution for occasionally connected clients: apply commands locally (prediction), verify state later with server.

What's interesting here is how "concurrency" issues are dealt with in the multiplayer networking architecture:

The solution is to keep a circular buffer of past character state and input for the local player on the client, then when the client receives a correction from the server, it first discards any buffered state older than the corrected state from the server, and replays the state starting from the corrected state back to the present “predicted” time on the client using player inputs stored in the circular buffer. In effect the client invisibly “rewinds and replays” the last n frames of local player character movement while holding the rest of the world fixed. 

This could also be done with CQRS+ES and occasionally connected clients, but however is probably overkill, since in most cases it's acceptable to just reconstruct state from the beginning (replay all events rather than last n). 

Anyway, I noticed this correlation quite early on after learning about CQRS+ES, but I thought I'd share this article for others that may find the correlation interesting. Furthermore, it's interesting to think of these game's replay features as a CQRS system replaying events, as they are absolutely equivalent. Also, each players camera position is essentially built off of read models, etc etc. I just think that it's interesting how this architecture has been used publicly, though in disguise, since 1996 (Duke Nukem 3D).

[Jeffrey Fritz]

I was actually swapping tweets with Rinat about this one..  

Just consider the amount of networking and packet swapping / read model logic around the MMO game 'World of Warcraft' with 10M+ users, that is a daunting task.

Jeff

[davidz]

That's the easy bit IMHO. It's the race conditions and sequencing(lag
and ping rates) that is insane. But they minimize by culling events
based on bsp trees constructed from view (player position in 3d space)
frustum culling (we call it vertical scaling ) by realms (we call it
horizontal scaling).

You quite often see players pop into your view (eventual consistency )
but once you see them and there in your view/node things smooth
out(and only then less culling if events take place I.e jumping/
running etc) So it looks massive but it's only massive based on what
you see.

For some reason I think it much easier for massively multiplayer games
because really you don't care in a real time manner that someone you
can't see does something, whereas in the web world you cannot do this
in massively collaboration systems (lol did I just make a new flavour
of the week concept in the enterprise world )

On Jun 6, 10:07 pm, Jeffrey Fritz <jeffreytfr...@gmail.com> wrote:
> I was actually swapping tweets with Rinat about this one..
>
> Just consider the amount of networking and packet swapping / read model
> logic around the MMO game 'World of Warcraft' with 10M+ users, that is a
> daunting task.
>
> Jeff
>

> On Wed, Jun 6, 2012 at 5:09 AM, Anders Storhaug <storhau...@gmail.com>wrote:
>
>
>
>
>
>
>
> > Hi all,
>

> > I was reading through this article<http://gafferongames.com/networking-for-game-programmers/what-every-p...>,

> > which is about multiplayer game network programming, and I just thought it
> > was interesting to draw a parallel between CQRS+ES and the Client-Side
> > Prediction multiplayer networking architecture. In a multiplayer game that
> > uses this networking architecture, packets contain batches of commands,
> > which are applied immediately on the local client & sent to the server. At
> > some moment later, the client verifies its prediction with the server's
> > response. Here, when the client & server disagree, this is the analog to a
> > concurrency error. This is exactly what Greg describes as a solution for
> > occasionally connected clients: apply commands locally (prediction), verify
> > state later with server.
>
> > What's interesting here is how "concurrency" issues are dealt with in the
> > multiplayer networking architecture:
>
> >> The solution is to keep a circular buffer of past character state and
> >> input for the local player on the client, then when the client receives a
> >> correction from the server, it first discards any buffered state older than
> >> the corrected state from the server, and replays the state starting from
> >> the corrected state back to the present “predicted” time on the client
> >> using player inputs stored in the circular buffer. In effect the client
> >> invisibly “rewinds and replays” the last n frames of local player character
> >> movement while holding the rest of the world fixed.
>
> > This could also be done with CQRS+ES and occasionally connected clients,
> > but however is probably overkill, since in most cases it's acceptable to

> > just reconstruct state from the beginning (replay *all* events rather