Erlang hints for an OO junkie
Thu Aug 12 06:34:09 CEST 2004
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
> 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
> 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).
More information about the erlang-questions