<div dir="ltr">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.<br><br>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?<br><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 19, 2016 at 10:55 AM Miles Fidelman <<a href="mailto:mfidelman@meetinghouse.net">mfidelman@meetinghouse.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <p>Thanks to all for your responses.</p>
    <p>Re. a couple of points here, might I ask a few follow-up
      questions:<br>
    </p></div><div bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <p>On 9/18/16 1:37 PM, Lutz Behnke wrote:<br>
    </p>
    <blockquote type="cite">Hello,
      <br>
      <br>
      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):
      <br>
      <br>
      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.
      <br>
    </blockquote>
    <br></div><div bgcolor="#FFFFFF" text="#000000">
    Well yes, but is that not where Erlang shines - being able to
    maintain huge numbers of processes (or, in this case, little state
    machines)?</div><div bgcolor="#FFFFFF" text="#000000"><br>
    <br>
    <blockquote type="cite">
      <br>
      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.
      <br>
    </blockquote>
    <br></div><div bgcolor="#FFFFFF" text="#000000">
    I'm actually thinking about military simulation - where the model is
    essentially:<br>
    <br>
    - 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)<br>
    <br>
    - 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<br>
    <br>
    - everything is synchronized by GPS time-stamp<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Then, I discovered Erlang.  And I started thinking - why not just
    have a process per object.</div><div bgcolor="#FFFFFF" text="#000000"><br>
    <br>
    <blockquote type="cite">
      <br>
      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.
      <br>
      <br>
      Please excuse me beating my own drum, but I have implemented a
      prototype of such an engine
(<a href="http://dl.acm.org/citation.cfm?id=2577389&CFID=787355984&CFTOKEN=91169762" target="_blank">http://dl.acm.org/citation.cfm?id=2577389&CFID=787355984&CFTOKEN=91169762</a>).
      Unfortunately, for legal reason, I cannot make the code publicly
      available yet.
      <br>
    </blockquote>
    <br></div><div bgcolor="#FFFFFF" text="#000000">
    Any chance of arranging a copy that's not behind a paywall?<br>
    <br>
    <br>
    Thanks,<br>
    <br>
    Miles<br>
    <br>
    <br>
    <blockquote type="cite"></blockquote></div><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite">
      <br>
      mfg lutz
      <br>
      <br>
      Am 18.09.2016 um 04:11 schrieb Miles Fidelman:
      <br>
      <blockquote type="cite">Hi Folks,
        <br>
        <br>
        I'm curious, has anybody written an Erlang-based game engine
        that
        <br>
        implements a process per game entity?
        <br>
        <br>
        I've been been finding various examples of Erlang being used to
        manage
        <br>
        user sessions, and other aspects of MMORPGs - but nothing that
        simply
        <br>
        does the obvious - treating each object, player, etc. as an
        Erlang process.
        <br>
        <br>
        Am I missing something?
        <br>
        <br>
        Thanks,
        <br>
        <br>
        Miles Fidelman
        <br>
        <br>
        <br>
      </blockquote>
      <br>
      <br>
      <br>
      <fieldset></fieldset>
      <br>
      </blockquote></div><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite"><pre>_______________________________________________
erlang-questions mailing list
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
    </blockquote></div><div bgcolor="#FFFFFF" text="#000000">
    <br>
    <pre cols="72">-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra</pre>
  </div><div bgcolor="#FFFFFF" text="#000000"></div>

_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div></div>