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

[Chris Pressey]

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

True.  Drat!  Only unique within the group of nodes in the current
'session'.  If you shut everything down and restart, that restarts the
reference counter too.  Ulf's external-id function would probably be
better in a scenario with both distribution and persistence.

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

Most of it, yes.  In my model, state for each object - if any - is
stored in its database record.  Every so often, the process uses that
state information to decide what to do, and updates the state in the
record if needed.  And many creatures don't have very complex lives, so
they need little or no stored state.  If the state information
disappears, the creature will eventually find something else interesting
to do, so there's not much to be lost either.

> For a MU* universe, that would hurt.  A lot.

I have to admit I haven't programmed in an actual MU* for years.  I was
heavily into one called MicroMUSE but that was a long time ago, seven
years probably.  I seem to remember its objects had registers 'A'
through 'Z', and that was pretty much all they had for state information
- not including things like the gender of the object or it's position,
which are less general-purpose forms of "state".

In a MU* setup it is indeed more important that the internal state be
saved, but I was using that as the reason to think about how to get all
that state into a (e.g.) database record, instead of thinking about
keeping the state in the process's local variables, and somehow freezing
arbitrary processes to portable representation on disk (which sounds
very complicated.)

> > "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'm certainly no expert, but I believe MAngband and Ultima Online are
probably the two most popular examples of the genre.  UO costs money and
MAngband has licensing problems, though.

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

Definately a specialized client, probably in Perl.  Without one, you
need a great deal of patience and imagination.  :-)  I considered just
sending cursor control sequences down the socket connection (i.e.
telnet) but that requires VT100 emulation, of course, and isn't very
abstract.  Possibly an option for users who don't want to use
specialized client software, though.

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

The flood algorithm is just about right to approximate acoustics, but it
is fairly slow.  It might be good to precompute it and cache it.  It
would be easier to do this with hearing than sight, as it changes less
as things move around.  In fact, if creatures don't block line-of-sight,
maybe that could be precomputed too, changing only when the scenery
(walls &c) change.  Doors that open and close frequently still present
problems though.

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

Ah, OK.  I also misunderstood the problem a bit.  I'm not proposing that
actual Erlang source code in text form be stored in a mnesia database. 
While I'm sure it's possible, I'm not sure it's recommended.  What I'm
mainly considering is storing *funs* in the database.  It also makes
sense to be able to index that fun to its source code somewhere; much
more important in a MUSE where everyone's a "programmer".

The FTP thing in and of itself is a good reason to use the filesystem to
accomodate multiple users using tools they already have.  Trying to
incorporate an on-line code editor would be complex and probably a bit
futile.

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

That's so easy it's almost criminal.  I wasn't considering clients
written in Erlang too, but with that I suppose I could bypass sockets
almost completely... and with SAE the client could still be pretty
small..

But, I considered the peer-to-peer model for multiplayer games, and I
concluded hacked peers open up too much of a loophole for cheating,
leading me to stick to a pretty strict client-server model.

But the using-Erlang-nodes-as-peers thing might work in other multi-user
contexts, like peer-to-peer file-sharing... not that the world needs
another peer-to-peer file-sharing protocol, mind you ;-)

_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