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-questio...@erlang.org
Sergej
On Tue, Jul 6, 2010 at 10:05 AM, ingo.schramm
<schram...@googlemail.com>wrote:
openpoker is written in erlang
http://www.devmaster.net/articles/mmo-scalable-server/
http://github.com/wagerlabs/openpoker
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)
--
http://developingthedream.blogspot.com/,
http://diastrofunk.com,
http://www.youtube.com/user/revoltingx, ~Isaiah 55:8-9
Their engine is being sold/licensed here
http://www.guildsoftware.com/naos/
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.
Here is a paper on the topic
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.73.5033
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).
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 :)
2cents
Nicholas
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.)
Somebody told me, a Battlestar Galactica browser game is backed up by
an Erlang engine.
> To unsubscribe; mailto:erlang-questions-unsubscr...@erlang.org
*http://tinyurl.com/26dthru*
*
*
-michael turner
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.
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 :).
2cents :)
Nicholas
This is the article by James that introduced me to Erlang ...
http://www.dadgum.com/james/performance.html
(see also http://prog21.dadgum.com/11.html)
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).
~M
--
Michael McDaniel
Portland, Oregon, USA
http://trip.autosys.us
http://edids.org
-michael turner
we are currently developing an experimental browser game server in
Erlang, with game logic embedded in Lua.
Henning
On Jul 8, 5:00 pm, Michael McDaniel <erla...@autosys.us> wrote:
>
> This is the article by James that introduced me to Erlang ...
>
> http://www.dadgum.com/james/performance.html
>
> (see also http://prog21.dadgum.com/11.html)
>
> 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).
>
> ~M
>
> --
> Michael McDaniel
> Portland, Oregon, USAhttp://trip.autosys.ushttp://edids.org
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> Seehttp://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscr...@erlang.org
________________________________________________________________
> Great! So many Erlang gamers out there!
>
> Somebody told me, a Battlestar Galactica browser game is backed up by
> an Erlang engine.
>
>
There's a article about this here:
http://www.theregister.co.uk/2011/02/05/battlestar_galactica_mmp/
/Joe
-michael turner
Robert
----- "Michael Turner" <michael.eu...@gmail.com> wrote:
> 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
> <schram...@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.
> > >
> > >
> > There's a article about this here:
> >
> > http://www.theregister.co.uk/2011/02/05/battlestar_galactica_mmp/
> >
> >
> > /Joe
________________________________________________________________
-michael turner
-michael turner
On Wed, Feb 9, 2011 at 8:34 AM, Michael Truog <mjt...@gmail.com> wrote:
found it here
http://www.unitypark3d.com/ (related to Unity3d game engine)