Erlang hints for an OO junkie

[Johan Warlander]

On Mon, 09 Aug 2004 21:35:32 -0700, Jay Nelson wrote
> Avoid inheritance if you can.  Why do you think you need it?

Hmm.. I'm trying to figure that out myself. I think I'll just go ahead as
below, and see what happens -- if I still think I need inheritance for some
particular issue, I'll try to have someone convince me there's a better way to
solve my concern ;)

> Re: containers -- processes are one of the best containers 
> available.  They have a unique name, can be found by the operating 
> system or vm so you don't need to write access code, they contain 
> only those things passed as arguments in the server loop and they 
> send things to another container (process).  Writing the paper 
> helped me discover that this is probably the most important aspect 
> of a process, providing an isolatable container of computation --
>  the second being that it serializes all requests, so it is very 
> good at maintaining a particular state.  That is why FSMs are so 
> sweet in erlang.  I find concurrency useful, but one of the less 
> important characteristics of processes.
> 
> >Either way, would you be able to give me some pointers on where to start
> >implementing a simple scenario like the one below, in a process-oriented way?
> >
> >1) The world consists of simple rooms with a textual description, linked
> >together in the four cardinal directions.
> >
> >2) Players can walk around between these rooms, and will see the room
> >descriptions as well as other players in the same room. 
> >
> >3) Players can communicate with others in the same room by talking.
> >  
> >
> At this point you have a choice as to processes: people or rooms.  
> Everyone says make the concurrent or animate things processes, so 
> the obvious choice is people, right?  Well... rooms are linked more 
> or less permanently in a certain fashion, people aren't.  How would 
> you connect people, and for how long?  People talk to each other but 
> does that cause them to change state?  Maybe, but not usually.  But 
> people carry weapons and other objects and give them to others.  In 
> that sense they are containers of things, and they also happen to be 
> containers of attributes and characteristics and skills.
> 
> Rooms are fundamentally really good containers.  Things move in and 
> out of them; objects can be rearranged inside them.  Moving in or 
> out, or picking up or leaving something changes the state of the 
> room as well as the person.  But the primary mechanism of the game 
> is for people to move from room to room.  I would start with a 
> geographic map of rooms, and create a single process per room with 
> interconnections only between adjacent rooms.  The people and 
> objects in the room would be maintained in some sort of tree or list 
> and passed as the state variable of the room.  A message to enter or 
> leave would cause a person to be added to or removed from the state, 
> with a confirmation for entering or a removal from the list for 
> leaving (after sending an enter to the destination room process).
> 
>  People could be records or processes.  Processes would let you send 
> messages like pick up object, set down object, etc.  Either way the 
> people themselves could be sent as a message from one room to another.
> 
> Start with this and forget the rest of the game.  See how far it 
> takes you, and what code looks like for moving around.  I would just 
> start with rooms and people moving from room to room and seeing who 
> else is present.  If you make a room a process, with a list of 
> people processes in it as the state variable of a looping server, I 
> think you'll find the code is trivial (hint: look at the package 
> lists for things like member).  Once you can do that, then grapple 
> with what it means for one person to talk to another.  It will be 
> the fundamental problem of your entire program.  If you are hung up 
> on having the program model the real world accurately, you will 
> never solve the problem of people talking to one another.  The rest 
> should be straight forward.

Okay, I'm starting to look at this in a completely different way than when I
set out to do this.. Thanks! I'll play around with the ideas you've given me
and see what it comes to. As you say, just starting out with rooms, people and
communication will probably help me understand and evolve a model for how to
do this, without getting too complex too fast.

On a sidenote, while I know I probably shouldn't be thinking about this quite
yet, where would I start running into performance problems as far as
concurrent processes go? 
Looking forward (pretty far), there'd probably be a stage at which I'd have a
few thousand rooms (1k - 5k perhaps), a similar amount of computer-generated
creatures with highly varying degrees of complexity in their behaviour
patterns, 20-70 concurrent players (pretty few, but probably resource
intensive) and several processes to govern things like weather, time of day,
etc. All in all, perhaps upwards of 10 000 processes.. where most of them,
admittedly, would have very low resource utilisation. Of course, strictly
speaking inanimate items might also end up being modeled as processes.. and if
so that number could rise to 15 000 in the above scenario.


Thanks for all your help so far :)

Johan