| Author |
Message |
< Erlang questions mailing list ~ Fun with Erlang (was Stand Alone Erlang for Windows. yet ag |
| cpressey at catseye.mb.ca |
 Posted: Thu Mar 15, 2001 7:57 pm |
 |
|
|
Guest
|
James Hague wrote:
> I use a variety of scripting languages at home and work. Mostly I've used
> Perl at work, but I actually used Erlang to prototype an algorithm used in a
> commercial PlayStation 2 game, no joke! (See http://www.summoner.com if you
> want to see the game.)
OK, this looks like a good place for a segueway :-)
I've noticed that one thing many Perl advocates tend to fall back on
when defending their language of choice is that it is "fun." I don't,
for the record, see "entertainment value" as a very important metric of
a language, at least not one in which you wish to get some important
work done. (For a toy language explicitly designed to be fun, it's
another story.)
But to me, Erlang is at least twice as fun as Perl, but I'm certain I
have a different sense of fun than most Perl programmers - witnessing
games like Perl Golf, I think the Perl definition of fun is closer to
"language abuse." That sort of fun almost isn't possible in Erlang,
which is the way I like it.
But I do want to dispell the myth that because Erlang can do serious
work, it can't also be used for fun - maybe in slightly different ways
than Perl but that's OK.
So I'm thinking about putting together a 'Fun with Erlang' web page to
point to fun things people are doing with Erlang. Games written in
Erlang like Othello, Minesweeper, and Board would be listed, but so
would projects like this PS2 game (if that's all right with you, James).
So my question to the list is if anyone knows of any other games or
loosely fun-related projects in Erlang.
I'm working on a game myself; it's sort of an MUD/MUSE/IF/roguelike
thing, so I'd be especially interested in hearing about any online games
or other fun stuff that's been attempted in Erlang.
Thanks!
_chris
--
"Ten short days ago all I could look forward to was a dead-end job as a
engineer. Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| etxuwig at etxb.ericsson. |
| Posted: Thu Mar 15, 2001 8:09 pm |
|
|
|
Guest
|
On Thu, 15 Mar 2001, Chris Pressey wrote:
>So my question to the list is if anyone knows of any other games or
>loosely fun-related projects in Erlang.
I don't know -- would the AXD 301 ATM switch count?
I've had great fun here. (:
/Uffe
--
Ulf Wiger tfn: +46 8 719 81 95
Senior System Architect mob: +46 70 519 81 95
Strategic Product & System Management ATM Multiservice Networks
Data Backbone & Optical Services Division Ericsson Telecom AB
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| thantos at telocity.com |
| Posted: Thu Mar 15, 2001 10:47 pm |
|
|
|
Guest
|
On Thu, Mar 15, 2001 at 01:46:30PM -0600, Chris Pressey wrote:
> I'm working on a game myself; it's sort of an MUD/MUSE/IF/roguelike
> thing, so I'd be especially interested in hearing about any online games
> or other fun stuff that's been attempted in Erlang.
Ooooh, now, this is fun: I was just thinking about Erlang-based MU*
the other night (and, naturally, that led to my thoughts about Binary
Strings vs List Strings; parsing eats up time in MU* design).
Theoretically, a MU* implimented in Erlang could have easily
distributable/extensible distributed databases; one could literally
walk off the edge of one MU* and onto another hosted on another site
and hardly know the difference ... except for any local player-mods
that might have been made. Strolling from a systemless SocialEM
(Erlang MU*) onto a World of Darkness EM wouldn't necessarily give you
stats and structure (though the WoD could be coded to stat you as Joe
Average; capturing migrating processes would be nicely necessary).
The main question that it occured to me to ask would be "How is the
best way to allow programming/extending the live system?" The
facility for live upgrade of Erlang code gives us a direct hook into
fixing things, but one has to impliment security on top of that. Do
we go with the LP-like model with directories of files which are then
instanced into existance, or something more MUX-like with instances
being live at all times but possibly inherited from?
Options, options.
--
Alexander Williams (thantos_at_telocity.com) | In the End,
"Blue Jester needs food." | Oblivion
"Blue Jester needs fuku-wearing cuties." | Always
http://www.chancel.org | Wins
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| mickael.remond at erlang- |
| Posted: Fri Mar 16, 2001 6:14 am |
|
|
|
Guest
|
Chris Pressey (cpressey_at_catseye.mb.ca) wrote:
>
> I'm working on a game myself; it's sort of an MUD/MUSE/IF/roguelike
> thing, so I'd be especially interested in hearing about any online
> games
> or other fun stuff that's been attempted in Erlang.
I was thinking about a MUD myself since several years.
Then I meet Thierry Mallard. He told me about an interesting game
project called "Worldforge".
I convinced him to look at Erlang and he convinced me to have a look at
Worldforge. Now we both think that such an online, massively
multiplayer game could be done in Erlang and are exploring such a
direction.
Thierry Mallard wrote two articles on this topic, and several others are
being written. If you need more information, you should have a look at
the English Area of the French Erlang-fr site:
http://www.erlang-fr.org/en-area/index.html
Comments are welcome.
--
Micka |
|
|
| Back to top |
|
| cpressey at catseye.mb.ca |
| Posted: Fri Mar 16, 2001 7:26 am |
|
|
|
Guest
|
Alexander Williams wrote:
> On Thu, Mar 15, 2001 at 01:46:30PM -0600, Chris Pressey wrote:
> > I'm working on a game myself; it's sort of an MUD/MUSE/IF/roguelike
> > thing, so I'd be especially interested in hearing about any online games
> > or other fun stuff that's been attempted in Erlang.
> Ooooh, now, this is fun: I was just thinking about Erlang-based MU*
> the other night (and, naturally, that led to my thoughts about Binary
> Strings vs List Strings; parsing eats up time in MU* design).
Indeed... I'm sticking to binaries and atoms whereever possible.
> Theoretically, a MU* implimented in Erlang could have easily
> distributable/extensible distributed databases; one could literally
> walk off the edge of one MU* and onto another hosted on another site
> and hardly know the difference ... except for any local player-mods
> that might have been made. Strolling from a systemless SocialEM
> (Erlang MU*) onto a World of Darkness EM wouldn't necessarily give you
> stats and structure (though the WoD could be coded to stat you as Joe
> Average; capturing migrating processes would be nicely necessary).
Although I had no such lofty plans to start out with, these were some of
the strengths for why I picked Erlang to do this in. Servers should be
able to treat each other as peers and refer clients to each other, and
distributed programming should make that easy, almost trivial.
> The main question that it occured to me to ask would be "How is the
> best way to allow programming/extending the live system?" The
> facility for live upgrade of Erlang code gives us a direct hook into
> fixing things, but one has to impliment security on top of that.
Indeed, I thought about that a bit too. A mechanism like Perl's
taint-checking would be nice. Failing that, probably a little
object-manipulation language which is compiled into safe Erlang when
entered.
> Do
> we go with the LP-like model with directories of files which are then
> instanced into existance, or something more MUX-like with instances
> being live at all times but possibly inherited from?
This just being an experiment for me, I'm not really following any
particular model with much fidelity.
This started out as an experimental roguelike game in Perl, which
quickly got too complex to be easily maintainable. I started
translating it to Erlang, but found I had a much easier time just
rewriting most of it.
All objects in my game are records in a monolithic mnesia table (which
is currently ram-and-disc, I will probably change that to ram-only with
periodic dumps in the future, for speed.)
There is a field 'pid' in the record definition. Objects with 'agency'
have a pid associated with them. Such objects can be NPC's (internal
bots), in which case the process is responsible for their AI. Or they
can be human players or external bots, in which case there's a valid
value in the 'socket' field too. So the difference between 'live' and
'inert' objects is merely that of an attached process.
I'm using a sort of 'object factory' approach where there are no
classes; instead, 'exemplars' which are copied and tweaked. Exemplars
describe distributions for stats (e.g. strength = 3d6) while instances
have concrete values (e.g. strength = 15.)
_chris
--
"Ten short days ago all I could look forward to was a dead-end job as a
engineer. Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| thantos at telocity.com |
| Posted: Fri Mar 16, 2001 8:55 am |
|
|
|
Guest
|
On Fri, Mar 16, 2001 at 01:16:44AM -0600, Chris Pressey wrote:
> Indeed, I thought about that a bit too. A mechanism like Perl's
> taint-checking would be nice. Failing that, probably a little
> object-manipulation language which is compiled into safe Erlang when
> entered.
It seems a bit ... unwieldy ... to plug in a whole separate language
when we already have a perfectly wonderful language (Erlang)
interpreting the core. I'd probably, given my druthers, throw away
the idea of "representations as objects" for the more-Erlang'y
"representations as processes," since Erlang lets us have extremely
lightweight processes so easily. More, I suspect, below. :)
> This started out as an experimental roguelike game in Perl, which
Roguelike. In Perl. [instert: making sign of the cross]
> All objects in my game are records in a monolithic mnesia table (which
> is currently ram-and-disc, I will probably change that to ram-only with
> periodic dumps in the future, for speed.)
Yeeow. That's scary-big, I must say. (Of course, much of my internal
sense of MU* scale has been shaped by sites like LambdaMOO and
FurryMUCK, both on the edge of outside size. Once you hit several
hundred to a thousand users on simul a night, even throwing text
around gets messy.) I probably would have started with the DB itself
being ram-only with dumps ... but that leaves aside the issue of how
objects themselves get stored/updated. Does one update the mnesia
table itself, or is that merely "current state," and the object
sources are stored in text files in some kind of file hierarchy? My
gut suggests that such an LP-like scheme might be just what the doctor
ordered, because it makes hot-swapping code easy.
> There is a field 'pid' in the record definition. Objects with 'agency'
> have a pid associated with them. Such objects can be NPC's (internal
> bots), in which case the process is responsible for their AI. Or they
> can be human players or external bots, in which case there's a valid
> value in the 'socket' field too. So the difference between 'live' and
> 'inert' objects is merely that of an attached process.
Hmmmmmm. Wouldn't it be easier to have "controlled objects" simply be
associated with a Pid from which they accept messages/method calls,
and its only the nature of the Pid that determines whether its player
or AI-controlled? A Player Pid would involve a poll for outside input
before it sent messages to the Thing, whereas an AI would be just
sending them based on perceptions (as relayed back by the Thing) and
coded responses.
Exempli gratia (a Thing based on an Erlang Process, because its an
Erlang ML  ):
Thing is considered to be the Pid of the "Thing" process here.
Thing accepts several messages from anyone:
{see, Sender, Text} -> Something game-environment is seen (usually
room Descriptions and such).
{hear, Sender, Text} -> Thing hears something. It might be from
someone speaking in the room or a creaky floor. Could be anything.
{smell, Sender, Text} -> I think you get the idea here.
You wouldn't necessarily need to have a message for each sense
(in fact, most MU* systems don't even provide the facility to do so,
Things can only {hear, Sender, Text}). Pretty much everyone counts on
Sender being useful, for various reasons, so message-sending is
typically only done through protected functions. Also note that
receiving messages you don't know what to do with should be pretty
much just silently tossed, maybe with a message to a debugging log if
desired. (It doesn't matter if your Robotic Dog doesn't impliment
{temperatureSense, Sender, Change}, for example. )
Likewise, Things can be ordered to do actions (which likely cause
Thing to, in turn, send messages to other Pids in its virtual area,
informing them to remove Thing from the target's content list, etc.).
Command-messages are only accepted from an appropriate Sender (defined
when the Thing is created and probably updatable). If its not from
Sender, toss it.
Useful command-messages might include:
{move, Sender, Direction}
{say, Sender, Text}
{odour, Sender, Text}
{reloadCode, Sender}
The last one lets you update the beasty on the fly without requiring
you to do a module:loop call every time through, making it slightly
more efficient and controllable.
A Player's Character, then, would only respond to command-messages
from the Player's ConnectionProcess Pid or a Wizard's privilidged Pid
(and, in turn, would emit status messages to that CP Pid). A bot, on
the other hand, would have an AI Pid it listened to and emitted to,
but the underlying Thing could be responding to either, invisibly
(and, if desired, switchably).
(Forgive me if this seems scattered, I'm writing this
extemporaneously. )
> I'm using a sort of 'object factory' approach where there are no
> classes; instead, 'exemplars' which are copied and tweaked. Exemplars
> describe distributions for stats (e.g. strength = 3d6) while instances
> have concrete values (e.g. strength = 15.)
Hmmmmm, so you're mimicing a very MUSH/MUX-like system for that.
Though you might want to allow for multiple Exemplars for any given
Instance and arbitrarily deep chains of Exemplars, to allow for more
flexible behaviour. (Ie. an Exemplar that soley contains the
statistic system and an Exemplar that contains the physical commands
for, say, a certain class of monster, as opposed to another; they
share stats and methods to access stats in common but the Basilisk may
change anything in its LoS to stone while the Cockatrice requires
touching, or something like that.)
I've been reading Theirry's articles as referenced earlier about
implimenting Worldforge in Erlang. I'll be honest, I dislike the
Worldforge project itself because I think its too ambitious and
unrealistic, but Thierry has broken down the necessary structures
underlying /any/ kind of IP-driven client/server interface very well.
These bits of code could very well form the core of a good MU* server
(and likely give far better performance than we have seen in the past
for MU* servers; soft-realtime is good).
--
Alexander Williams (thantos_at_telocity.com) | In the End,
"Blue Jester needs food." | Oblivion
"Blue Jester needs fuku-wearing cuties." | Always
http://www.chancel.org | Wins
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| mickael.remond at erlang- |
| Posted: Fri Mar 16, 2001 11:25 am |
|
|
|
Guest
|
>
> Hmmmmmm. Wouldn't it be easier to have "controlled objects" simply be
> associated with a Pid from which they accept messages/method calls,
> and its only the nature of the Pid that determines whether its player
> or AI-controlled? A Player Pid would involve a poll for outside input
> before it sent messages to the Thing, whereas an AI would be just
> sending them based on perceptions (as relayed back by the Thing) and
> coded responses.
[snip...]
I have read your whole message and I must admit that the "picture" you
are proposing is very exciting.
We will place it on the Erlang-fr page and translate it in French, if
you do not mind.
> I've been reading Theirry's articles as referenced earlier about
> implimenting Worldforge in Erlang. I'll be honest, I dislike the
> Worldforge project itself because I think its too ambitious and
> unrealistic, but Thierry has broken down the necessary structures
> underlying /any/ kind of IP-driven client/server interface very well.
> These bits of code could very well form the core of a good MU* server
> (and likely give far better performance than we have seen in the past
> for MU* servers; soft-realtime is good).
>
I agree with you on Worldforge ambition, that is why I was first
interested in a MUD like approach, which is much more established.
But Thierry Mallard convinced me to have a look at Worldforge. We then
come to think that an Erlang approach could make this project feasible.
We are both very pragmatic and are interested in first having some code
working and then improving it.
Your reflexion on the game design by process is very insteresting.
Maybe we could start working together on a real working and playable
implementation ?
--
Micka |
|
|
| Back to top |
|
| thantos at telocity.com |
| Posted: Fri Mar 16, 2001 1:01 pm |
|
|
|
Guest
|
On Fri, Mar 16, 2001 at 12:25:03PM +0100, Mickael Remond wrote:
> I have read your whole message and I must admit that the "picture" you
> are proposing is very exciting.
> We will place it on the Erlang-fr page and translate it in French, if
> you do not mind.
By all means, people from all countries should be exposed to the
horror of my ideas and imaginings. :)
> I agree with you on Worldforge ambition, that is why I was first
> interested in a MUD like approach, which is much more established.
> But Thierry Mallard convinced me to have a look at Worldforge. We then
> come to think that an Erlang approach could make this project feasible.
> We are both very pragmatic and are interested in first having some code
> working and then improving it.
I'd love to see the basic core systems implimented in Erlang and
supporting some kind of "MU*-like text-based VR" before I buy into the
Worldforge plan; I've been following it for a while (as a good
MU*-geek should) and, while they have some good single-scenario
systems, I don't think they have the genericity to provide the kind of
experience I look for online (not the least reason being that anyone
can spell "cow" but I'll be damned if I can draw one).
If any approach COULD improve the feasibility, its likely Erlang.
> Your reflexion on the game design by process is very insteresting.
> Maybe we could start working together on a real working and playable
> implementation ?
Years of actually thinking about and beating on the problem. I'm
probably one of the few folks who've both worked on Coda (a
Scheme-based MU* core) and POO (a Python-based system). I'd certainly
be interested in helping out wherever I can, even if its purely on
design and structure. (One of the main problems I see in such
projects most of the time is everyone wants to get in there and beat
code without thinking of overall design first; I do not suffer that
problem. Probably because I find design more fun than
implimentation. )
--
Alexander Williams (thantos_at_telocity.com) | In the End,
"Blue Jester needs food." | Oblivion
"Blue Jester needs fuku-wearing cuties." | Always
http://www.chancel.org | Wins
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| mickael.remond at erlang- |
| Posted: Fri Mar 16, 2001 1:45 pm |
|
|
|
Guest
|
Alexander Williams (thantos_at_telocity.com) wrote:
>
> Years of actually thinking about and beating on the problem. I'm
> probably one of the few folks who've both worked on Coda (a
> Scheme-based MU* core) and POO (a Python-based system). I'd certainly
> be interested in helping out wherever I can, even if its purely on
> design and structure. (One of the main problems I see in such
> projects most of the time is everyone wants to get in there and beat
> code without thinking of overall design first; I do not suffer that
> problem. Probably because I find design more fun than
> implimentation. )
Hey ? You've worked on Poo ?
This is precisely the Mud that I enjoyed reading and that gave me the
idea to write an Erlang Mud.
I really like the Poo implementation. I found it brilliant. The code is
extremely compact. Beautiful.
I am very eager to implement such a tool in Erlang, using process
oriented design...
--
Micka |
|
|
| Back to top |
|
| thantos at telocity.com |
| Posted: Fri Mar 16, 2001 2:20 pm |
|
|
|
Guest
|
On Fri, Mar 16, 2001 at 02:44:44PM +0100, Mickael Remond wrote:
> Hey ? You've worked on Poo ?
> This is precisely the Mud that I enjoyed reading and that gave me the
> idea to write an Erlang Mud.
> I really like the Poo implementation. I found it brilliant. The code is
> extremely compact. Beautiful.
I hacked on it a bit. Ultimately, I found it personally
unsatisfactory, in part because of the way the database itself is
managed in POO. Marshalling objects to the store is a great idea in
principle, but the ability to turn around and say "dump this whole
thing to ASCII" never materialized, and doing online inline
modifications of the core server objects was not only possible, but
necessary ... but once committed, never came out again in a way that
let you examine the server as a whole.
One of the things I WOULD like to steal openhandedly from POO is the
way in which objects can be referenced not only be a unique ID (which
we get for free in Erlang), but the way objects could be referenced in
Directory container objects; the "$MajorThing.MinorThing.TargetThing"
concept was a brilliant insight. It makes accessing a live-object in
a known environment trivial. Coupling this with an LP-like file-based
object source store would be an excellent move, I think. Updating
objects, then, wouldn't necessarily involve touching them directly
unless its to set the Thing's local environment. Modifying code would
involve editing the file, compiling it, then sending a
"{reloadSource}" message to the poor beleagured thing. Much safer, in
the long run, because no object behaviour is changed until the source
is at least lexically correct.
> I am very eager to implement such a tool in Erlang, using process
> oriented design...
I think it can be done. One thing I wonder about, however, is whether
a running process can be marshalled out to disk and reloaded. If so,
we're golden. If not ... well, then we get into questions about how
to manage state persistantly. Its far easier to say "dump all child
processes of this Pid to disk" than to say "OK, walk this list of Pids
and query them for state," especially when you go to reload.
--
Alexander Williams (thantos_at_telocity.com) | In the End,
"Blue Jester needs food." | Oblivion
"Blue Jester needs fuku-wearing cuties." | Always
http://www.chancel.org | Wins
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| etxuwig at etxb.ericsson. |
| Posted: Fri Mar 16, 2001 2:30 pm |
|
|
|
Guest
|
On Fri, 16 Mar 2001, Alexander Williams wrote:
>I think it can be done. One thing I wonder about, however, is whether
>a running process can be marshalled out to disk and reloaded. If so,
>we're golden.
This can be done, as long as one doesn't make any assumptions about
Pid (it will change), and there's a stable state in which to do this.
Take a look at the dispatcher contrib. It packs processes into ETS,
re-activating them if something happens. This is done on top of
the existing Erlang, and is similar to a mechanism used in
AXD301 for handling connection setups (the problem there is that we
can't have one process per connection, as there are too many
connections.)
One could make it more general still by extracting the process
dictionary before killing the process instance.
You still need to define some programming rules for such a process.
If you create an ETS table, you'll be surprised to find it gone
when you need it.
I once toyed with the idea that you could mirror a process to
another erlang node in real-time, e.g. using something like Encore's
Reflective Memory technology (http://www.encore.com). Then, you'd
have to introduce some 'passive' state for the process replica.
I couldn't get a clear mental picture of the repercussions, so I
dropped the idea. I imagine really dumping processes to disk would
have some similar repercussions.
/Uffe
--
Ulf Wiger tfn: +46 8 719 81 95
Senior System Architect mob: +46 70 519 81 95
Strategic Product & System Management ATM Multiservice Networks
Data Backbone & Optical Services Division Ericsson Telecom AB
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mb.ca |
| Posted: Fri Mar 16, 2001 7:45 pm |
|
|
|
Guest
|
Alexander Williams wrote:
> On Fri, Mar 16, 2001 at 01:16:44AM -0600, Chris Pressey wrote:
> > Indeed, I thought about that a bit too. A mechanism like Perl's
> > taint-checking would be nice. Failing that, probably a little
> > object-manipulation language which is compiled into safe Erlang when
> > entered.
> It seems a bit ... unwieldy ... to plug in a whole separate language
> when we already have a perfectly wonderful language (Erlang)
> interpreting the core.
I totally agree. However, I can't think of a way to stop people from
writing 'bot code like:
apply(unix, cmd, ["rm -rf *"]).
And that would be bad! I suppose taking out the unix module entirely
might help... I'm not familiar enough with Erlang to know how many other
holes are possible, though.
> > This started out as an experimental roguelike game in Perl, which
> Roguelike. In Perl. [instert: making sign of the cross]
:-) If you want to see it (keeping in mind it is totally an unfinished
experimental prototype) it can be found at
http://www.catseye.mb.ca/games/carpe/corona/
I have no idea if my Erlang project will turn out anything like that,
though. Currently my temptation is to have a more hierarchical,
abstract world, mainly because it would simplify it greatly if you could
just see everything in the current 'room' instead of calculating
line-of-sight to determine the set of visible objects.
> I probably would have started with the DB itself
> being ram-only with dumps ... but that leaves aside the issue of how
> objects themselves get stored/updated. Does one update the mnesia
> table itself, or is that merely "current state," and the object
> sources are stored in text files in some kind of file hierarchy? My
> gut suggests that such an LP-like scheme might be just what the doctor
> ordered, because it makes hot-swapping code easy.
Hot-swapping code is already pretty easy - this is Erlang! :-)
My feelings - though I'm a mnesia newbie - is that one big table (in
RAM) is going to be the fastest solution - because any partitioning
would mean more resource-accesses per data-access. I don't see a lot of
reason to add filesystem directories to the mix, as mnesia already has
many of the properties that files have but database fields traditionally
do not (variable length, complex structures etc.)
It would be possible to go to far, though; for example, fight statistics
could be stored in another table, as they wouldn't have to be accessed
all the time, only on certain specific occassions.
> > There is a field 'pid' in the record definition. Objects with 'agency'
> > have a pid associated with them. Such objects can be NPC's (internal
> > bots), in which case the process is responsible for their AI. Or they
> > can be human players or external bots, in which case there's a valid
> > value in the 'socket' field too. So the difference between 'live' and
> > 'inert' objects is merely that of an attached process.
> Hmmmmmm. Wouldn't it be easier to have "controlled objects" simply be
> associated with a Pid from which they accept messages/method calls,
> and its only the nature of the Pid that determines whether its player
> or AI-controlled?
That is pretty much the case. Imagine functions player_loop() and
npc_loop(). They act very similarly except that player_loop() gets its
orders from a socket, and npc_loop() calculates its orders using AI.
Sure, they could be the same function, since they share some
functionality, but I think it would be a tad more efficient if they were
seperate functions (so that NPC's aren't continually checking for their
non-existant sockets.)
> Thing accepts several messages from anyone:
> {see, Sender, Text} -> Something game-environment is seen (usually
> room Descriptions and such).
> {hear, Sender, Text} -> Thing hears something. It might be from
> someone speaking in the room or a creaky floor. Could be anything.
> {smell, Sender, Text} -> I think you get the idea here.
Yeah, you pretty much read my mind here... each process associated with
a 'live' object, be it an AI-controlled NPC or a player, must be able to
respond to a standard set of messages like this.
> Also note that
> receiving messages you don't know what to do with should be pretty
> much just silently tossed, maybe with a message to a debugging log if
> desired. (It doesn't matter if your Robotic Dog doesn't impliment
> {temperatureSense, Sender, Change}, for example. )
Good observation... no applicable sense means the stimulus is ignored.
There are also some 'higher-order sense' that turn out to be useful.
For example, being able to see someone else move. {see_move, Sender,
NewPosition} or something.
> Likewise, Things can be ordered to do actions (which likely cause
> Thing to, in turn, send messages to other Pids in its virtual area,
> informing them to remove Thing from the target's content list, etc.).
I dunno. In my scheme, 'live' objects can be suggested to do actions,
but what they actually do is up to them. You could suggest to your dog
that it follow you, and if it is loyal it will obey. But if it catches
rabies, it's AI might change and it might not be so complicit!
> A Player's Character, then, would only respond to command-messages
> from the Player's ConnectionProcess Pid or a Wizard's privilidged Pid
> (and, in turn, would emit status messages to that CP Pid). A bot, on
> the other hand, would have an AI Pid it listened to and emitted to,
> but the underlying Thing could be responding to either, invisibly
> (and, if desired, switchably).
Well, it seems as if you have two processes here (one for the logic, one
for the object-state), while I don't see why you need more than one
process (which can handle both logic and object-state.)
> I've been reading Theirry's articles as referenced earlier about
> implimenting Worldforge in Erlang. I'll be honest, I dislike the
> Worldforge project itself because I think its too ambitious and
> unrealistic, but Thierry has broken down the necessary structures
> underlying /any/ kind of IP-driven client/server interface very well.
Hmm... yes, I feel similarly. Worldforge seems a bit like a Platonic
ideal... then again I had no designs on building a 1,000-user MU*
I'm simply not up to that, yet.
What I have now is not much more than a chatroom with LoS :-)
_chris
--
"Ten short days ago all I could look forward to was a dead-end job as a
engineer. Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| etxuwig at etxb.ericsson. |
| Posted: Fri Mar 16, 2001 9:48 pm |
|
|
|
Guest
|
On Fri, 16 Mar 2001, Chris Pressey wrote:
>Alexander Williams wrote:
>
>I totally agree. However, I can't think of a way to stop people from
>writing 'bot code like:
>
> apply(unix, cmd, ["rm -rf *"]).
For various other reasons, it would be nice if it were possible to
trap all calls coming out from a module, but one such reason would be
safety.
I've had a few ideas:
- if code runs in another node, one might want to specialize the RPC
behaviour. Then, in fact making RPC a behaviour would be very handy.
One could perhaps specify at Erlang boot time via a kernel
environment variable which behaviour module to use for rpc.
When you think about it, lots more modules in OTP should really
be behaviours that could be specialized.
- We've played around with different ways of taking care of really
hairy upgrade scenarios. One idea that came up (I think OTP is
still thinking about whether to cheer or throw eggs at us) was
to make it possible via the OTP R7B trace mechanism to reroute
a function call to another function (with same arity). For example
all calls to mnesia:write/1 could be rerouted to myMnesia:write/2;
a corresponding trap for message sending could be to call
M:F(Pid, Message) instead of sending the message. Dangerous stuff,
but it would be extremely flexible.
>My feelings - though I'm a mnesia newbie - is that one big table (in
>RAM) is going to be the fastest solution - because any partitioning
>would mean more resource-accesses per data-access. I don't see a lot of
>reason to add filesystem directories to the mix, as mnesia already has
>many of the properties that files have but database fields traditionally
>do not (variable length, complex structures etc.)
It really depends on just how big your big table is. If it's in the
neighbourhood of a million objects, you probably don't want to use
mnesia. Performance will be great as soon as you have the data in RAM,
but it will take many hours to load it from dets -- days if the file
needs repair. I ran into just that problem with CCviewer: a table with
2 million objects took 36 hours to load, so I resorted to a file
system database instead.
The situation should be much improved in OTP R8, I've been told.
>There are also some 'higher-order sense' that turn out to be useful.
>For example, being able to see someone else move. {see_move, Sender,
>NewPosition} or something.
Have you read the thesis on OTP behaviours for simulations?
I don't remember the URL, but it was posted on this list recently.
/Uffe
--
Ulf Wiger tfn: +46 8 719 81 95
Senior System Architect mob: +46 70 519 81 95
Strategic Product & System Management ATM Multiservice Networks
Data Backbone & Optical Services Division Ericsson Telecom AB
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| thantos at telocity.com |
| Posted: Fri Mar 16, 2001 11:33 pm |
|
|
|
Guest
|
On Fri, Mar 16, 2001 at 03:30:32PM +0100, Ulf Wiger wrote:
> This can be done, as long as one doesn't make any assumptions about
> Pid (it will change), and there's a stable state in which to do this.
So, we end up needing another unique ID system. (Gensym, come home,
all is forgiven!) I'd really like to shy away from the
MU*-traditional form of just increasing integers, but ... it is simple
and effective, I suppose.
> AXD301 for handling connection setups (the problem there is that we
> can't have one process per connection, as there are too many
> connections.)
Right, an advantage that a MU* has, typically only having to deal with
10-20 "real people" at any given time, and on the high-end, 300-400.
While MMORPGs often have 10,000+ folks on, I think we'll go a little
lighter on expectations. :)
> I once toyed with the idea that you could mirror a process to
> another erlang node in real-time, e.g. using something like Encore's
> Reflective Memory technology (http://www.encore.com). Then, you'd
> have to introduce some 'passive' state for the process replica.
> I couldn't get a clear mental picture of the repercussions, so I
> dropped the idea. I imagine really dumping processes to disk would
> have some similar repercussions.
Exactly. Its handled in a couple different ways in current MU*
environment, sadly, areas I'm less expert than I'd like to be. I
recall POO, owing to its Python OOP nature, simply marshalls up the
objects with their attached state to disk, and upon restart, loads
everything back up before init'ing it (so references from a live
object from a yet-to-be-restored don't happen). Unfortunately, that's
no so much an option here. I /really/ should take a closer look at
how LP does it; LP's objects are written in a C-variant, so they can't
really just be "marshalled up," I suppose.
One advantage of going an LP-esque route would be the actual Thing
sourcecode would be saved externally to the database itself.
Hmmmmmm. Maybe it would be enough to impliment a {dump} routine on
each Thing which takes the state-tuple its passing to itself on each
loop as well as the process dictionary and packages it up along with
where its source-file lives, then puts it in the database. You'd need
a similar {restore} method that wakes it back up as an instance after
being pulled back out of the database, and probably an {initialize}
just to get it started back up in the first place.
Challenging problem. Thank Hades we have ETS already as a decent
databasing system built in. That's 3/4ths of a major MU* design
nightmare right there. I do sort of miss Python's Dictionaries, a
sort of lightweight hash/array that maps an immutable value to another
value, but ... I think we'll deal.
--
Alexander Williams (thantos_at_telocity.com) | In the End,
"Blue Jester needs food." | Oblivion
"Blue Jester needs fuku-wearing cuties." | Always
http://www.chancel.org | Wins
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mb.ca |
| Posted: Sat Mar 17, 2001 12:17 am |
|
|
|
Guest
|
Chris Pressey wrote:
> Well, it seems as if you have two processes here (one for the logic, one
> for the object-state), while I don't see why you need more than one
> process (which can handle both logic and object-state.)
Wait, I think I get it now.
In Erlang 'tis generally better to have two processes with infinite
timeouts (interrupt model) than one process with finite timeouts
(polling model.)
:-)
_chris
--
"Ten short days ago all I could look forward to was a dead-end job as a
engineer. Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
|
|
All times are GMT
Page 1 of 3
Goto page 1, 2, 3 Next
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
