[erlang-questions] game engines?
Mon Sep 19 17:55:00 CEST 2016
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:
> 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
- 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
> Unfortunately, for legal reason, I cannot make the code publicly
> available yet.
Any chance of arranging a copy that's not behind a paywall?
> 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
>> Am I missing something?
>> Miles Fidelman
> erlang-questions mailing list
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions