<div dir="ltr">I've had decent success with a (non-public) MMO-like game engine using processes in three ways:<div><br></div><div>1) process per player (user object, connection detail, metadata)</div><div>2) process per game entity (location, state)</div><div>3) process per region (quadtree or octree populated coordinate)</div><div><br></div><div>and it all works well with some provisos.</div><div><br></div><div>The positives I've found so far:</div><div><br></div><div>1) Erlang's got great libraries for writing MMO-like systems, out of the box</div><div>2) Erlang's scheduler exists, and does a reasonably good job</div><div>3) The actor model wins the tradeoff war against all other concurrency models for my use case (and I suspect many/most MMO use cases)</div><div>4) Erlang distribution exists, and does a reasonably good job</div><div>5) Erlang's deployment story, once you puzzle it out, is pretty great</div><div><br></div><div>The negatives I've found so far:</div><div><br></div><div>1) Out of the box, erlang's shared state is both much larger and much slower than, e.g., your usual bespoke C++ memory slab</div><div>2) Straight line computation can be 100x slower than C++ on, e.g., intensive math tasks</div><div>3) NIFs that do primarily memory allocation/deallocation can be no faster than native Erlang</div><div>4) Erlang's scheduler can still have nontrivial jitter at 99.9pct, but you can write an almost-isochronous scheduler in C++</div><div>5) Navigating through 1-4 above can be problematic in the absence of a highly skilled and experienced team in some use cases</div><div>6) It is nontrivial to form that highly skilled and experienced team, even if you have highly skilled and experienced developers open to learning Erlang</div><div>7) Much of the popular erlang tooling is buggy, idiosyncratic, and non-orthogonal; picking the right mix is nontrivial</div><div><br></div><div>Although it is not fully baked yet, and may in fact never be fully baked, I would recommend checking out Pony (<a href="http://www.ponylang.org/">http://www.ponylang.org/</a>), which is essentially a well-typed, memory-safe, race-safe Erlang-like minimal C++ with high performance and the actor model.  For teams that are coming from C++ and enjoy the affordances of high performance languages but want better equipment and the actor model, that direction might be a more natural fit.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 20, 2016 at 8:51 AM, Miles Fidelman <span dir="ltr"><<a href="mailto:mfidelman@meetinghouse.net" target="_blank">mfidelman@meetinghouse.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <p>On 9/20/16 10:42 AM, Daniel Goertzen wrote:<br>
    </p>
    <blockquote type="cite">
      <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>
      </div>
    </blockquote>
    <br></span>
    I'm not actually sure that you'd need to run items synchronously in
    an actor based design.  <br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<span class=""><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr"><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>
      </div>
    </blockquote>
    <br></span>
    Now isn't that an interesting thought!<span class="HOEnZb"><font color="#888888"><br>
    <br>
    Miles</font></span><div><div class="h5"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr"><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" target="_blank">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.<wbr>cfm?id=2577389&CFID=787355984&<wbr>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>
            </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>______________________________<wbr>_________________
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/<wbr>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>
            ______________________________<wbr>_________________<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/<wbr>listinfo/erlang-questions</a><br>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
    <pre cols="72">-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra</pre>
  </div></div></div>

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