Erlang hints for an OO junkie

[Johan Warlander]

On Wed, 11 Aug 2004 14:44:13 -0700, Chris Pressey wrote
> > The thing is that you can seldomly rely on anything at all to be
> > non-dynamic in a game. However, one thought I had was if perhaps the
> > objects/items as such- even persons and windmills - should be indeed
> > records, and the behaviours themselves be the processes, attaching to
> > the appropriate record.
> 
> This works too.  Each record can have a field for its "animacy", 
> which might be a process or might be absent.  What this appears to 
> be leading towards is modelling everything as partly static, partly dynamic.

Yes, exactly -- that would be one approach at least, and how well it fits for
my purposes? Don't know yet, but hopefully it'll become more apparent after
some experimentation.

> One thing you might want to look at (although you probably already have
> considering where you're coming from with this project) is the Inform
> language and how it handles "daemons" on objects.  Inform is sorely
> limited by the Z-machine; much, much better could be done in Erlang.

Actually, I haven't looked at Inform -- an I probably should, so I'll dig
around a little and see what I come up with.

> When an actor tries to move into a room, a message is sent to the 
> room telling it that the actor wants to come in.  If the room allows 
> this, it sends a return message back to the actor telling them they 
> were allowed in, and both processes update their internal state to 
> reflect the new position of the actor.

Exactly -- and eventually I'll need to address persistency; in this particular
case, I'd want the actor to save it's state as far as what room it's in, but I
wouldn't want the room to save it's state regarding what actors are in it. Oh
well.. getting ahead of myself here, but it's always interesting to get a
better idea of what the 'big picture' is going to look like :)

> When an actor speaks, a message is sent to the room they are 
> currently in.  Each room keeps track of all the actors in it, so it 
> relays each of them the same message.  If the message was "loud",
>  perhaps the room sends it to all adjacent rooms as well.

Yup, and each container might filter the message as it passes through - if
someone's hiding in the closet, some words might come out garbled, and if the
door to the next room is closed, you might need to listen at the door to hear
anything.

> 
> Unlike the find_listeners() function of my previous post, this isn't
> really a recursive solution, which may have some good ramifications for
> performance (a single process isn't blocked doing a traversal; 
> instead, all the processes involved in the traversal share the load.)

That is true. I didn't even consider that, coming from a background of writing
these games in a strongly sequential manner.. Either way I'd have done it in
one of those languages / environments would've resulted in the same 'lag' in
performance :) I can say though, that I'm happy I didn't seriously consider
concurrency before I ran into Erlang, as that would've meant threads, and
they've always looked nasty to me for various reasons highlighted here ;)

> Also, to go back to the subject of OO, it demonstrates a technique
> (delegating) that can be thought of the parallel of inheritance in
> a purely message-oriented system.  Instead of X IS-A Y, you have
> something more like X RELAYS-TO Y.  This is much more flexible, but
> since it's correspondingly easier for it to go haywire too, it's likely
> that it should be used even more conservatively/wisely than inheritance
> should be used in OO systems.

Hmm.. I'm not sure if I see the parallel so clearly, but I might be missing
something - and it does seem a little more dynamic to me, as a recipient
doesn't have to pay attention to the message, or even know about it (as long
as message queues are properly flushed).

Johan