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

Garrett Smith g@REDACTED
Wed Jul 16 05:19:10 CEST 2014


On Tue, Jul 15, 2014 at 12:42 PM,  <lloyd@REDACTED> wrote:
> Hi Felix,
>
> Thanks for helping me think this through.
>
> - Players do not interact. Each player is playing against the "real world,"
> e.g. results of their actions. Think of it as project planning with many
> many contingencies. I'd say "expert system," but that sounds rather hoity
> toity. I say "game" only in the sense that there are reward points for
> successful action.
>
> Loop is basically:
>
> - gather facts
> - make plan
> - take action
> - evaluate results

This is a concrete actionable problem - build the loop. This is
something you could build with a simple process loop/server just to
see how things are working (Joe's book is a great resource for taking
this lower level/direct approach). Later you can convert this over to
a gen_server or e2 service, plugging it into a proper OTP app.

But I would not worry about "proper" anything until you have made more
progress on the core problem, which maybe you're describing in these
bullet points.

> - There are universal resources accessed by player state but these, as a
> whole, are static text, links, and images; wild-eyed estimate: 10 megabytes

I'd hack and slash this -- hard code stuff into source files -- just
get it working.

In the abstract you can serve things via named services very easily.

> - I estimate that each player will store less than three megabytes of
> private data.

What's the easiest, most direct imaginable way to do this in Erlang?
Do that. (hint: dets)

> - We're not dealing with elaborate graphics or animations. Only latency is a
> logic tree or inference engine evaluating facts; e.g. (Looking at Erlang
> eres/seres; but I may be able get away with something more simple minded).
>
> Latency, in other words, is a function of how many private and shared
> database lookups are necessary to evaluate a set of condition -> action
> rules. Effective state management should help me keep rule sets fairly
> minimal.

If you can get this stuff working in some fashion -- forget databases,
keep it in memory, loaded from dev/test source files or config files
that you can file:consult -- you can back your way into
persistence/recovery later. And "latency optimization" problems even
later.

> Prospects for this game are in the 200K range, but I'm successful with low
> hundreds of players.

How about stating with one player? Then two.

> Ad hoc querying is not necessary.

I suspect though your problem is where to start. What's the most
*obvious* thing that you should see working first? It's certainly not
scaling to 200K anything. It's not latency. Is it the loop above?
Something else?

Forget design - stumble through! Erlang is great for that :)

Garrett



More information about the erlang-questions mailing list