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

[Alexander Williams]

On Sat, Mar 17, 2001 at 06:25:13PM -0600, Chris Pressey wrote:
> 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.

Makes perfect sense, though if you're going to bring beasties back
after a game save, you still have to find a unique tag to associate
between a Pid and a DatabaseEntry.  Mmm, though I suppose in your
case, rebuilding straight from the DB would be acceptible.  The
initialization/restore code would simply walk the DB in some order,
and create a controlling Pid for this run, set it up from the data in
the DatabaseEntry, and run with it.  

That's probably not a bad idea for coming back up with a MU* server,
in the majority of cases.  I wonder about Things which are dependent
on other Things being up to work, but ... I suppose if all names are
resolved through a NameServer Pid, and you make sure it comes up
reasonably first/early, then it can just make things wait until their
targets wake up.

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

MUSE evolved into the MUSH/MUX servers of today.  The "register"
concept got expanded to arbitrarily-named and -lengthed (up to
4k), and are, additionally, able to hold either code or data (mainly
because code is just text ... and MUSH/MUX language is very simple
scripting, though you can impliment complex things in it if you don't
mind the bleeding from the eyes).  All in all, its a very nice,
simple, straight-forward system overall ... but I really wish I had a
more powerful programming language embedded.  :)

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

As long as processes can be marshalled and restarted, its golden
gravy.  I sometimes long for facilities like the old LispM's had of
just freezing the whole memory-state to disk for resumption at a late
time.  That kind of facility would be perfect.  :)

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

UO doesn't really count; it is pretty much a 3d MUD with pretty flash
graphics (like EverCrack).  I really /hate/ those interfaces, btw; its
impossible to gauge distances without binocular vision, actually
targeting things is nearly impossible to do while standing still, much
less moving, and let's not even get into the ballance issues.  Oi vey!

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

Depends on how you impliment the VT100 controls; with enough
abstraction, it can be ... tolerable.  Still, probably nowhere NEARLY
as useful as a custom client written in Erlang using Erlang-based GUI
tools.  Despite all the complaints regarding them, they /do/ work.

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

Might be hard to precompute all the areas sound could flow to
... you'd have to run flow for every point on the map, which could be
several hundred (at a minimum) sites.  Hmmmm, for precomputing LoS,
you might as well just precompute for each door state ... but that
gets nuts quickly if you can't break regions down cleanly by "this
area will never be affected if that door changes state."

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

Oh, I've done it in other languages.  Its a bit ... ugly ... but it
can be done.  The trick is replacing for a time the usual command
editor with another specialized for editing, then switching it back.

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

If you're worried about cheating, you might as well just not write a
game these days, if it involves ANY code in any form running on a
client.  Even telnet is susceptible to folks running front-ends which
do macro moves, etc.  Web-based games get daemon-flooded by bots which
play faster with simple logic than any human hopes to.  And so on.
Cheaters always find a way.  If they have to learn Erlang (and BEAM,
if you distribute it pre-compiled) to do it, I consider that a net
win.  :)

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