Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Games Entertainment

Suggestions for a new Java-based MOO 10

Dan Hon asks: "A friend of mine is in the middle of writing a Java1.1 based MOO provisionally titled "m++". We're on the look out for new features that we could incorporate - really groundbreaking stuff that has been on peoples' wishlists, but hasn't been implemented yet. We've come up with a few cool ideas ourselves like transmitting sounds between rooms to a certain distance radius so you can hear "muffled" conversations, implementation of path objects between rooms so that locations can be "flooded" along the same lines of the sound transmission, and others. Does anyone have any other ideas? You can access the current status of the project at this location."
This discussion has been archived. No new comments can be posted.

Suggestions for a new Java-based MOO

Comments Filter:
  • I'd like to see something where any given object in the world has both text and graphical representation, and you can interact either via a traditional text-based client or via a ultima-style graphical client.

    --

  • First of all: end users are *supposed* to be able to get it running! :-)

    A 1.0 release is scheduled for this saturday, seeing as how it's been in pre-X for a six months now... If you haven't been able to get the software running at all, the TME staff would welcome your patches, comments, bug reports, etcetera. Requests for documentation in specific areas would be nice too, because at this point we're not sure what's documented and what's not.

    I will spare you the long plug for TR's design, and say simply this: the ideas which you are discussing could easily be implemented on top of TR, and TR was designed with things like that in mind. I would really encourage you to look at the TR API before going off and reinventing the wheel yet another time. TR stores everything (in a fairly efficient manner) as something like a relational database of MOO objects, like LambdaMOO, but without all the permissions (and IMHO with a much better authoring toolkit) Also -- depending on what kind of game you want to make, the Entity project is pretty interesting too. Also written in Java, also Open Source. (Personally, I don't care for their statistics model or heavy use of reflection, but then, I'm odd)

    Divunal, by the way, is a different project from TR (we've been kinda vague about that) it's the game itself, whereas TR is just the engine. Divunal is going to be a commercial product, though, and contains lots of really specific code to *our* game, that we don't feel would be generally useful.

    The generally useful bits will probably be released under the GPL in a few months, or sooner if anyone voices a specific interest.
  • You might want to take a look at the COG Engine, it's a Java-based Online Gaming Engine, released under the GPL. Feel free to use any of the code, I'm the author! (c:

  • Some security considerations, of course -- don't want the users changing the rules of the dungeon too much -- but it'd be cool if they could upload their own Java-based objects/modules/avatars/etc (using GetClassByName or whatever the API is) to alter (within bounds) the behaviour of the environment. This can go far beyond (possibly too far beyond) what any built-in scripting langage might be capable of, and saves you the trouble of writing one.

  • The interesting thing about MOO (if you mean the servers related to LambdaMOO) is that multiple users with varying levels of trustedness can extend the system.

    There should be some rant here about how MOO servers leverage many of the qualities of Open Source software, but I'm too tired to spew the right buzzwords.
  • I used to be really into MOOs, not because of the social-interaction stuff but because they're such a neat computing metaphor. Everything's stored inside a database, including the programs that manage the database! And everything's hierarchical, so scripts can make variables globally accessible. Very cool stuff.
    In my opinion, a MOO should just be a programming language with a database back-end, and everything else written in that language. That way, you can use the database for anything you want- a MOO, for instance, makes a really great scriptable web server (not quite as good as Zope [zope.org], though). And you can use it to serve basically anything you want. Instead of making just a Java MOO, why not make an extendible application platform, with a database that can execute code, which happens to work particularly well for serving text-based virtual reality worlds?
  • If you're looking for java-based MU* servers and client ideas, see what you can sniff out of the TwistedReality engine. It's apparently GPL'd.


    Since I couldn't get pr1 or pr2 to work, I'll likely wait until they distribute something an end user can get running and have some fun with before I take a peek at it again.

Cobol programmers are down in the dumps.

Working...