[erlang-questions] What is best way to maintain state in a web-based multiplayer game?

[Felix Gallo]

I think you have some more marble to cut away before the shape of the
problem begins to reveal itself.

* do the players interact with each other directly?  If so, what state do
they share and how much?  Is there a separation between 'state for
everyone' (e.g. world of warcraft: the entire world geometry and all 3d
models are gigabytes of static data that are stored on the local filesystem
and not kept 'live' in memory) and 'player state'?  What is the size and
nature of each type of state?

* what are the constraints around latency -- does it look more like a real
time game (e.g. street fighter, counterstrike, league of legends) where,
e.g., 250 ms of latency is unacceptable to the experience, or more like a
turn based game (e.g. chess, poker, backgammon) where latency of 3s is
tolerable?  This drives certain considerations; e.g., you may be able to
use a slightly lower performance but more reliable database system for the
latter case.

* what is the shape and nature of your cost envelope?  If you are running
server infrastructure for a game, then you may need to take special
measures to ensure that your costs remain beneath your gross profit.

Since, as you say, managing game state is such a giant pain in the ass, my
general best practice when I do exactly this thing as part of my day job is
to first write down all of the different kinds of state, their approximate
quantity in bytes per player/world/universe/shard/whatever, and then do
some spreadsheet math to figure out what I can get away with.

Example: Game is Facebook-style web game like Farmville.  State can be
boiled down to a binary data structure that is 4 kilobytes in size per
player.  Expected profit per user is on the order of pennies.  Tens of
millions of users expected.  Solution: save state in the user's own browser
via encrypted cookie, use tiny database (sqlite, mysql, etc.) for
leaderboards and sending seeds between players.

Example: Game is World of Warcraft style MMO but you're trying to do it in
the browser so can't download gigabytes.  So you must shard each zone into,
say, a 50 megabyte downloadable size.  Zone shards are static so can be
files.  Private player data (e.g. inventory, raid history, message log) is
maybe 1 megabyte; public player data (e.g., x/y/z coordinates, avatar skin)
is maybe 30K and shared across the entire world (but usually limited to a
shard), needs fast access though as the world ticks at 30 frames per second
and you need to do distance calculations, etc.  Store the public player
data in memory, dets (per shard) or redis depending on whether you want raw
speed, resiliency, or tooling.  Store the private data in memory, dets,
redis, or mysql, depending on speed, resiliency, tooling, cost and
analytics requirements.

Generally I use ets for fast-access random-lookup state that has to get
shared between processes, redis for fast-enough (still plenty fast)
random-lookup state that has to be able to get large and/or survive system
crashes or writeoffs (via slave replication and aof, rather than
clustering), mysql for mass market mediocre state storage where the client
has pre-existing infrastructure and ad hoc querying is important, postgres
for green fields state storage where ad hoc querying is important, and
thankfully so far I have been able to avoid having to use inconsistent data
stores in production.  I wouldn't ever consider dets or mnesia because
equivalently-functional tools exist that are radically more popular and
have better tooling, capability, characteristics or safety guarantees.

F.



On Tue, Jul 15, 2014 at 10:03 AM, Lloyd R. Prentice <lloyd@REDACTED>
wrote:

>
> I'm thinking through the design of a web-based multiple-player game. Each
> player maintains a private database--- most likely dets. Each player moves
> through nested finite state machines. Each player may be logging in or out
> at any state of play.
>
> At this point my grasp of Erlang architecture breaks down. I don't
> understand how best to:
>
> - parse game structure across players, processes, and directories
> - maintain player state between sessions
>
> At this point in my Erlang education I feel like I know the words but
> can't play the music.
>
> I'd much grateful for any and all ideas and suggestions.
>
> Many thanks,
>
> LRP
>
> Sent from my iPad
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140715/c98f0ba0/attachment.htm>