[erlang-questions] game engines?

Tue Sep 20 18:22:15 CEST 2016

I've had decent success with a (non-public) MMO-like game engine using
processes in three ways:

1) process per player (user object, connection detail, metadata)
2) process per game entity (location, state)
3) process per region (quadtree or octree populated coordinate)

and it all works well with some provisos.

The positives I've found so far:

1) Erlang's got great libraries for writing MMO-like systems, out of the box
2) Erlang's scheduler exists, and does a reasonably good job
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)
4) Erlang distribution exists, and does a reasonably good job
5) Erlang's deployment story, once you puzzle it out, is pretty great

The negatives I've found so far:

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
2) Straight line computation can be 100x slower than C++ on, e.g.,
intensive math tasks
3) NIFs that do primarily memory allocation/deallocation can be no faster
than native Erlang
4) Erlang's scheduler can still have nontrivial jitter at 99.9pct, but you
can write an almost-isochronous scheduler in C++
5) Navigating through 1-4 above can be problematic in the absence of a
highly skilled and experienced team in some use cases
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
7) Much of the popular erlang tooling is buggy, idiosyncratic, and
non-orthogonal; picking the right mix is nontrivial

Although it is not fully baked yet, and may in fact never be fully baked, I
would recommend checking out Pony (http://www.ponylang.org/), 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.

On Tue, Sep 20, 2016 at 8:51 AM, Miles Fidelman <mfidelman@REDACTED>
wrote:

> 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> 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 listerlang-questions@REDACTED://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
>> 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
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160920/e87af856/attachment.htm>