introduction

hrm, well, where to begin? innerspace has been in the design process for almost eight 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!

oh, and to get it out of the way, yes, innerspace was the name of a somewhat preposterous movie from the 80s. this is merely a coincidence ;-)

so what is it?

the buzzword-compliant description would be as follows:

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!

okay, that might be an exaggeration, as my experience with muds comes exclusively from a programmer's standpoint, other than my various interactions with games like lambdamoo, avalon, etc. i never got very far with those games because generally i'd find things i didn't like, or felt i could improve upon, and that sent me back to the drawing board, to design a game that worked exactly the way i wanted it to.

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.

but before i get to anything else

i would like to thank the twisted python project, specifically matt "glyph" lefkowitz, for the marvelous framework they created, which let me skip large amounts of uninteresting coding to focus on stuff i liked. there was a huge jump in stability and functionality when i switched from a horribly hacked version of PyRO (also a fine framework, at least, before i started screwing with it), to an only slightly hacked version of twisted.

additionally, i have to admit that i borrowed a number of ideas and design methods from the things i learned while working with glyph on a sort of predecessor to twisted-python -- a java-based text-based game called divunal, run on an engine he created called twisted reality.

just as a story for posterity, because i don't know if it's out there anywhere, twisted-python started as a port of twisted reality to python, from java. when glyph mentioned his work on this, i hadn't learned python yet, and i believe my words were, "who uses python? why don't you just write it in perl?"

moving on.... ;-)

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.

        [this partcular goal fell a bit short with the destruction of python's
         RExec framework. currently, it IS NOT SAFE to provide programmer rights
         to untrusted coders. however, the framework is there to provide a
         restricted execution environment, and work is underway myself to provide
         a reasonably secure environment.]

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
many 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.

        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.

InnerSpace is made available under version 2 of the GNU General Public License. The included LICENSE file describes this in detail.

Warranty

THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE USE OF THIS SOFTWARE IS WITH YOU.

IN NO EVENT WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY, BE LIABLE TO YOU FOR ANY DAMAGES, EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Again, see the included LICENSE file for specific legal details.