in the cap theorem. game need Consistency (multiplayer) and Persistence (savegame)

I think availability is more about distribution than frame per second
if the code is idempotent with user actiob, we just store user action,
share then and expect same result from peer with same input.

the challenge would be to synchronize action history between peer using xmlrpc

build an event table youcan add but not modify
and the possibility to sync with another table
and make the table persistent
depending on the size that the event table could grow. it may or not be effective
a guy turning arround shooting every where would generate 20 events per seconds.
if an event weight 40bytes, an hour of gaming will take 2megabytes.
i will need to garbage collect the list. then i will need to serialize the entire game world

if we use simple server/client approach, then we only expose some database procedure on the rpc and the client will interpret it all.
bench xml-rpc scored [150-200] call per second with both small and big payload
it did same with two concurrent client. summing up to 300 call per second
ncurses can do 1000fps but i limit myself to 16 , to fit DOS PIT. so 32 call per second in direct streaming, all call will weight 40*25 char/cell with color code, one bytes and 2 int, ~5kb
and most submit will be really small