[erlang-questions] game engines?

[Miles Fidelman]

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
> 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/20160919/f56fc4ab/attachment.htm>