<schramm.i...@googlemail.com> wrote: > Does somebody ever used Erlang to program game servers? Is there any > real live industrial game solution written in Erlang?
I use it alongside rabbitmq and a use the whole 'eveything is a process' method. Although I haven't released it and scaled it yet, I hope it'll scale will. That is if the game needs to. Some of the links posted are interesting, you'll also get a lot of hits if you google 'erlang mmo'
It was interesting implementing things like game loops, pathfinding, chat, etc. Erlang so far has been a good choice.
(err, sorry, I'm used to using the android-dev list, forgot to hit reply-all)
<luismarianogue...@gmail.com> wrote: > On Tue, Jul 6, 2010 at 5:05 AM, ingo.schramm > <schramm.i...@googlemail.com> wrote: >> Does somebody ever used Erlang to program game servers? Is there any >> real live industrial game solution written in Erlang?
However, the Erlang piece seems to be mainly for NPC actors (ships (?)) and the AI associated with them... but that is just speculation after reading their development blog a year or two ago (I think that is when it went into production). They call it the "/Kourier"/ system.
For a normal MMO you would probably need a few NIFs to make everything as efficient as possible but its scalability should surpass other language implementations (with less lines of code and less complexity).
Miguel Morales wrote: > I'm developing a mobile 2D multiplayer rpg, although it's not open > source you can find my dev blog here: > http://developingthedream.blogspot.com/
> I use it alongside rabbitmq and a use the whole 'eveything is a process' method. > Although I haven't released it and scaled it yet, I hope it'll scale > will. That is if the game needs to. > Some of the links posted are interesting, you'll also get a lot of > hits if you google 'erlang mmo'
> It was interesting implementing things like game loops, pathfinding, > chat, etc. Erlang so far has been a good choice.
> (err, sorry, I'm used to using the android-dev list, forgot to hit reply-all)
> On Tue, Jul 6, 2010 at 5:09 AM, Mariano Guerra > <luismarianogue...@gmail.com> wrote:
>> On Tue, Jul 6, 2010 at 5:05 AM, ingo.schramm >> <schramm.i...@googlemail.com> wrote:
>>> Does somebody ever used Erlang to program game servers? Is there any >>> real live industrial game solution written in Erlang?
>>> I need to know this for some evangelization :)
For an MMO backend, erlang could be decent. Depending on how many external libraries you use or rather how many native libraries you need to interface with, it might not be too bad. No reason I can think of why you couldn't. For a regular game or for an MMO client however, I'm not so sure. For those, something like C# might be a better fit (easy to interface with C++, native or managed). As far as consoles go, I could see erlang running on a 360 fine, using all cores but not so much on a Wii (where you too often need to hand optimize code which will require C++/assembly) and not so much on the PS3 where you may get a hard time using the SPUs from erlang (as I'm guessing the VM won't run on them out of the box and you might have to spend considerable time to get erlang processes to run on SPUs (feasible I'm sure)).
You'll definitely need a large number of NIFs for allocating memory aligned binaries for all that data you need to process with SIMD instructions and all kind of other stuff too. Games where performance isn't a huge bottleneck or where is it easy to parallelize would be a good fit for erlang, such as the poker game mentioned. I could see a small company willing to invest in building their core tech in erlang but I doubt we'll see any big ones change any time soon. For them, it would make more business sense to build support applications with it (such as online presence stuff, debugging tools, test tools, data/code build tools, etc.), things you mostly access through a network or are distributed in nature.
The truth is that most game programmers out there are fundamentally imperative programmers. I work in the industry and frankly, I haven't met many programmers that have used functional p. languages beyond a few simple scripts or that have even played with them in the past. Most of them come from a C/C++ background and as such, if you are a company looking to hire talent and experience, you'll need to offer work in something they are familiar with. This is mainly why a language like C# has more chances of succeeding, if only because of the familiar syntax. I do believe the code quality would be higher if more of it was written in a functional language but I can't picture seeing it happening very fast. I do know of some studios using LISP variants and I also know they have a hard time hiring programmers (mostly hire seniors with functional p. experience and game experience, which is not so common).
Also keep in mind a substantial portion of the companies out there making video games are essentially microsoft shops. They run windows, use visual studio, etc. That means they have support directly from microsoft for all their products (compilers, linkers, sdks, etc.). There is a huge incentive to use microsoft products for them in development so even when an opportunity arises where they could build an application, they will often opt for C++ or C# (or a mix of both) because of that fact and the one mentioned above where that is where most of their talent pool lies. As such, for anyone part of such a project, it'll be an uphill battle. The state of things is unlikely to change anytime soon seeing three of the four biggest markets are PC gaming, console gaming (360 SDK pretty much requires windows/vs) and web based games (flash dev tools are mostly for windows, so is silverlight (who uses java anymore on the web anyway?)) The fourth being mobile games. (Mac/linux gaming omitted, while it is slowly picking up recently (specially noticeable with Stream), it isn't very big yet)
For erlang to make more headway into games, I believe they would need to make it easier to integrate into existing applications. It is fairly straightforward to integrate python, lisp, lua or even javascript into an existing application but I'm not sure I could say the same of erlang. Being easy to embed would be a great first step, allowing progressive transition from C++ into erlang (for PC at least). To use erlang on consoles, you'll need a beam to native compiler for sure as some consoles do not allow interpreted code to execute (ie: PS3, applies to mobile devices as well such as the iPhone/iPad). Even if it were for just a subset of erlang, an LLVM frontend could achieve that with backends for different target architectures. Thankfully the current generation of consoles is all powerpc based so that might not be that much work.
I for one would love to see erlang used more in games as well as their supporting applications :)
> However, the Erlang piece seems to be mainly for NPC actors (ships (?)) > and the AI associated with them... but that is just speculation after > reading their development blog a year or two ago (I think that is when > it went into production). They call it the "/Kourier"/ system.
> For a normal MMO you would probably need a few NIFs to make everything > as efficient as possible but its scalability should surpass other > language implementations (with less lines of code and less complexity).
> Miguel Morales wrote: > > I'm developing a mobile 2D multiplayer rpg, although it's not open > > source you can find my dev blog here: > > http://developingthedream.blogspot.com/
> > I use it alongside rabbitmq and a use the whole 'eveything is a process' > method. > > Although I haven't released it and scaled it yet, I hope it'll scale > > will. That is if the game needs to. > > Some of the links posted are interesting, you'll also get a lot of > > hits if you google 'erlang mmo'
> > It was interesting implementing things like game loops, pathfinding, > > chat, etc. Erlang so far has been a good choice.
> > (err, sorry, I'm used to using the android-dev list, forgot to hit > reply-all)
> > On Tue, Jul 6, 2010 at 5:09 AM, Mariano Guerra > > <luismarianogue...@gmail.com> wrote:
> >> On Tue, Jul 6, 2010 at 5:05 AM, ingo.schramm > >> <schramm.i...@googlemail.com> wrote:
> >>> Does somebody ever used Erlang to program game servers? Is there any > >>> real live industrial game solution written in Erlang?
> >>> I need to know this for some evangelization :)
<schramm.i...@googlemail.com> wrote: > Does somebody ever used Erlang to program game servers? Is there any > real live industrial game solution written in Erlang?
> I need to know this for some evangelization :)
> Cheers, > Ingo
> ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscr...@erlang.org
________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscr...@erlang.org
On Jul 8, 2010, at 4:27 AM, Nicholas Frechette wrote:
> hand optimize code which will require C++/assembly) and not so much > on the > PS3 where you may get a hard time using the SPUs from erlang (as I'm > guessing the VM won't run on them out of the box and you might have > to spend > considerable time to get erlang processes to run on SPUs (feasible I'm > sure)).
It's not clear that it _is_ feasible in any interesting sense. The SPUs are essentially numeric vector engines. They have 128 registers, each 128 bits wide; loads are only 128 bits (16 bytes) and stores are only 128 bits (16 bytes). Memory is byte addressed and addresses are 32 bits, but the 2009 manual talks about 256 kB.
One could imagine SPU _nodes_ doing vector crunching that Erlang processes running on the PPU communicated with as if Erlang. But Erlang would not be the language of choice for programming SPUs. (An APL dialect would be ideal, or Fortran 95.)
________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscr...@erlang.org
> On Jul 8, 2010, at 4:27 AM, Nicholas Frechette wrote:
> > hand optimize code which will require C++/assembly) and not so much > > on the > > PS3 where you may get a hard time using the SPUs from erlang (as I'm > > guessing the VM won't run on them out of the box and you might have > > to spend > > considerable time to get erlang processes to run on SPUs (feasible I'm > > sure)).
> It's not clear that it _is_ feasible in any interesting sense. > The SPUs are essentially numeric vector engines. They have 128 > registers, each 128 bits wide; loads are only 128 bits (16 bytes) > and stores are only 128 bits (16 bytes). Memory is byte addressed > and addresses are 32 bits, but the 2009 manual talks about 256 kB.
> One could imagine SPU _nodes_ doing vector crunching that Erlang > processes running on the PPU communicated with as if Erlang. But > Erlang would not be the language of choice for programming SPUs. > (An APL dialect would be ideal, or Fortran 95.)
Though James Hague has mainly talked about client-side game programming, and mostly separately from Erlang topics, his writings are on both Erlang and games is fascinating, and even where there's no clear overlap, they perhaps be a source of insights on this topic. Besides which, reading him on these subjects leads you compulsively onto other programming topics he's covered, and before you know it, you've eaten the *whole bag* of potato chips ;-)
>To use erlang on consoles, you'll >need a beam to native compiler for sure as some consoles do not allow >interpreted code to execute (ie: PS3, applies to mobile devices as well such >as the iPhone/iPad).
Not true about the PS3. Using Lua as a scripting language is common. (It's also used in iPhone games.)
A bigger problem is that BEAM relies on gcc extensions for speed, so you have to take the hit if you're using platform where a specific C compiler is mandated.
While yes the SPUs are mainly for vector processing, imo, they could be suited quite well in practice for erlang processes. 256kb is total space they have for code/data as such would be great for small processes. Erlang processes already have all their data immutable meaning this would imply little need to dma info in/out of spus. While not designed for it, the SPUs can still be used for general processing and in fact, it is better to use them with something they aren't so good at rather than not use them at all. You'll find that a large number of ps3 games, even today make use of less than 75% of the SPUs.
Since most erlang applications are already message passing based, the processes need not share their memory with each other. Obviously, the size being the key factor here, one would still have to fit the code in <150kb to be able to do much with the processes. For long lists processing or large binaries, one might be able to do double buffering (or tripple) and still keep decent speeds. This could be done in erlang with minimal nif support, see below.
I'd see it like this: you'd spawn a process, you'd mark it as being "spu friendly" so that the spus can find it when they look for the next process to execute. SPUs would then dma the code & process data and run it and then move on to the next process. For long running processes, one could artificially "yield" to allow the spu to run another task before returning to it, something like a yield() nif. Obviously, only a subset of erlang would run out of the box, as things like io/kernel stuff would require message passing with a process on the PPU to execute them. I could see number crunching processes having a partner process on the PPU who's job would be to partition/segment the data and feed it to the SPU process on demand. The spu process could then do something like:
%% Process data in 50kb chunks, or perhaps less loop(SomeData, CurrPos) -> PPUPartner ! {send_next, CurrPos}, %% DMAed and sent to the PPU partner process executing on the PPU, might not be needed if the partner process just splits everything up front and queues all the processing messages or keeps track via the 'processed' message and keeps the queue full or at a decent size process current pos. stuff here, part 1... %% This doesn't have to be simd stuff, but very well could be (using NIFs) begin_receive_msgs(), %% NIF to start dma of messages, this would start streaming in the next data chunk, optional, only there to reduce latency from blocking receive statement which has to dma any new messages and wait for their data process current pos. stuff here, part 2... PPUPartner ! {processed, CurrPos, Result}, %% Sends the result calculated back to the ppu partner process to gather them back, come to think of it, this pattern is similar to map-reduce receive {data, Data, Pos} -> loop(Data, Pos), done -> ok end.
When the process ends execution, run GC if needed, wait for all pending DMAs to finish and grab the next one. On the PPU side, the partner process mostly idles waiting for the SPU to be done with the data and request more or send back results. It would do simple operations like appending the result to the head of a list for max performance then at the end, simple run a lists:reverse (as done traditionally anyway) or for long lists, run that operation on the SPUs as well (lists:spu_reverse?). 1 PPU partner process could easily split work among several SPU processes, feeding them and gathering/sorting their results.
Anyhow, sorry for the lengthy train of thoughts. It is a shame now that the PS3 is no longer supporting the "other OS" option otherwise I would love to experiment with something like this. Then again, it appears IBM will no longer develop new cell processors in the future so this effort might be moot. (I think they are stopping at something like 2 ppu hyper threaded cores (4 virtual cores) and 32 spu cores per chip? alas I forgot the details) I'm also not sure if the other os option allowed the OS to access to the spus in the first place as if I remember correctly, a number of things are "turned off" and inaccessible so mostly all of this talk is speculation :).
On Wed, Jul 7, 2010 at 8:05 PM, Richard O'Keefe <o...@cs.otago.ac.nz> wrote:
> On Jul 8, 2010, at 4:27 AM, Nicholas Frechette wrote:
>> hand optimize code which will require C++/assembly) and not so much on the >> PS3 where you may get a hard time using the SPUs from erlang (as I'm >> guessing the VM won't run on them out of the box and you might have to >> spend >> considerable time to get erlang processes to run on SPUs (feasible I'm >> sure)).
> It's not clear that it _is_ feasible in any interesting sense. > The SPUs are essentially numeric vector engines. They have 128 > registers, each 128 bits wide; loads are only 128 bits (16 bytes) > and stores are only 128 bits (16 bytes). Memory is byte addressed > and addresses are 32 bits, but the 2009 manual talks about 256 kB.
> One could imagine SPU _nodes_ doing vector crunching that Erlang > processes running on the PPU communicated with as if Erlang. But > Erlang would not be the language of choice for programming SPUs. > (An APL dialect would be ideal, or Fortran 95.)
On Thu, Jul 08, 2010 at 07:10:45PM +0900, Michael Turner wrote: > Though James Hague has mainly talked about client-side game programming, and > mostly separately from Erlang topics, his writings are on both Erlang and > games is fascinating, and even where there's no clear overlap, they perhaps > be a source of insights on this topic. Besides which, reading him on these > subjects leads you compulsively onto other programming topics he's covered, > and before you know it, you've eaten the *whole bag* of potato chips ;-)
I think I stumbled upon the original performance article in early 2005 and investigated Erlang at that time.
I was fairly burnt out on computers and especially software (after about 30 years of computers, last 20 of which were software). I was on a multi-month (year?) hiatus from software/systems creation in any form.
Then I stumbled upon James's article and actually got excited about software again! James introduced me to a tool, Erlang, that didn't get in my way, but actually, in a major way, facilitated my end results. And provided some income and lots of fun (still).
James, I doubt I ever said so until now, so *"Thank you"* for the original performance article and introduction to Erlang. (I have told the OTP team *Thank you* for Erlang, and do so again here).
Very O/T here, but ... I think the main reason I left three (or was it four) grammatical errors in my plug for Hague's blog is that I was trying to write as well as he does. I shouldn't try. Not that he needs *another* one for me, after what Michael McDaniel just wrote. Joe Armstrong says we need more books. I'm starting a "Draft James Hague" movement: write a book. I'll buy it even if he just ends up just *pretending* it's about Erlang. Better yet, team up with Nicholas Frechette to write Erlang for GPU Programming, or something similarly unlikely.
-michael turner
On Fri, Jul 9, 2010 at 12:00 AM, Michael McDaniel <erla...@autosys.us>wrote:
> On Thu, Jul 08, 2010 at 07:10:45PM +0900, Michael Turner wrote: > > Though James Hague has mainly talked about client-side game programming, > and > > mostly separately from Erlang topics, his writings are on both Erlang and > > games is fascinating, and even where there's no clear overlap, they > perhaps > > be a source of insights on this topic. Besides which, reading him on > these > > subjects leads you compulsively onto other programming topics he's > covered, > > and before you know it, you've eaten the *whole bag* of potato chips ;-)
> I think I stumbled upon the original performance article > in early 2005 and investigated Erlang at that time.
> I was fairly burnt out on computers and especially software > (after about 30 years of computers, last 20 of which were > software). I was on a multi-month (year?) hiatus from > software/systems creation in any form.
> Then I stumbled upon James's article and actually got excited > about software again! James introduced me to a tool, Erlang, > that didn't get in my way, but actually, in a major way, > facilitated my end results. And provided some income and > lots of fun (still).
> James, I doubt I ever said so until now, so *"Thank you"* for > the original performance article and introduction to Erlang. > (I have told the OTP team *Thank you* for Erlang, and do so > again here).
Hey Michael, I just have 20 years of computers and software but some 10-15 of the Internet with all those crappy quickies of time to market stuff and only Erlang saved me to still believe in the possibility of well crafted software :)
On Jul 8, 5:00 pm, Michael McDaniel <erla...@autosys.us> wrote:
> I think I stumbled upon the original performance article > in early 2005 and investigated Erlang at that time.
> I was fairly burnt out on computers and especially software > (after about 30 years of computers, last 20 of which were > software). I was on a multi-month (year?) hiatus from > software/systems creation in any form.
> Then I stumbled upon James's article and actually got excited > about software again! James introduced me to a tool, Erlang, > that didn't get in my way, but actually, in a major way, > facilitated my end results. And provided some income and > lots of fun (still).
> James, I doubt I ever said so until now, so *"Thank you"* for > the original performance article and introduction to Erlang. > (I have told the OTP team *Thank you* for Erlang, and do so > again here).
> > On Jul 8, 2010, at 4:27 AM, Nicholas Frechette wrote:
> > > hand optimize code which will require C++/assembly) and not so much > > > on the > > > PS3 where you may get a hard time using the SPUs from erlang (as I'm > > > guessing the VM won't run on them out of the box and you might have > > > to spend > > > considerable time to get erlang processes to run on SPUs (feasible I'm > > > sure)).
> > It's not clear that it _is_ feasible in any interesting sense. > > The SPUs are essentially numeric vector engines. They have 128 > > registers, each 128 bits wide; loads are only 128 bits (16 bytes) > > and stores are only 128 bits (16 bytes). Memory is byte addressed > > and addresses are 32 bits, but the 2009 manual talks about 256 kB.
> > One could imagine SPU _nodes_ doing vector crunching that Erlang > > processes running on the PPU communicated with as if Erlang. But > > Erlang would not be the language of choice for programming SPUs. > > (An APL dialect would be ideal, or Fortran 95.)
> On Jul 8, 2:05 am, "Richard O'Keefe" <o...@cs.otago.ac.nz> wrote: >>> On Jul 8, 2010, at 4:27 AM, Nicholas Frechette wrote:
>>>> hand optimize code which will require C++/assembly) and not so much >>>> on the >>>> PS3 where you may get a hard time using the SPUs from erlang (as I'm >>>> guessing the VM won't run on them out of the box and you might have >>>> to spend >>>> considerable time to get erlang processes to run on SPUs (feasible I'm >>>> sure)).
>>> It's not clear that it _is_ feasible in any interesting sense. >>> The SPUs are essentially numeric vector engines. They have 128 >>> registers, each 128 bits wide; loads are only 128 bits (16 bytes) >>> and stores are only 128 bits (16 bytes). Memory is byte addressed >>> and addresses are 32 bits, but the 2009 manual talks about 256 kB.
>>> One could imagine SPU _nodes_ doing vector crunching that Erlang >>> processes running on the PPU communicated with as if Erlang. But >>> Erlang would not be the language of choice for programming SPUs. >>> (An APL dialect would be ideal, or Fortran 95.)
Well, *that* definitely needed to be added to the Wikipedia article about Erlang. Done. Now all we need is a parse transform to make a new language called Cylon: Erlang with FORTH syntax. Just in case you ever wondered why you could never understood the Cylons.
On Tue, Feb 8, 2011 at 12:27 AM, Joe Armstrong <erl...@gmail.com> wrote: > On Thu, Jul 8, 2010 at 9:54 AM, ingo.schramm <schramm.i...@googlemail.com > >wrote:
> > Great! So many Erlang gamers out there!
> > Somebody told me, a Battlestar Galactica browser game is backed up by > > an Erlang engine.
> On Jul 8, 2:05 am, "Richard O'Keefe" <o...@cs.otago.ac.nz> wrote: > > > On Jul 8, 2010, at 4:27 AM, Nicholas Frechette wrote:
> > > > hand optimize code which will require C++/assembly) and not so much > > > > on the > > > > PS3 where you may get a hard time using the SPUs from erlang (as I'm > > > > guessing the VM won't run on them out of the box and you might have > > > > to spend > > > > considerable time to get erlang processes to run on SPUs (feasible > I'm > > > > sure)).
> > > It's not clear that it _is_ feasible in any interesting sense. > > > The SPUs are essentially numeric vector engines. They have 128 > > > registers, each 128 bits wide; loads are only 128 bits (16 bytes) > > > and stores are only 128 bits (16 bytes). Memory is byte addressed > > > and addresses are 32 bits, but the 2009 manual talks about 256 kB.
> > > One could imagine SPU _nodes_ doing vector crunching that Erlang > > > processes running on the PPU communicated with as if Erlang. But > > > Erlang would not be the language of choice for programming SPUs. > > > (An APL dialect would be ideal, or Fortran 95.)
There is another company who Erlang in games and that is Guild Software, http://www.guildsoftware.com/, who have an MMO game called Vendetta Online, http://www.vendetta-online.com/. They use Erlang in the servers. As far as I know they have been using Erlang for at least 3-4 years.
> Well, *that* definitely needed to be added to the Wikipedia article > about > Erlang. Done. Now all we need is a parse transform to make a new > language > called Cylon: Erlang with FORTH syntax. Just in case you ever > wondered why > you could never understood the Cylons.
> -michael turner
> On Tue, Feb 8, 2011 at 12:27 AM, Joe Armstrong <erl...@gmail.com> > wrote:
> > On Thu, Jul 8, 2010 at 9:54 AM, ingo.schramm > <schramm.i...@googlemail.com > > >wrote:
> > > Great! So many Erlang gamers out there!
> > > Somebody told me, a Battlestar Galactica browser game is backed up > by > > > an Erlang engine.
They also sell the MMO server/client here http://www.guildsoftware.com/naos/inbrief.html The Kourier system uses Erlang to model NPCs (Non-Person Characters) as actors (processes), so there might be AI work in there too.
> There is another company who Erlang in games and that is Guild Software, http://www.guildsoftware.com/, who have an MMO game called Vendetta Online, http://www.vendetta-online.com/. They use Erlang in the servers. As far as I know they have been using Erlang for at least 3-4 years.
>> Well, *that* definitely needed to be added to the Wikipedia article >> about >> Erlang. Done. Now all we need is a parse transform to make a new >> language >> called Cylon: Erlang with FORTH syntax. Just in case you ever >> wondered why >> you could never understood the Cylons.
>> -michael turner
>> On Tue, Feb 8, 2011 at 12:27 AM, Joe Armstrong <erl...@gmail.com> >> wrote:
>>> On Thu, Jul 8, 2010 at 9:54 AM, ingo.schramm >> <schramm.i...@googlemail.com >>>> wrote: >>>> Great! So many Erlang gamers out there!
>>>> Somebody told me, a Battlestar Galactica browser game is backed up >> by >>>> an Erlang engine.
Unfortunately, press releases don't qualify as reliable sources (RS) under Wikipedia's guidelines. Guild Software's NAOS engine seems to be known only through press releases, at this point. If we could get somebody from Guild to give a talk about NAOS (say, at the upcoming ACM SIGPLAN Erlang Workshop in Tokyo later this year), resulting in some paper that gets at least a page in a conference proceedings, it's Wikipedia RS, since the writing will have gone through something like peer review.
On Wed, Feb 9, 2011 at 8:34 AM, Michael Truog <mjtr...@gmail.com> wrote: > They also sell the MMO server/client here > http://www.guildsoftware.com/naos/inbrief.html > The Kourier system uses Erlang to model NPCs (Non-Person Characters) as > actors (processes), so there might be AI work in there too.
> On 02/08/2011 03:24 PM, Robert Virding wrote: > > There is another company who Erlang in games and that is Guild Software, > http://www.guildsoftware.com/, who have an MMO game called Vendetta > Online, http://www.vendetta-online.com/. They use Erlang in the servers. > As far as I know they have been using Erlang for at least 3-4 years.
> >> Well, *that* definitely needed to be added to the Wikipedia article > >> about > >> Erlang. Done. Now all we need is a parse transform to make a new > >> language > >> called Cylon: Erlang with FORTH syntax. Just in case you ever > >> wondered why > >> you could never understood the Cylons.
> >> -michael turner
> >> On Tue, Feb 8, 2011 at 12:27 AM, Joe Armstrong <erl...@gmail.com> > >> wrote:
> >>> On Thu, Jul 8, 2010 at 9:54 AM, ingo.schramm > >> <schramm.i...@googlemail.com > >>>> wrote: > >>>> Great! So many Erlang gamers out there!
> >>>> Somebody told me, a Battlestar Galactica browser game is backed up > >> by > >>>> an Erlang engine.
Unfortunately, press releases don't qualify as reliable source (RS) under Wikipedia's guidelines. Guild Software's NAOS engine seems to be known only through press releases, at this point. If we could get somebody from Guild to give a talk about NAOS (say, at the upcoming Erlang activity in the functional programming conference in Tokyo later this year), resulting in some paper that gets a page or so in a conference proceedings, it's Wikipedia RS, since it will have gone through something like peer review.
On Wed, Feb 9, 2011 at 8:34 AM, Michael Truog <mjtr...@gmail.com> wrote: > They also sell the MMO server/client here > http://www.guildsoftware.com/naos/inbrief.html > The Kourier system uses Erlang to model NPCs (Non-Person Characters) as > actors (processes), so there might be AI work in there too.
> On 02/08/2011 03:24 PM, Robert Virding wrote: > > There is another company who Erlang in games and that is Guild Software, > http://www.guildsoftware.com/, who have an MMO game called Vendetta > Online, http://www.vendetta-online.com/. They use Erlang in the servers. > As far as I know they have been using Erlang for at least 3-4 years.
> >> Well, *that* definitely needed to be added to the Wikipedia article > >> about > >> Erlang. Done. Now all we need is a parse transform to make a new > >> language > >> called Cylon: Erlang with FORTH syntax. Just in case you ever > >> wondered why > >> you could never understood the Cylons.
> >> -michael turner
> >> On Tue, Feb 8, 2011 at 12:27 AM, Joe Armstrong <erl...@gmail.com> > >> wrote:
> >>> On Thu, Jul 8, 2010 at 9:54 AM, ingo.schramm > >> <schramm.i...@googlemail.com > >>>> wrote: > >>>> Great! So many Erlang gamers out there!
> >>>> Somebody told me, a Battlestar Galactica browser game is backed up > >> by > >>>> an Erlang engine.
