Introduction

Hrm, well, where to begin? InnerSpace has been in the design process for four years now, and has been written and rewritten many, many times. Each time I always thought, "Oh, I've got everything figured out, so I should be finished Real Soon Now." Ha!

So What Is It?

The buzzword-compliant description would be: InnerSpace is a text-based virtual reality framework that allows multiple Internet users to connect to, manipulate and aid in the creation of a limitless universe.

In other words, it's a MUD, but it's the best damn MUD out there!

History

Initially, this project started as a port of LambdaMOO to Java. Of course, I didn't even get halfway through the first design without realizing a million things that were either A.) annoying design choices in LambdaMOO, or B.) practically impossible to implement in Java. I got pretty far, too, before I realized this (in fact, I still have the original version of InnerSpace written in Java using mucho RMI ). I realized that there were a number of things that I wanted to implement that other MUD/MOO/M* packages just didn't. BTW, I'm going to use the phrase MUD from here on, even though it's an oversimplification.

Things MUDs Should Have

• Authoring Support/Permissions Model - I wanted to be able to safely give any user programmer's rights, without having to worry about the havoc they could bring on the system.
  
• An Elegant Internal Programming Language - Initially, I was going to just embed a Python interpreter into my Java code, but I realized that Python's cool factor was just too great. So now the whole server is written in Python.
  
• Better Object Referencing - Most MUDs suffer from issues with naming objects. There's basically two established methods; you either assign each object an arbitrary unique ID (LambdaMOO's method), or ensure that no two objects share the same name. These methods had various shortcomings. If each object had a unique ID number, you could allow the name property on various objects to be the same. However, the drawback was that if your player character was not physically in the same room as the object you wanted to refer to, you were forced to refer to it by it's ID, like #175847. Conversely, if each object has a unique internal name, you'd be able to refer to something like candle(4). However, for things to look less intrusive, you had to set a special property that would change the name users saw when they looked at an object. You then assigned an aliases property that would provide a number of other ways to refer to the object.
  
  My solution is nicer, I think. The inner.space.registry keeps track of all objects by name and ID. So for the most part, you just refer to objects by their name. But if there's more than one item with that name, an AmbiguousError is raised by the parser, which asks "When you say, 'candle', do you mean candle (#456), candle (#726), or candle (#5)?"
  
• A Graphical Object Editor - So I may have come to appreciate UNIX, but I still love my Macintosh. By the same token, I want to be able to see at a glance all the major attributes of an object and be able to edit them easily.
  

So Much Code, So Little Time

Really, there's many things that I think make InnerSpace pretty cool. If you're still with me at this point, you rock. Here's some miscellaneous neat stuff:

• All game objects (users, rooms, doors, etc.) are represented by one class. Any object can potentially be a container for other objects, though by default they are not. Objects have a parent, which gets consulted if a selected property or verb isn't found on the child.
• Every command entered by the user forks a new process to run the code in. That way a malicious (or stupid) user can't lock up the rest of the system, only it's verb call.
• The Pyro (PYthon Remote Objects) package is used to allow child processes access to the world's objects. It's been rather elegantly hacked (I think) to allow a sort of verification by remote code, so the (yet unwritten) object editor can be a little easier to write, while still being fairly secure.
• The InnerSpace client is still written in Java, which allows for easy distribution by applet or other platform-independent method.