[erlang-questions] game engines?

Tue Sep 20 17:51:37 CEST 2016

On 9/20/16 10:42 AM, Daniel Goertzen wrote:

> Erlang processes shine when they can run asynchronously and in a 
> loosely coupled manner, so I am skeptical that a process-per-entity 
> would work well where the entities need to run synchronously (20 
> times/sec) and interact heavily.  For synchronous, interactive 
> behavior I suspect the solution you currently have (thread iterating 
> through objects) is simplest.

I'm not actually sure that you'd need to run items synchronously in an 
actor based design.

1.  Anything that's not doing anything can simply suspend itself until 
an incoming message triggers a state change.  That saves a LOT of cycles 
right there.

2. For things that are moving, I'm not sure how distributing time ticks 
to x000 processes, and then letting them do their thing, is any 
different than iterating through the same x000 processes.

What gets tricky, in any case, is line-of-sight calculations, and 
behaviors that are based on what each object sees.  That requires some 
form of global state, and operations on global state.  But that's a 
separate issue, and one that one also has when threading a chain of 
control through a bunch of objects - either way, one either has to do a 
global calculation, or each entity has to take a look around itself.

>
> I remember a discussion years ago about a simulation consisting of 
> ants randomly moving from square to square on a chess board where only 
> 1 ant is permitted on a square.  The discussion revolved around 
> process-per-ant and all the synchronization issues that it entailed.  
> It turned out that flipping things inside out and using a 
> process-per-*square* and representing the ants as messages passed 
> between them worked out much better. There are many ways to use 
> processes, and mapping them to your simulation's actors is not always 
> best.  Is there another way to apply many processes to a military sim?

Now isn't that an interesting thought!

Miles

>
>
> On Mon, Sep 19, 2016 at 10:55 AM Miles Fidelman 
> <mfidelman@REDACTED <mailto:mfidelman@REDACTED>> wrote:
>
>     Thanks to all for your responses.
>
>     Re. a couple of points here, might I ask a few follow-up questions:
>
>
>     On 9/18/16 1:37 PM, Lutz Behnke wrote:
>
>>     Hello,
>>
>>     assigning each object in the game gets difficult for a number of
>>     reasons, when trying to do this for an MMO, especially MMORPGs
>>     (characterized by a very large number of objects, and active
>>     entities):
>>
>>     You waste resources (CPU, RAM) when an object is currently not
>>     being referenced by an active entity (e.g. a client connection,
>>     thus and avatar or alternatively a Mob/NPC), since there is no
>>     other process that will send any messages.
>
>     Well yes, but is that not where Erlang shines - being able to
>     maintain huge numbers of processes (or, in this case, little state
>     machines)?
>
>
>>
>>     More importantly, should you scale your engine to multiple hosts,
>>     you either have to enforce a single process, requiring all
>>     updates and query messages to be routed to this proc. Or you will
>>     have to build some master/slave or peer to peer logic, which will
>>     ensure consistency in the face of CAP.
>
>     I'm actually thinking about military simulation - where the model
>     is essentially:
>
>     - every simulator (e.g., a flight sim, or a tank) is running on
>     its own machine, complete with local world model and image
>     generation (necessary to keep up with jitter-free image generation
>     during high-g turns - you don't want pilots to puke all over the
>     simulators)
>
>     - there's a lot of dead reckoning going on locally - the only
>     things that cross the network are deltas and events, generally
>     sent by multicast
>
>     - everything is synchronized by GPS time-stamp
>
>     I discovered Erlang when I realized that we (the company I worked
>     for) took a very different approach for simulating "virtual
>     forces" (think non-player characters) - when we simulated 1000
>     tanks, on one machine, each tank would be an object, and we had 4
>     threads winding their way through every object, 20 time a second. 
>     Turns out that the main loops are real spaghetti code that breaks
>     every time a new property gets added to an object.
>
>     I started wondering why we didn't just have a process per
>     simulated object - essentially the way we treated the
>     person-in-the-loop simulators.  The answer, of course, being
>     context switching overhead.
>
>     Then, I discovered Erlang.  And I started thinking - why not just
>     have a process per object.
>
>
>>
>>     Separating into a) the state of instances, which you can store in
>>     a KV-store and have b) a pool of generic procs, that will process
>>     the state with c) a set of modules that provides the logic for a
>>     particular object allows to push the state to the appropriate
>>     host. With a separate KV-store that can handle net-partition and
>>     node failure, you gain even a good amount of fault-resilience.
>>
>>     Please excuse me beating my own drum, but I have implemented a
>>     prototype of such an engine
>>     (http://dl.acm.org/citation.cfm?id=2577389&CFID=787355984&CFTOKEN=91169762).
>>     Unfortunately, for legal reason, I cannot make the code publicly
>>     available yet.
>
>     Any chance of arranging a copy that's not behind a paywall?
>
>
>     Thanks,
>
>     Miles
>
>
>>
>>     mfg lutz
>>
>>     Am 18.09.2016 um 04:11 schrieb Miles Fidelman:
>>>     Hi Folks,
>>>
>>>     I'm curious, has anybody written an Erlang-based game engine that
>>>     implements a process per game entity?
>>>
>>>     I've been been finding various examples of Erlang being used to
>>>     manage
>>>     user sessions, and other aspects of MMORPGs - but nothing that
>>>     simply
>>>     does the obvious - treating each object, player, etc. as an
>>>     Erlang process.
>>>
>>>     Am I missing something?
>>>
>>>     Thanks,
>>>
>>>     Miles Fidelman
>>>
>>>
>>
>>
>>
>>
>>     _______________________________________________
>>     erlang-questions mailing list
>>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>     http://erlang.org/mailman/listinfo/erlang-questions
>
>     -- 
>     In theory, there is no difference between theory and practice.
>     In practice, there is.  .... Yogi Berra
>
>     _______________________________________________
>     erlang-questions mailing list
>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>     http://erlang.org/mailman/listinfo/erlang-questions
>

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160920/41212c43/attachment.htm>