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

[Chris Pressey]

Alexander Williams wrote:
> On Fri, Mar 16, 2001 at 03:30:32PM +0100, Ulf Wiger wrote:
> > This can be done, as long as one doesn't make any assumptions about
> > Pid (it will change), and there's a stable state in which to do this.
> So, we end up needing another unique ID system.  (Gensym, come home,
> all is forgiven!)  I'd really like to shy away from the
> MU*-traditional form of just increasing integers, but ... it is simple
> and effective, I suppose.

My prototype currently uses just that, courtesy of
mnesia:dirty_update_counter.  References would also be sufficient, I
would think, considering they are IIRC unique into the billions.

Alexander Williams wrote:
> > I have no idea if my Erlang project will turn out anything like that,
> > though.  Currently my temptation is to have a more hierarchical,
> > abstract world, mainly because it would simplify it greatly if you could
> > just see everything in the current 'room' instead of calculating
> > line-of-sight to determine the set of visible objects.
> Ie. the "MUD" concept in which the universe is broken into groups of
> "cells" or rooms, and all things within a given cell can freely
> interact.  Its certainly the simplest means of implimenting a
> universe, and the easiest to explain to an outside observer.

"Because it is there" is also a reason to go around the mountain  :-)  I
got LoS working quite well last night, so I'm going to keep the
interface 'roguelike' and resist the temptation to resort to the simpler
hierarchical structure of a classical MU*.

That does mean I have to handle far more objects, though, as a single
large 'room' could be a hundred seperate wall/floor/ceiling blocks! 
There is correspondingly less emphasis on textual descriptions, though.

> The main reason to add a filesystem hierarchy to the system is to make
> it easy to modify things from INSIDE the system, on the fly.

But I do not understand how working in the filesystem is easier than
working in mnesia tables.  The main reason I see to go with the
filesystem is performance under the current mnesia.  If that were not a
problem, using mnesia only would be simpler (& maybe faster.)  Using the
filesystem is more complex for several reasons, e.g. not all filesystems
are created equal.

> One could, theoretically, lay a false filesystem hierarchy over the
> mnesia database itself ...

Well, no.  The game world is hierarchical, the database records are
hierarchical.  There is just a hierarchy, not a "false filesystem
hierarchy": that step is just outright skipped.  I think
mnesia+filesystem is a redundant combination too, I just think the
redundant part is the filesystem.

That doesn't rule out "uniform resource locators" which can look like
"item/weapon/sword/katana/magic.erl" - though granted Erlang will
probably not parse this quite as quickly as a filesystem would.  But
once you've referred to it once, you can use it's unique key to refer to
it quickly again.

Then again it's fairly clear we've got different games in mind.  I
wasn't at all planning to build or help build "the" Erlang MMUD... I
already have a game, I'm just trying to get it out of Perl and into
Erlang and experiment with making it multiplayer.  If I can provide
help, it'll probably be in the form of letting people learn from the
mistakes I make in my prototype anyway :-)

> > There are also some 'higher-order sense' that turn out to be useful.
> > For example, being able to see someone else move.  {see_move, Sender,
> > NewPosition} or something.
> Sure; defining the set of messages your Things can respond to is one
> of the basics of game design.  Allowing that kind of extensibility on
> a Thing by Thing basis is one of the advantages of being able to drive
> a generic core.  :)

Yes.  But there's always a tradeoff between generality and performance. 
If you're saying I should do an inheritance-tree-traversal every time a
message comes in, to find out what I should do, I don't agree.  That is
the most flexible system (and it is easy to write) but it is also one of
the least efficient.  In the interests of speed, all my 'instances' are
merely copies of older 'exemplar' objects, with some things changed; the
instance practically never 'defers' or 'delegates' to the exemplar.

_chris

-- 
"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, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html