[erlang-questions] game engines?

Tue Sep 20 15:36:17 CEST 2016


In a somewhat related topic (large-scale discrete event simulation in Erlang) - and even it is a shameless plug, sorry for that - there is also Sim-Diasca (http://sim-diasca.com/), a discrete event simulation engine released as free software. The goal is to perform the simulation of complex systems in a multi-agent way, with scalability in mind (thus in a parallel and distributed manner); of course simulation and game engines share quite a lot of architectural and software traits.

As for us, we used (and are still using) plain Erlang (not OTP, whether or not it is a good choice) and a lightweight layer above it to provide the object-oriented constructs we needed (multiple inheritance, polymorphism, etc.), on top of which the engine as such was built (to perform time synchronisation, support interactions and provide relevant properties like the respect of causality and reproducibility).

In this setting each model instance is represented by exactly one Erlang process, and it proved to be quite scalable (of course synchronisation has a cost, and surely one shall not expect perfect speed-up with this kind of simulations). Back in 2010, we already exceeded 1 million interacting model instances in a single simulation (and the models involved were not specifically lightweight…). Recently this work received a bit of third-party positive feedback [1].

So IMHO such use of Erlang seems to be a very good solution to cover the needs you mentioned (moreover using it for that did not inflict much headache).

Hope this helps,


[1] http://sbrc2016.ufba.br/downloads/Salao_Ferramentas/154234.pdf

Olivier Boudeville
EDF R&D, Département SINETICS, Groupe ASICS, Bureau O2-E10
7, Boulevard Gaspard Monge, 91120 Palaiseau, France

Tél. : +33 (0)1 78 19 43 63
Tél. mobile : +33 (0)6 16 83 37 22

De :  [mailto:]
Envoyé : mardi 20 septembre 2016 12:14
À : 
Cc : 
Objet : Re: [erlang-questions] game engines?

2016-09-19 17:55 GMT+02:00 Miles Fidelman <<mailto:>>
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.

Back in the day, there was the Sim94 troop simulation project, which was pretty successful - and way before Erlang got multicore support:

This related master's thesis might also be of interest (oops, turns out I was the examiner):
I also found this newer work while searching, but I haven't read it myself:
Finally, I found this, which made me double-check that I wasn't answering a post from 2012 :-) http://erlang.org/pipermail/erlang-questions/2012-March/065136.html


Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.

This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or virus-free.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160920/cfb08ae5/attachment.html>

More information about the erlang-questions mailing list