what about using javaspaces for handling mmpo worlds?
or is it best to use a ‘simulation’ and wrap all your own
calls over tcp/ip etc…
just ‘take’, ‘write’ etc seems very neat- maybe it hasnt
got the speed needed for mmpo?
just intrested in peoples thoughts.
There was a bit of discussion about this subject lately at mud-dev
The basic concept is almost essential to writing good semi-infinitely scalable systems.
But games developers don’t tend to like it much…
so no ones tryed it? it looks like javaspaces is just a
wrapped up RMI- and that seems abit over the top
for tracking game object?
i’ve used jini and javaspaces to build a highly scalable service oriented architecture for bioinformatic services. the architecture is very ripe for mmpog: distributed transactions, naming services, leasing services, and javaspaces.
i have zero experience with mmpog architectures and can only base my opinion on my own experience building discrete event simulators and soa architectures, but, i think the technology is a fit.
in mmpog’s i believe the key is in grouping objects based on probablity of interaction, proximity, state of an entity, or a network of interactions among entities. these obvious partitions are implemented via javaspaces. operations on the group or individuals is implemented as a jini service. attributes of the object are implemented as a java class.
[quote]so no ones tryed it? it looks like javaspaces is just a
wrapped up RMI- and that seems abit over the top
for tracking game object?
[/quote]
Not by a long way! Tuplespaces (as it’s more rightly known) is completely unrelated to RMI, architecturally.
Anyway, as the above quote shows, we’re using tuplespaces (albeit in a different guise - free-floating MQ’s). We have considered doing a javaspaces wrapped implementation of some of our tuplespace stuff to see how it compares to the current implementations, but as far as I know no-one here has used it in anger…
PS copy/paste misattributed that quote - I’m about to fix it
From experience, those groupings are relatively unhelpful in any large scale MMOG. You have to use tuplespaces at a more abstracted level in order to reap the rewards (high degrees of parallelism etc)
just i read this someplace:
i would love to get me head around this… sounds very
interesting stuff. im making a simulation that has lots of
object and i was thinking this maybe the way to go.
there will also be lots of connections (players) interacting
with the objects in the space in realtime.
look in your local bookstore for this book: http://www.amazon.com/exec/obidos/tg/detail/-/0201309556/104-2050770-3847115?v=glance it will plant the seeds…
can you elaborate? don’t you use tuples to represent the state of a player or entity in the world, and a tuplespace as a set of related entities?
sun’s implementation of jini/javaspaces is tightly coupled to rmi. all the core services are constructed as rmi activatable services (reggie, ma. all javaspace objects must be rmi friendly (serializable). if you build any user services to interact with a javaspace out of process or in a distributed fashion, you will use rmi. in sung li’s jini book he spends a few chapters getting those not up to date on all facets of rmi up to date.
i think jini/avaspaces is much more than the original tuplespace in that a javaspace contains objects with methods and i think the original definition of a tuple is just data. jini also provides a plethora of services for architecting distributed solutions: leasing management, discovery/lookup, distributed transaction management, distributed events. i’m not sure that gelertner’s original concept provided such a complete set of building blocks.
Sure, but my point is that the two are entirely different things, not (as the OP questioned) simply minor extensions of each other.
Tuplespaces are an alternative programming paradigm.
[/quote]
i think jini/avaspaces is much more than the original tuplespace in that a javaspace contains objects with methods and i think the original definition of a tuple is just data. jini also provides a plethora of services for architecting distributed solutions: leasing management, discovery/lookup, distributed transaction management, distributed events. i’m not sure that gelertner’s original concept provided such a complete set of building blocks.
[/quote]
Well, objects with methods ARE just data in the java world. I’m not really comparing to whatever the original CL/linda roots were, but what people have spent the last X years using as the generic concept + programming paradigm of TS’s. I’ve only used javaspaces having already known TS’s and not noticed any differences (yet).
Sure, the JINI services are useful, but are they an intrinsic part of javaspaces (both are available as separate downloads, aren’t they?).
That’s not a trivial question to answer, and the going rate for consultantcy on this is $85/hour…
Grexengine.com is being redesigned at the moment now that some of the patents have been granted. The new content may include an article on this, because it’s an interesting set of problems. Could be a while though, I’m afraid.
hahaha blabla’’’’ - heres somthing for u that confuses
me- wonder if u could wave the $85 
i got like a rubber
band and some old fluff in me pocket if u want that :)?
anyways… heres what makes me abit confused…
if we make a game with javaspaces the objects are
serialized and stored yes?
then say we have a house class. then the database will
have loads of serialized house instances.
if we update the house class because of a bug 
then
what happens to all the old serialized house instances
stored in places all over the network…???
depend what you modified in the class and whether you include a constant serial version in your class.
now, replacing this house dynamically without shutting down the jvm is a complete different problem that requires more abstraction, registration, versioning metadata, etc…
[quote](both are available as separate downloads, aren’t they?).
[/quote]
nope… javaspaces are just one service in jini.
fair enough blahblahblah, but intuitively it seams very easy to map the mmpog framework requirements directly onto jini or a jini-like framework. sounds like fun stuff…
Sure, it’s intuitive. But intuitive != effective. Most complex systems don’t work if you merely try to fit them into an arrangement that is conceptually obvious and sensible to a human - instead you usually have to find what is convenient and efficient for the hardware and software platform.
NB I’m not trying to be patronising (I’m sure you know this already), just trying to make clear what I mean by saying you can’t just do what would seem sensible.
agreed :> …further, until you’ve created such a beast it is just an academic exercise at best, but fun nontheless.
They were, up to Jini 1.2 but after that RMI was just one of a few pluggable transport layers. JERI is the reworked and rethought replacement for RMI.
I and my company, Kayak Interactive, and it’s predecessor have worked with Jini for over 4 years now - pretty much since the beginning. Funny coincidence, Jini and multiplayer games:)
Bill