A good scripting language for java games

I read this article on the subject but i still can’t decide if i trust the article:

http://www.javaworld.com/javaworld/jw-03-2005/jw-0314-scripting-p2.html

Im interested in a scripting language that uses Java syntax and can interpret Java code with classes and interfaces without any modifications like BeanShell but this is about 10x slower than Groovy and this is about 2 times slower than Pnuts and Rhino.

The size of the jar and the usabiliy of the api is also important.

So what do you think it’s the best scripting language for java games?

Frankly, that article sucks. There are bits like the long warbling look at groovy closures as a “special feature” which suggest the author doesn’t know that much (at least one of the other langauges and off the top of my head 3 of them also fully support closures).

The microbenchmark, of just one very limited set of ops, is IMHO almost a waste of time. The author apparently didn’t even know WHY things got faster between JVMs, let alone delve into the ramifications of that (at a glance, I guess it was probably the improvements to reflective method invocation. He really needs to go and investigate the overhead from reflection going on there, and e.g. make a benchmark that emphasises and de-emphasisses that).

Finally, using just one set of ops? Compelte waste of time. You need to test a whole load of things. IMHO, the author is pretty damn lazy, seeing as it would have been pretty easy for a scripting language review to write some sensible “real” code - the point of scripting languages is to make writing real code very very fast and easy!

w.r.t. to beanshell, I’d suggest looking at the mailing list archives. They are are about 12-18 months overdue on a new release that would massively increase performance. I’m not subbed any more, so don’t know why its still not happened, but I suspect its because time is goign instead on getting beanshell into JDK properly (c.f. the JSR’s, beanshell now has its own JSR). I suspect they are wating to compelte that, then they will do the perf improvements that they roughly know how to do and would make a big difference.

Why would you start a scripting language comparison with a set of performance benchmarks? The whole point of a scripting language (IMHO) is that you’ve using a considerably higher level language for places where development time is much more important than runtime performance. The most important thing for a scripting language should be how much productivity gain you’re going to get from using it. Anything which becomes a bottleneck can be pushed into the Java side of things and exposed to the scripting layer.

The only reason i need a scripting language is for people who know litle of programing to script quests with it in a game remake im working on. Speed is important because scripts are going to run every frame with some sort of script loding mechanism. Im tempted to use Javascript because it’s commonly known and looks like it has a stable development team and strong support behind it.

I was experimenting with rhino at one time and I think it’s about a 500kb jar. I think you have the right idea as javascript knowledge seem pretty common and it is in fact a sweet little language.

Hello, i’m using java 1.6.0 betas, and there is a Javascript engine built in the Java.
The Javascriupt code can communicate with Java codes(f.e.:call Java methodes, instantiating, etc.) and the Java code can communicate with the Javascript code (f.e.:change some settings, class javascript routines, etc.). So there is full interoperability.

I think, it’s fast enough (inner compiling…), and it’s an officially built in full-features script language.

I’m using it in my game project.

Sorry for my bad english.

Java 6 has a couple of good improvements to help scripting. From this article:

http://www.devx.com/Java/Article/30722/1954?pf=true

[quote]The new Java Compiler API allows Java source to be compiled from within a Java application. During compilation, the application has access to the library dependency information as formulated, along with any warnings, errors, and other messages that are generated. Although this feature did not seem like something I would use often, I quickly found new uses for it. To enable Java scripting, Java SE 6 supports JSR 223, a scripting framework that provides scripting language access to Java internals. You can locate scripting engines and invoke them to run scripts at runtime. The Scripting API allows you to provide Java support for the scripting language of your choice. In addition, the Web Scripting Framework allows script code to generate Web content within any Servlet container.
[/quote]

I’m using Groovy quite a lot these days - okay, it has some flaws, but it’s well worth adding to your toolkit. For XML generation, it’s pretty unmatched.

As for speed, Groovy can compile down to bytecode (don’t know if the OP’s article mentions this - JW appears to be down), and while I know nothing about the quality of that bytecode, it’s likely to be one of the faster scripting languages out there because of it.

I guess I question the need for a scripting language at all.

Java code can be run-time loaded. If you provide a decent API frankly I dont think ist any harder to write then any of the game-scripting lnaguages otu tehr and easier then many.

shrig

A decent API is one thing, but syntax, keywords, operators, layout etc are quite another - no one syntax can be correct in all situations. Different languages have their place, just as Java has its.

True, but most game scripting languages just crib their synatx from existing languages anyway (most often C.)

Yes, you can of course also use Java for scripting. However…
-the turn over rate isnt that nice (compilation takes a while… on slower machines its 30seconds vs some msec)
-tools.jar is rather big (6.8mb vs less than 0.5mb for any scripting language)
-long winded java syntax (thats no issue for me)

Using that compiler directly also looks pretty meh, because the documentation is somewhat lacking, it requires lots of parameters and it also needs disc access. It really isnt the best tool for the job.

I’m with Jeff on this one. I would be very surprised if the number of people who would be making scripts is going to be large enough for these issues to matter:

