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