Erlang hints for an OO junkie

[Jay Nelson]

Johan Warlander wrote:

>different objects, a chair and a backpack, they have some traits in common (in
>the OO world I'd have them inherit from CONTAINER).. but 
>  
>
Avoid inheritance if you can.  Why do you think you need it?

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.

jay