[erlang-questions] What is best way to maintain state in a web-based multiplayer game?
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
> - 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
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
> 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?
Forget design - stumble through! Erlang is great for that :)
More information about the erlang-questions