Erlang hints for an OO junkie
Wed Aug 11 09:30:54 CEST 2004
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!
More information about the erlang-questions