On Feb 22, 6:00 pm, 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-erlang [2] http://www.erlang-factory.com/conference/London2011/speakers/PaoloNegri [3] http://www.erlang-factory.com/conference/SFBay2011/speakers/PaoloNegri Thanks. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
