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

[Lloyd R. Prentice]

Ah, Garrett, you are so damned smart! You hit the nail dead on the head:

"I suspect though your problem is where to start."

I can see most of the pieces, but they are many and each distracts in my mind from the other. This, I suppose, is why I have been obsessed with the idea of architecture; e.g. How the pieces fit together.

But your slice-and-dice the big problems into little problems makes imminent good sense. I shall  do exactly that.

Thank you for dispersing one layer of fog.

All the best,

Lloyd


Sent from my iPad

> On Jul 15, 2014, at 11:19 PM, Garrett Smith <g@REDACTED> wrote:
> 
>> 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