But it only needs to be done once, at development time.

On the other hand, the population of scripters is going to be vastly smaller than the population of players. You’d probably reduce the download burden by having the scripters get the jdk, instead of everyone having to download some other scripting language.

As Jeff said, that’s just a matter of API design.

IMHO, anyway.

But it only needs to be done once, at development time.

Huh? Its not like you write the complete game in one go and everything just works perfectly.

Using a scripting language (and media caching) makes the process very interactive. You change a script, save, switch over to the game, press F5 (or whatever) and you see your changes in effect. Its really cool and lots of fun. Its super awesome for prototyping, because you can just go ahead and try differing things out, tweak variables and see how it feels etc.

On the other hand, the population of scripters is going to be vastly smaller than the population of players.
You’d probably reduce the download burden by having the scripters get the jdk, instead of everyone having to
download some other scripting language.

I ment that its like that if you want to ship your game/application with build-in scripting abilities. I for one dont ship any extra script jars, because I just compile my stuff once I’m satisfied with it. And well, yea I’m fine with java syntax, because it allows me to do this :wink:

Btw I’m using Janino for scripting. Its a very fast on-the-fly java compiler. So, I’m basically using java for scripting. My framework allows me to use any other scripting language if I want to. But I’m using this one, because its the only way to get full java execution speed. (WYSIWYG ;))

Have you used Eclipse?

It compiles your Java on the fly whenever you save. And its very fast 8)

Indeed. But depending on who needs to be able to understand and update your scripts, Java may be entirely inappropiate for the task.

Try explaining to a non-technical game-designer wannabe (who you’d dearly love to be able to implement simple new game rules in your engine) why the length of a String is “length()”, of a String[] is “length” and of a List is “size()”. And explain how to interpret the error message which results when he gets it wrong.

Java is a great language, but appropiate for all tasks and for all people it is not! :wink:

Eclipse yea… well, its pretty fast. But starting it in first place takes a while… eats lots of ram… then some swapping etc. Its pretty heavy. Whereas using a scripting language is more like writing html. Yea, its really like writing html. Also if you write over in eclipse, save, switch over, press reload… then there is no gurantee that eclipse is done with compiling. (Using jdt for compiling directly is certainly more appealing.)

[quote=“oNyx,post:17,topic:26954”]
Eclipse tells you when it is building on bottom right corner of the Eclipse window. In the rare case when it isn’t instantaneous (e.g. it has to rebuild the workspace) you can easily wait until it is done.

But more to the point… you could probably use BeanShell to prototype some aspects in an interpretted mode and then provide the final compiled classes for distribution. Keeping things Java would simplify some aspects of the scripting, though Java 6 will have the proper scripting support for all sorts of scripting languages, so that might make more sense.

There isnt much of a reason to use a less optimal tool. Watching some corner… having to wait eventually… nah… why should I bother with that?

But more to the point… you could probably use BeanShell to prototype some aspects in an interpretted mode
and then provide the final compiled classes for distribution.

Thats pretty much what I do (as I said). But I use janino instead of beanshell. At the end I just compile it and change a line in a configuration file… thats it.

Java 6 will have the proper scripting support for all sorts of scripting languages

If you grab that jsr jar you can use it right away with 1.5. However, I didnt found it useful at all. Its not suited for scripting complete classes (see above)… its more of a lowest common dominator thing (and usually you cant script complete classes). I guess its fine for usual scripting tho.

I haven’t think about an option to reload scripts at play time but thats a good idea for prototyping which is what i want to do. I will have to rethink my proto game architecture to separate the static model from the dynamic model but i thibk it will be worth.

I’m using Javascript at the moment which is E4X enabled:
http://www.ecma-international.org/publications/standards/Ecma-357.htm
Nothing beats E4X when working with xml.

I’m remaking the spaceinvaders demo to work with javascript. I’m working with scripts controling each entity. I have scripts for Alien.js, Ship.js, VictoryScreen.js, PauseScreen.js,DefeatScreen.js,ShotScreen.js,GameMaster.js. Each script only has to provide these methods: void initialize(), void setup(), void cleanup(), void update(), void present(). Communication is made trough an hosted Javascript object called Game that forwards all calls from entities to the game master script that controls the game rules and decides what call should be satisfied and in what circunstances.

Some methods of the Game object:


Game g = Game.get();
g.setSpeed(this,100);
g.setDirection(this,angle);
b=g.canShot(this)
shotid=g.shot(this)
b=g.gotHit(this)
b=g.isDead(this)
t=g.getTime(this)
kc=g.getKeyPress(this)
mc=g.getMousePress(this)
x=g.getMouseX(this)
y=g.getMouseY(this)
sch=g.schedulle(this,wakeup_cond)
state=g.getEvent(this,sch)
...

Doesn’t sound too hard to learn except for the schedulle event part. But that is just a scheduller i can use to tell the game to call me back which i can check with a g.getEvent(this) once wakeup_cond has triggered (still working on this). Plus Javascript is not delaying the game in any noticeable way.