[MUD-Dev] Tuplespaces and MUDs
Matt Cruikshank
mcruikshank at vitalimages.com
Fri Sep 3 21:53:19 CEST 2004
J C Lawrence asked:
> Are tuplespaces interesting for game development? What would be
> needed to make them more interesting?
Well, I couldn't find a C++ version of them. And the Linda-C stuff
that I found used its own compiler to create tuplespace executables.
I feel that tuplespace libraries would need to be more of a
general-purpose tool in order to receive any wide acceptance.
What kind of tuples do you envision, JCL?
in("Health", playerID, ?health)
out("Health", playerID, health-damage)
That kind of thing?
It seems to me that the processing model of tuplespace isn't very
appropriate for MUDs, and other than that, you'd just be using a
tuplespace repository as a relational database. I say that, because
input and output is definitely based on a connection between the
client and the MUD server. Unless you plan on distributing the
execution of player commands?
SERVER (machine with connection to client):
socket >> commandText;
out("action", playerID, commandText)
in("result", playerID, ?outputText)
socket << outputText;
PROCESSOR:
in("action", ?playerID, ?commandText)
out("result", playerID, outputText)
And maybe you break it down further at that point, such that the
PROCESSOR is actually first a PARSER, and then you have separate
processors for each room, maybe? Or for each zone, or for each kind
of activiy?
THE SHIRE ZONE PROCESSOR:
in("action", "shire", ?playerID, ?commandText)
// handles things like dialog?
COMBAT PROCESSOR:
in("attack", ?playerID, ?commandText)
// handles ALL combat, maybe?
MERCHANDICE PROCESSOR:
in("buy", ?playerID, ?commandText)
See, I'm having a problem here, because the SERVER needs to keep
taking input and sending output from the client on an asynchronous
basis. Tuplespaces seem to be based solely on synchronous input and
output. Some activities can be asynchronous, but I can't see how
I/O would work, with what I've read.
So, to answer your question, I think that tuplespaces need to come
in a general-purpose SDK with an easy-to-use C++ API, and they need
to support asynchronous (or at least non-blocking) in/out
operations, for them to be useful for MUD development. (Maybe a
"select" command that doesn't block?)
Could you post some more links for where I can find some more
information? A Google search returned a bunch of glowing reviews,
but nothing particularly useful for a C++ programmer. =3D)
-Matt
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list