Java as an IF authoring language?
Stephen Tjasink
After returning to this group after a few years I see the same
TADS vs Inform vs other languages debates going on so I thought
I'd add some comments. I have a feeling I might have posted about
this before but can't remember...
One of the main problems that people have with using IF authoring
languages is that they have to learn them, resulting in many
"how do I do X in langauge Y?" type questions. The solution to
that problem at least would be to use an existing programming
language.
Java seems suited to the job, as far as I can see. Code for
dealing with situations can be put in standardly-named methods
in the object. For example code to do something when an object
is dropped is placed in that object's OnDrop method. These methods
are called by the interpreter when they are needed and game objects
can be modelled by normal Java objects.
This would use the standard Java compiler and have to run on a
slightly modified Java virtual machine. Parsing input could either
be done in Java or internally by the machine - doing it in Java
would allow the programmer to change the parser if he wanted to.
The choice of Java is motivated by two things. The first is that
it seems to offer all the object-oriented operations one would need
for dealing easily with IF games. The second is that it is interpreted
so the interpreter can be modified to do necessary tasks (e.g. call
an object's OnDrop method when the object is dropped).
I haven't tried writing any games with newer versions of any of the
available IF authoring languages so I don't know how they perform...
I was hoping someone could tell me if trying to get Java to do it
would be worth while or if other languages cope fine as they are. :)
Stephen
--
/--------- Stephen Tjasink aka stja...@cs.uct.ac.za ----------- Vermillion -\
| University of Cape Town, Cape Town, South Africa -==UDHISS==- |
| For Space Quest fans: http://www.cs.uct.ac.za/~stjasink/sq/ -==UDIC==- |
\ For Bubble Bobble fans: http://www.cs.uct.ac.za/~stjasink/bb/ ---- \/ -----/
HarryH
In article <6j95rq$aij$1...@groa.uct.ac.za>, stja...@cs.uct.ac.za says...
>One of the main problems that people have with using IF authoring
>languages is that they have to learn them, resulting in many
>"how do I do X in langauge Y?" type questions. The solution to
>that problem at least would be to use an existing programming
>language.
>
>Java seems suited to the job, as far as I can see. Code for
Take a look at this if you want to make text adventure in Java.
http://fan.net.au/~dodo/java/text-adventure/index.html
Of course, the questions will then be "how do I do X in Java and its
classes?"
:)
-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant
Matt Kimball
Stephen Tjasink <stja...@cs.uct.ac.za> wrote:
: One of the main problems that people have with using IF authoring
: languages is that they have to learn them, resulting in many
: "how do I do X in langauge Y?" type questions. The solution to
: that problem at least would be to use an existing programming
: language.
: Java seems suited to the job, as far as I can see.
Well, not all IF authors already know Java, so they would have to
learn a language anyway.
I think one of the major reasons that the existing IF languages are
better suited to writing IF than Java is that in the existing
languages you can define methods and properties for objects, where in
Java, you can only define methods and properties for classes, which
are later instantiated in to objects. This may seem trivial, but it
really is useful to have this OODB/OOP hybrid thing when writing IF.
You could extend the Java language to do this with a preprocessor or
something, but then it wouldn't be Java anymore.
Also, not all platforms that have Z-Machine interpreters available
have Java interpreters. And it is more work to write or port a full
Java interpreter than a full Z-Machine interpreter. And the Java
runtime tends to take up more resources than the Z-Machine runtime,
without gaining much as far as I can tell.
But, all of those caveats out of the way, if someone wants to write IF
libraries for Java, I would certainly take a look at them.
--
Matt Kimball
mkim...@xmission.com
Steven Posey
The first problem would be developing a parser. Why bother, when Inform and TADS (and a slew of
others) already have the parser libraries. We have Infocom to thank for developing Zilch, which
paved the way for all the others (of which, Inform was developed to behave exactly like Zilch; even
if the source code is different in style, the z-code interpreters can read both Zilch and Inform
compiled code). There's enough parser code to last us a long time, without Java.
The second problem is that Java was not designed from the ground up as an IF interpreter/compiler.
The Java VM is designed with much more overhead than z-code interpreters (the original Zilch
interpreter only took up 8K, yet it played all z-code games up to z3 -- which is MOST of Infocom's
library). Getting the Java VM to run on as many platforms as, say, Frotz would be rediculous.
Our target audience for IF isn't the people who have the big OS's with Java VM's. Our target
audience is EVERYBODY with a computer. The current IF compilers and interpreters do that job, and
do it well. I think it'd be in our own best interests to NOT write IF in Java. I'm not saying it
can't be done -- quite the contrary; Java is conceptually similar to Inform, and I think it would be
easy for a Java-coder to make some good IF. But the code would suffer from the overhead of the Java
VM; it would be considerably slower than an equivalent Inform or TADS-compiled game. Plus, it
wouldn't run on as many machines as the others would. Some of us play IF on 48K 8-bit machines, and
I doubt anyone could make a Java VM that would run under those specs. (Let's not get into a
processor war here. I happen to love my Atari 800 and I love it even more that z3 code will run on
it. I just want to keep playing IF on it as long as it still boots.)
Java's not a bad idea, I just don't think it's time has come as an IF authoring tool... IMHO ;-)
Steven
John Elliott
Matt Kimball <mkim...@xmission.com> wrote:
>I think one of the major reasons that the existing IF languages are
>better suited to writing IF than Java is that in the existing
>languages you can define methods and properties for objects, where in
>Java, you can only define methods and properties for classes, which
>are later instantiated in to objects.
IMO this is a fairly big problem with developing IF using Java source.
You'd have to define the object (as a class) in one place, and have another
class that instantiated all the objects somewhere. Any references in the
objects to other objects would have to be set after the objects had been
instantiated.
>You could extend the Java language to do this with a preprocessor or
>something, but then it wouldn't be Java anymore.
There's no (theoretical) reason why an IF compiler couldn't be written
that spat out Java source or J-code. I wouldn't fancy doing it though :-)
>And the Java
>runtime tends to take up more resources than the Z-Machine runtime,
>without gaining much as far as I can tell.
There have been complaints that the Z-Machine is too limited (64k RAM,
no dynamic memory allocation etc.). The Java VM might be the way to go, as
opposed to building a 32-bit Z-machine.
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
Matt Kimball
John Elliott <j...@seasip.demon.co.uk> wrote:
: Matt Kimball <mkim...@xmission.com> wrote:
:>And the Java
:>runtime tends to take up more resources than the Z-Machine runtime,
:>without gaining much as far as I can tell.
: There have been complaints that the Z-Machine is too limited (64k RAM,
: no dynamic memory allocation etc.). The Java VM might be the way to go, as
: opposed to building a 32-bit Z-machine.
Yeah, I was one of those complaining about those limitiations. But I
don't think the JVM is a good replacement for the Z-machine.
It could be done with the JVM, but I think a simple 32-bit VM would be
better. One that doesn't tie you to a particular object model, and
one that is easy to port. (I have looked at the source to a few
implementations to the JVM, and I have looked at the source to a few
implementations of Z-machine interpreters. The Z-machine interpreters
are much simpler and much more portable.)
And you can design a 32-bit VM that is much less resource intensive
than the JVM. I'm pretty confident that I could write a reasonable
interpeter core for a 32-bit VM for PalmPilot, but porting the JVM to
the PalmPilot would be a big investment. Same with a MS-DOS JVM.
Maybe it would be reasonable to use the JVM if you didn't require any
of the standard JVM classes, but I still think it is a suboptimal
solution.
--
Matt Kimball
mkim...@xmission.com
John E
If the text adventure you want can be written in Inform then there
is no need to go back to programming.
I don't think going back to pure code would help a text
adventure. A more-that-suitable engine exists and that
engine will run in the famous Z-plet, giving it every
advantage that being writen in Java gives (internet access).
To me Java and C++ are 99.99% indentical
(well, not allocating memory by hand and no pointers IS
a big difference, but I digress)
I certainly would not stop using Photoshop or Fractal painter
to draw images in code. I just draw.
Stephen Tjasink wrote in message <6j95rq$aij$1...@groa.uct.ac.za>...
>After returning to this group after a few years I see the same
>TADS vs Inform vs other languages debates going on so I thought
>I'd add some comments. I have a feeling I might have posted about
>this before but can't remember...
>
>One of the main problems that people have with using IF authoring
>languages is that they have to learn them, resulting in many
>"how do I do X in langauge Y?" type questions. The solution to
>that problem at least would be to use an existing programming
>language.
>
>Java seems suited to the job, as far as I can see. Code for
>dealing with situations can be put in standardly-named methods
>in the object. For example code to do something when an object
>is dropped is placed in that object's OnDrop method. These methods
>are called by the interpreter when they are needed and game objects
>can be modelled by normal Java objects.
>
>This would use the standard Java compiler and have to run on a
>slightly modified Java virtual machine. Parsing input could either
>be done in Java or internally by the machine - doing it in Java
>would allow the programmer to change the parser if he wanted to.
>
>The choice of Java is motivated by two things. The first is that
>it seems to offer all the object-oriented operations one would need
>for dealing easily with IF games. The second is that it is interpreted
>so the interpreter can be modified to do necessary tasks (e.g. call
>an object's OnDrop method when the object is dropped).
>
>I haven't tried writing any games with newer versions of any of the
>available IF authoring languages so I don't know how they perform...
>I was hoping someone could tell me if trying to get Java to do it
>would be worth while or if other languages cope fine as they are. :)
>
>Stephen
>--
>/--------- Stephen Tjasink aka stja...@cs.uct.ac.za -----------
Vermillion -\
>| University of Cape Town, Cape Town, South
Andrew Brault
>And you can design a 32-bit VM that is much less resource intensive
>than the JVM. I'm pretty confident that I could write a reasonable
>interpeter core for a 32-bit VM for PalmPilot, but porting the JVM to
>the PalmPilot would be a big investment. Same with a MS-DOS JVM.
Hmm, I have almost finished a VM (alas, 16 bit) for the PalmPilot
and HP48GX, along with associated development tools. I am planning
to use it for graphical adventure games but there is no reason it
could not be used for IF. The interpreter is only 8k! (on the HP48)
I chose to use a Smalltalk-like language (that is also similar in
many ways to Inform). I forsook automatic memory management for
static allocation of objects (using the development tools) and
a limited malloc/free manual allocation scheme. In this way it
is also similar to the Z-machine.
Anyways, I have had good success with the limited amount of code
I have written so far with this system. I think something like
it would be good for the next generation IF systems, once extended
to a 32 bit model so that you can use as much memory as you want.
With IF it is important to keep the size of programs as small as
possible, even today, because a large portion of the "market" or
audience is people who have PDAs and small computers, as well as
large ones, but they prefer playing IF on the small ones.
---
Andrew Brault <a...@tiac.net>
JC
On Tue, 12 May 1998 16:02:32 -0500, "John E" <johnDEL...@earthlink.net>
wrote:
>If the text adventure you want can be written in Inform then there
>is no need to go back to programming.
[...]
What's this supposed to mean?
';';James';';
Stephen Tjasink
In <87lns77...@ajb.i-have-a-misconfigured-system-so-shoot-me> Andrew Brault <a...@tiac.net> writes:
>>And you can design a 32-bit VM that is much less resource intensive
>>than the JVM. I'm pretty confident that I could write a reasonable
>>interpeter core for a 32-bit VM for PalmPilot, but porting the JVM to
>>the PalmPilot would be a big investment. Same with a MS-DOS JVM.
>Hmm, I have almost finished a VM (alas, 16 bit) for the PalmPilot
>and HP48GX, along with associated development tools. I am planning
>to use it for graphical adventure games but there is no reason it
>could not be used for IF. The interpreter is only 8k! (on the HP48)
Well my thoughts on this subject arose largely because of the fact
that a few years ago I wrote a JVM to run on digital TV decoders
with 1 Mb RAM and a 68000-series processor. It's been run on various
platforms, including 16-bit environments such as MS-DOS and seems
to work pretty well - it includes garbage collection, thread support
and all the other things that a JVM is supposed to but it runs in
muuuuch less space than Sun's bloated version. Of course, it won't
run on an HP48 or something like that.
Stephen
--
/--------- Stephen Tjasink aka stja...@cs.uct.ac.za ----------- Vermillion -\
| University of Cape Town, Cape Town, South Africa -==UDHISS==- |