Erlang hints for an OO junkie

[Johan Warlander]

On Tue, 10 Aug 2004 13:45:30 -0700, Chris Pressey wrote
> My two cents:
> 
> If it's "animate", if it has "dynamic behaviour", if it "moves" - model
> it as a process.  If it isn't/hasn't/doesn't - model it as a record (or
> a dictionary.)
> 
> So: people, motorcycles, windmills, radios, thunderstorms, etc are
> processes.  Sandwiches, taverns, tables, mountains, etc are records.

Okay, here's the catch - it's certainly as you say above, that the first set
of objects have dynamic behaviour, while the second set ordinarily do not..
however, these things are not so static. A dead person doesn't move, while an
enchanted sandwich might very well fly around flapping its lettuce, and for a
more down-to-earth example, if you leave the sandwich on the table for a week
or two it'll definitely gain some dynamic behaviour.

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.

For example, a player logging in would cause his in-game body to be loaded and
instantiated in the game as a record, but his connection to the game (that
which allows him to issue commands to be parsed and executed) would be a
process, attached to the body. Similarly, if someone casts an enchantment on a
sandwich (for whatever devilish purposes), that enchantment would be the
process, and it would attach to the sandwich.

I don't know if this would solve all of these issues (or indeed any of them),
but it seems to me like one possible way.
 
> That said, you could very well model everything as processes, and 
> have messages propogate from people to rooms back to people, and 
> such.  This may be a more elegant way to address the problem in some 
> ways, but in my mind it's not sufficiently more elegant to warrant 
> doing it.  You can have a *lot* of processes in Erlang, but even so, 
> the more conservative you are with them, the more efficient the 
> result.  If you model everything as a process you might be able to 
> have 50K rooms, 50K items, 50K animals and 50K players; but if you 
> only model "animate" things as processes you'll be able to have 100K 
> animals, 100K players, and who knows how many rooms and items :)

Well, either way would work for me as I'm not aiming to build a massively
multi-player game; rather, my intended audience if this ever turns into a
playable game would be somewhere around 40-150 people I think.. with the
possibility of handing a few hundred, but absolutely not numbers in the
thousands. The game world as well will probably not ever grow too far beyond a
few thousand rooms, as I'd rather have 500 great rooms than 5000 average ones.

In short, performance -shouldn't- turn out to be the deciding factor.. I'd be
more inclined to value simplicity / beauty of implementation (whatever this
turns out to mean in Erlang), since those factors tend to add a lot to the
maintainability of code.

> Whichever way you choose to go, good luck!

Thanks!

Johan