Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Chris Pressey <>
Fri Mar 16 08:16:44 CET 2001

Alexander Williams wrote:
> On Thu, Mar 15, 2001 at 01:46:30PM -0600, Chris Pressey wrote:
> > I'm working on a game myself; it's sort of an MUD/MUSE/IF/roguelike
> > thing, so I'd be especially interested in hearing about any online games
> > or other fun stuff that's been attempted in Erlang.
> Ooooh, now, this is fun: I was just thinking about Erlang-based MU*
> the other night (and, naturally, that led to my thoughts about Binary
> Strings vs List Strings; parsing eats up time in MU* design).

Indeed... I'm sticking to binaries and atoms whereever possible.

> Theoretically, a MU* implimented in Erlang could have easily
> distributable/extensible distributed databases; one could literally
> walk off the edge of one MU* and onto another hosted on another site
> and hardly know the difference ... except for any local player-mods
> that might have been made.  Strolling from a systemless SocialEM
> (Erlang MU*) onto a World of Darkness EM wouldn't necessarily give you
> stats and structure (though the WoD could be coded to stat you as Joe
> Average; capturing migrating processes would be nicely necessary).

Although I had no such lofty plans to start out with, these were some of
the strengths for why I picked Erlang to do this in.  Servers should be
able to treat each other as peers and refer clients to each other, and
distributed programming should make that easy, almost trivial.

> The main question that it occured to me to ask would be "How is the
> best way to allow programming/extending the live system?"  The
> facility for live upgrade of Erlang code gives us a direct hook into
> fixing things, but one has to impliment security on top of that.

Indeed, I thought about that a bit too.  A mechanism like Perl's
taint-checking would be nice.  Failing that, probably a little
object-manipulation language which is compiled into safe Erlang when

> Do
> we go with the LP-like model with directories of files which are then
> instanced into existance, or something more MUX-like with instances
> being live at all times but possibly inherited from?

This just being an experiment for me, I'm not really following any
particular model with much fidelity.

This started out as an experimental roguelike game in Perl, which
quickly got too complex to be easily maintainable.  I started
translating it to Erlang, but found I had a much easier time just
rewriting most of it.

All objects in my game are records in a monolithic mnesia table (which
is currently ram-and-disc, I will probably change that to ram-only with
periodic dumps in the future, for speed.)

There is a field 'pid' in the record definition.  Objects with 'agency'
have a pid associated with them.  Such objects can be NPC's (internal
bots), in which case the process is responsible for their AI.  Or they
can be human players or external bots, in which case there's a valid
value in the 'socket' field too.  So the difference between 'live' and
'inert' objects is merely that of an attached process.

I'm using a sort of 'object factory' approach where there are no
classes; instead, 'exemplars' which are copied and tweaked.  Exemplars
describe distributions for stats (e.g. strength = 3d6) while instances
have concrete values (e.g. strength = 15.)


"Ten short days ago all I could look forward to was a dead-end job as a
engineer.  Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies,
Esoteric Topics Mailing List:

More information about the erlang-questions mailing list