Erlang hints for an OO junkie
Tue Aug 10 06:35:32 CEST 2004
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
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.
More information about the erlang-questions