Xarble


Java as a Scripting Language
           I was going to write my own parser/interpreter for some silly subset of Scheme for our scripting language, and I knew it would be a lot of work, and not very fun, and it would probably end up being be very limiting to the script-writer.
           Instead, I am now planning on adding a JVM to Xarble, and using Java as our interpreted scripting language, right out of the box.  And, if your VM has JIT compilation, then we (you) get that performance boost for free!  (There's no way I was going to write a JIT system for XarbleLisp.)  Also, it makes the whole scripting thing very much easier and faster to implement, so now I can spend my time doing other things, like making the combat system more complex.
           In any case, I'd like LOTS OF FEEDBACK on this idea, before I start to implement it.  Is it a good idea?  ;Bad idea?  Why?  ;How could I best implement this?


How I Plan on Having Things Work
           The basic idea is that I have some sort of API that interfaces with the Xarble C++ code.  Stuff to print messages to the screen, pop up text boxes, all of that fun stuff.  This would probably consist of a C++ side, implementing the features, and a Java side, wrapping the native calls to the C++ functions.  The JSL API will probably involve having a mirrored inheritance tree, in which the Java instantiations will represent instantiations of Thing (and sub-classes of Thing) objects. Let me clarify with an example:
           Let's say we have a map consisting of RedShirt and GreenShirt, and the weapons they carry (RedShirt has a Small Laser Pistol and GreenShirt has a Big Club).  So, that means that the JVM would have two JavaLiving objects instantiated, one for RedShirt and one for GreenShirt, as well as two JavaWeapon classes instantiated, one for the Small Laser Pistol, and another for the Big Club.  The JavaWeapon class would consist of wrapper methods that natively call the appropriate methods in the ACTUAL Weapon class.  Etc...  This kind of sucks, because it means that there's THREE different parallel classes to think about now, RootThing, Thing, and JavaThing (and their derivatives).  If there's a better way to do this TELL ME PLEASE GODDAMNIT! WHY ARE YOU SO QUIET OUT THERE?! Ahem.  Yeah.

Plans for the Future?
           This should make things fairly simple if we ever decide to convert our Xarble engine to a Client/Server MUD application.  It would be like a normal LPMud, but with Java instead of LPC, and with a GUI instead of a Infocom-like text interface.  This is something I'm interested in, as I was a MUDder for quite a long time, and that sort of open development multiuser environment is really cool.


Addendum: 14 APR 1998
           Hmm.  It seems that this is going to be more complicated than I expected.  Actually, quite a lot more complicated.  There are all sorts of reference issues between Java and C, and Java doesn't interface with C++, at least not yet.  You have to write C wrapper functions for any C++ code you want to execute natively. As such, you cannot use any object-orientedness in C++ with Java... at least not directly, so you have to "flatten" the data structures in transit.  Evil, I tell you.


Addendum: 01 AUG 1998
           I've decided on a model change for this JSL thing. Instead of keeping track of all the stuff that's already kept track of in C++ in the JVM, I'm just going to instantiate the wrapper classes as things are needed, and toss them when they aren't.
           I was also considering moving the entire object system into the JVM exclusively, but decided that that could slow things down too much. I'll have to do that, though, if ever I want to make it a MUD-type thing. I'll just save that for later, okay? :D


Mail the author of this page at iffy@uclink4.Berkeley.EDU.