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

[Alexander Williams]

On Sat, Mar 17, 2001 at 03:10:48PM -0600, Chris Pressey wrote:
> 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.

Except, as I think someone else mentioned, the References are only
ephermal and not persistant across database loads.  For a Roguelike,
that's fine, since about the only truly persistant information is
stuff about the character and his equipment, all else can be regenn'd
at load time.  For a MU* universe, that would hurt.  A lot.

> "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*.

Cool.  Though ... a Roguelike MU* might be intrresting.  I think you'd
need to impliment LoH (Line of Hearing) to really handle folks talking
to one another, and you'd need a specialized client.  Hmmmmm, LoH
could probably be implimented as a sort of flooding algorithm.  Set
the player's site to an Int value, set the neighboring ones to Int-1,
recurse until you can't spread anymore.  Any square with a val > 0 is
in the LoH.  Might be slow, I guess.  Only have to do it once for
every move, though ... as long as you stand still, it doesn't change.

> 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.

I can see that; you don't have to describe a room if you can see it.
On the other hand, you've got more little fiddly bits to manage, along
with a far stronger emphasis on autonomous drone beasties, which'll
just be huge fun.  (If I were implimenting them, I'd probably just
impliment a suite of "sensors" and then have the AI /only/ key off
that knowledge.  You can be a lot more emergent-begaviour-esque that
way.)

> 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.

Well, because its easier to communicate to a human what
"/server/player/soul.erl" actually /is/ than to try and find it in a
swarm of mnesia tables which may not be necessarily nested.  Its
purely a user interface issue, really, though there IS a goodly
measure of "how can I make this easy for people to update remotely"
too.  Its very easy for folks to edit code locally with Their
Favourite Editor(tm) then use ftp to drop it into the right directory.

> 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.

Probably wouldn't parse it as quickly, no, but it could parse it
pretty easily.  I wouldn't use a unique key to access that particular
/file/ again, in my mind it represents just straightforward, inert
sourcecode.  Actual live Things would be running instances of said
code and, as such, would be tagged with Unique IDs (maybe of the kind
Ulffe laid out in the other message), and would need them, because
each would be unique.

> 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 :-)

[grin]  Letting others learn from your mistakes is probably the best
help anyone can provide.  In a sense, you have a somewhat easier time
of making it multiplayer than others.  Just set the cookie on your
node to the same thing every time, and you can transparently tag
another node with a ping, add it to your known nodes, then access it
as if it were right next door.

> 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.

Right, in your case, instances probably /won't/ be any deeper than a
single level, perhaps two, at any given time.  In my case ... I very
well have a tree that looks like this:

  Weapon -> Sword -> \
		      - Magic Sword -> Excalibur -> Excalibur (jnstance)
     Magic Weapon -> /

The actual Excalibur game-object/Thing might be inheriting 3-deep and
possibly with a mix-in (with Magic_Weapon.erl defining an override for
the {attack} message or somesuch).  Of course, all this inheritance
probably takes place at the Erlang module level and not with "real"
inheritance, with Magic_Sword.erl doing an -import of Sword.erl and
Magic_Weapon.erl ...

On the other hand, that brings me to an actual Erlang issue I haven't
quite figured out yet.  One can't specifically import from a specific
file in a specific place in the file hierarchy.  It'd be nice to have
some way to define a "package" as the top of some file directory than
refer to it with an import like: 

  1> top.dir.dir2.dir3:function(args) ...

Unfortunately ... I don't think I can and that's a pretty hefty syntax
hack.

-- 
Alexander Williams (thantos@REDACTED)               | In the End,
  "Blue Jester needs food."                             | Oblivion
  "Blue Jester needs fuku-wearing cuties."              | Always
  http://www.chancel.org                                | Wins