Received: by 10.43.117.132 with SMTP id fm4mr13501683icc.1.1329950539829;
        Wed, 22 Feb 2012 14:42:19 -0800 (PST)
X-BeenThere: clojure@googlegroups.com
Received: by 10.231.93.147 with SMTP id v19ls2370846ibm.1.gmail; Wed, 22 Feb
 2012 14:42:08 -0800 (PST)
Received: by 10.50.169.2 with SMTP id aa2mr66631igc.1.1329950528107;
        Wed, 22 Feb 2012 14:42:08 -0800 (PST)
Received: by 10.50.209.5 with SMTP id mi5msigc;
        Wed, 22 Feb 2012 13:34:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.29.1 with SMTP id f1mr3519929vdh.16.1329946442419; Wed, 22
 Feb 2012 13:34:02 -0800 (PST)
Authentication-Results: ls.google.com; spf=pass (google.com: domain of
 paolo.ne...@wooga.net designates internal as permitted sender)
 smtp.mail=paolo.ne...@wooga.net; dkim=pass
 header...@wooga.net
Received: by ge5g2000vbb.googlegroups.com with HTTP; Wed, 22 Feb 2012 13:34:02
 -0800 (PST)
Date: Wed, 22 Feb 2012 13:34:02 -0800 (PST)
In-Reply-To: <CAKAZBdehcLUUR=-aEEuaL7DgpL2DZyRx=DkSWgfzTq+VAxZJrQ@mail.gmail.com>
References: <3c68cc8b-bbdd-4753-81eb-0eebb5c14053@18g2000yqe.googlegroups.com>
 <CA+67v5_+X_91CQZTmZcHKXwNCiYnEiJ0A60XESSyoB85AskO7g@mail.gmail.com>
 <CAKAZBdfa+pHrKpMGYnvcya9zrjhnKJ+PmmuYfrqcuKbVwKnf6Q@mail.gmail.com>
 <CAL36E+uhzUSif+BF3VrY2RFSvgW1kcTwNc0M8JFhcpier=vvgA@mail.gmail.com> <CAKAZBdehcLUUR=-aEEuaL7DgpL2DZyRx=DkSWgfzTq+VAxZJrQ@mail.gmail.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8)
 AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11,gzip(gfe)
Message-ID: <b2c7d1b3-adbb-4872-aa61-1932dabc5e3e@ge5g2000vbb.googlegroups.com>
Subject: Re: clojure thesis opportunity
From: Paolo Negri <paolo.ne...@wooga.net>
To: Clojure <clojure@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Feb 22, 6:00=A0pm, Cedric Greevey <cgree...@gmail.com> wrote:
> On Wed, Feb 22, 2012 at 11:40 AM, Timothy Baldridge
>
> <tbaldri...@gmail.com> wrote:
> >> On the other hand, Lisp letting you update things on the fly is also
> >> of obvious value to an MMORPG, which tends to involve adding and
> >> tweaking stuff from time to time but you really don't want to take the
> >> game servers down, ever, if you can avoid it.
>
> > That's also a major feature of Erlang. On-the-fly code updating is
> > actually one of its strengths.
>
> >http://en.wikipedia.org/wiki/Erlang_(programming_language)#Hot_code_l...
>
> > That being said, the syntax of Erlang is so insanely bad, I can't
> > bring myself to touch it.
>
> Sounds like what we need is a Lisp with the actor model. Ideally,
> Clojure with a distributed version of agents, maybe built on top of
> agents and Java's RMI.
>
> Then again, what you said about Erlang's syntax lots of people say
> about Lisp's. ;)

Thanks everyone for the interesting replies and pointers to other
resources.

I find pretty intriguing that erlang and the actors came up in this
thread since we already do write game backend in erlang and we
reported reported regularly about our experience at conferences [1],
[2], [3].
Indeed the actor pattern is a very effective way of modeling game
servers and the erlang OTP framework offers out of the box with tools
and constructs that simplify dealing with the complexity of a
multitude of concurrently evolving states.

Still, the topic of this thesis is not really focused on game servers
but about improving how games are configured, balancing the values
that drive the evolution and progresse in virtual words is a very
interesting and complex task, configurations appears as naked data but
they actively drive the execution of many aspects of games, in some
way you might think about configuration as a form of execution plan
game logic, this is why having configuration in a form that can be
interpreted both as data and code is of special interest.
Another interesting aspect is that in our erlang game server we take
XML configurations files and generate code (each XML file is compiled
into an erlang module) so our servers effectively are configured by
code, not data, this also make it easier to upgrade configurations on
a running system thanks to the erlang hot code reload facilities,
changin configuration actually mean running a newer version of the
configuration code.

I'm looking forward to your comments and ideas on the topic.

[1] http://www.slideshare.net/wooga/from-0-to-1000000-daily-users-with-erla=
ng
[2] http://www.erlang-factory.com/conference/London2011/speakers/PaoloNegri
[3] http://www.erlang-factory.com/conference/SFBay2011/speakers/PaoloNegri