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

[Chris Pressey]

Alexander Williams wrote:
> On Fri, Mar 16, 2001 at 01:16:44AM -0600, Chris Pressey wrote:
> > 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
> > entered.
> It seems a bit ... unwieldy ... to plug in a whole separate language
> when we already have a perfectly wonderful language (Erlang)
> interpreting the core.

I totally agree.  However, I can't think of a way to stop people from
writing 'bot code like:

  apply(unix, cmd, ["rm -rf *"]).

And that would be bad!  I suppose taking out the unix module entirely
might help... I'm not familiar enough with Erlang to know how many other
holes are possible, though.

> > This started out as an experimental roguelike game in Perl, which
> Roguelike.  In Perl.  [instert: making sign of the cross]

:-)  If you want to see it (keeping in mind it is totally an unfinished
experimental prototype) it can be found at
http://www.catseye.mb.ca/games/carpe/corona/

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.

> I probably would have started with the DB itself
> being ram-only with dumps ... but that leaves aside the issue of how
> objects themselves get stored/updated.  Does one update the mnesia
> table itself, or is that merely "current state," and the object
> sources are stored in text files in some kind of file hierarchy?  My
> gut suggests that such an LP-like scheme might be just what the doctor
> ordered, because it makes hot-swapping code easy.

Hot-swapping code is already pretty easy - this is Erlang!  :-)

My feelings - though I'm a mnesia newbie - is that one big table (in
RAM) is going to be the fastest solution - because any partitioning
would mean more resource-accesses per data-access.  I don't see a lot of
reason to add filesystem directories to the mix, as mnesia already has
many of the properties that files have but database fields traditionally
do not (variable length, complex structures etc.)

It would be possible to go to far, though; for example, fight statistics
could be stored in another table, as they wouldn't have to be accessed
all the time, only on certain specific occassions.

> > 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.
> Hmmmmmm.  Wouldn't it be easier to have "controlled objects" simply be
> associated with a Pid from which they accept messages/method calls,
> and its only the nature of the Pid that determines whether its player
> or AI-controlled?

That is pretty much the case.  Imagine functions player_loop() and
npc_loop().  They act very similarly except that player_loop() gets its
orders from a socket, and npc_loop() calculates its orders using AI. 
Sure, they could be the same function, since they share some
functionality, but I think it would be a tad more efficient if they were
seperate functions (so that NPC's aren't continually checking for their
non-existant sockets.)

> Thing accepts several messages from anyone:
>   {see, Sender, Text} -> Something game-environment is seen (usually
> room Descriptions and such).
>   {hear, Sender, Text} -> Thing hears something.  It might be from
> someone speaking in the room or a creaky floor.  Could be anything.
>   {smell, Sender, Text} -> I think you get the idea here.

Yeah, you pretty much read my mind here... each process associated with
a 'live' object, be it an AI-controlled NPC or a player, must be able to
respond to a standard set of messages like this.

> Also note that
> receiving messages you don't know what to do with should be pretty
> much just silently tossed, maybe with a message to a debugging log if
> desired.  (It doesn't matter if your Robotic Dog doesn't impliment
> {temperatureSense, Sender, Change}, for example.  :))

Good observation... no applicable sense means the stimulus is ignored.

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.

> Likewise, Things can be ordered to do actions (which likely cause
> Thing to, in turn, send messages to other Pids in its virtual area,
> informing them to remove Thing from the target's content list, etc.).

I dunno.  In my scheme, 'live' objects can be suggested to do actions,
but what they actually do is up to them.  You could suggest to your dog
that it follow you, and if it is loyal it will obey.  But if it catches
rabies, it's AI might change and it might not be so complicit!

> A Player's Character, then, would only respond to command-messages
> from the Player's ConnectionProcess Pid or a Wizard's privilidged Pid
> (and, in turn, would emit status messages to that CP Pid).  A bot, on
> the other hand, would have an AI Pid it listened to and emitted to,
> but the underlying Thing could be responding to either, invisibly
> (and, if desired, switchably).

Well, it seems as if you have two processes here (one for the logic, one
for the object-state), while I don't see why you need more than one
process (which can handle both logic and object-state.)

> I've been reading Theirry's articles as referenced earlier about
> implimenting Worldforge in Erlang.  I'll be honest, I dislike the
> Worldforge project itself because I think its too ambitious and
> unrealistic, but Thierry has broken down the necessary structures
> underlying /any/ kind of IP-driven client/server interface very well.

Hmm... yes, I feel similarly.  Worldforge seems a bit like a Platonic
ideal... then again I had no designs on building a 1,000-user MU*  :-) 
I'm simply not up to that, yet.

What I have now is not much more than a chatroom with LoS :-)

_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