Erlang hints for an OO junkie

[Johan Warlander]

On Mon, 09 Aug 2004 08:32:27 -0700, Jay Nelson wrote
> I just finished writing an article for the Snowbird ICFP workshop on 
> erlang entitled "Structured Programming Using Processes".  Look for 
> it when the conference comes out or check my website in November.

Will certainly do :)

> The basic premise in the paper is to think of data flows and 
> processes rather than OO.  In OO an object is stored and represented 
> in a single place with all the code that can access the data.  In 
> erlang, messages are sent from process to process so data can be 
> stored in whatever format is best for each process.  You may neeed 
> to keep things in a database, so you can have one table per object 
> type, or coerce all to fit in a single table with some extra 
> columns.  A process could read the currently relevant ones in as a 
> list and dole them out to other processes for manipulation.  User 
> commands can be received, transformed and routed to the process 
> holding the object in question.

I haven't even started looking at database handling etc.. I take it Mnesia
would be the way to go? However, I definitely think I'd go for a table per
object type. Here's where I run into the OO ghost again, though.. Given two
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 

> 
> For your gaming problem you need to decide what must be done 
> concurrently and what must be done sequentially.  Everything else 
> can go either way.  If you have a process for each person or monster 
> (animate entities), internal to the process can be their possessions 
> which they can give to another process in exchange for something 
> else.  The same can happen with traits.

I think I have a vague idea of what you're getting at :) I'm also realising
that it's probably not entirely useful to try to think of things in terms of
what I would've done in an OO language.. 

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.

4) Any entity, not just player characters, should be able to receive
communication messages in the form of talking or acting.. This becomes
important for allowing non-player characters to act on what players do later
on, and also enchanted items might be activated by certain actions or words etc.*

* Not to mention going further with containers, when you want to model in-game
vehicles etc - someone sitting in a wagon pulled by a horse, in a particular
room, would most likely be modeled by the game as being inside a container in
the room, which itself is also a container.

It's pretty much the most basic stuff, and given your hints above, I figure
that each player (person) would be a process. The rooms, however.. a single
resource process of some kind, that would keep track of the game geography and
how to navigate it?

> If you are stuck on objects, make a process for every object.  You 
> will run into some problems, but you may feel comfortable.

Nah, I'm trying to learn something new in the process. Feeling comfortable
isn't my highest priority ;)

Johan