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.

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.

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.

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.

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.

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*

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:

Quote

-the turn over rate isnt that nice (compilation takes a while... on slower machines its 30seconds vs some msec)

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

Quote

-tools.jar is rather big (6.8mb vs less than 0.5mb for any scripting language)

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.

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

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 )

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<String> 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!

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

Also if you write over in eclipse, save, switch over, press reload... then there is no gurantee that eclipse is done with compiling.

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.

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.

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

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.

I know that ease of use and performance are important elements when choosing a language for implementing logic and artificial intelligent in games. There exist some nice feature rich scripting languages that are useful when focusing on these requirements. However, integrating a strong scripting language with full access to the java API into a game engine raises a few important questions. If the intention is to allow players to modify and adjust the scripts a strong scripting language can be misused and therefore be a potential security risk. Additional, a strong scripting language might use features of the java language like e.g. deprecated methods that can undermine stability of the game over time.

How do you guys deal with this issue? Or do you actually think it is worth taking into consideration when choosing a scripting language?

We need a way to edit object behavior in-game/game editor while the game is running.This has become the standard for level design, editing and development.

This can be done with Java but since Eclipse does it but it does require a compile step. With a script it is REAL easy to make work in-game (i.e. one reload script button or even a textarea for little snippet changes in the game editor GUI)

Also, the level designer doesn't have to have a Java dev suite installed and set-up (read configured with proper project paths etc). They just need the game itself. (and embedded editor like we do it :-))

[...]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.[....]

I use applet alike entry points (init, tick, render, destroy) and just script everything from that point. Its a full class which in turn can instanciate other (fully scripted) classes etc. If janino spits out some really weird error (happens sometimes), I just compile it the usual way and check what went wrong.

This approach works perfectly for prototypes or small games (and basically its the same as your approach, but the difference is that I get full speed and that I can do a usual compile at the end).

@benjamin

Well, there are different solutions for different problems. I'm for example not interested in letting other people fiddle around with my scripts (there wont be any at the end anyways). So its perfectly fine to ignore all possible security issues.

If you want that players can script stuff (and exchange scripts), you have to pick some scripting language with access control or restrict access through other means.

We did agent/ai scripting recently and I can say it was definitely not as easy as expected.

if you allow users to wirte AI scripts, one main challange is that they don't interfere with the running system. The easiest hack is to do huge computations, which will prevent the other from thinking, acting and further will break the rendering and animtion if the system is single threaded. Therefore we run every single agent in an own thread, which leads synchronzations issues with their perception and action tasks..

for most games however this won't ne needed, because the scripting is only used to simplify the development process, 'securing' isn't needed usually.

The hotswappable code in eclipse is not really suited for this. When you significantly change your code (add a method, field, etc) the hotswap fails.And when it is supposed to work, I quite often (twice a day..) get a VM crash after the hotswap.

It's much more convenient to have something that can be reloaded on the fly, and always works.

Last point would be that in Java (as in all OO languages) the boiler-plate code is quite big. It gets a bit annoying when doing lots of tiny scripts.

My own scripting-language just has some very trival shortcuts, that the parser turns into java-code, which is fed into the compiler inside tools.jar - for me it works out very well, you get 100% performance. And as all scripts are run server-side, I don't have to distribute tools.jar to everybody.To get aruond the massive tools.jar filesize, one could use Jikes, which is extremely fast, but AFAIK only does Java up to 1.4.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Thanks for the input. It really helped to broaden my knowledge of how to address the scripting issue.

After trying to use two different scripting languages: Groovy and Pnuts I realize that I was unable to speed up the development process of games. Of course, I am not a guru in these languages and I might improve with time. However, developing in java is not so slow anymore as it used to be. Tools like Eclipse really speed up the development process. Moreover, scripting languages like Groovy and Pnuts is based on the same syntax as java with only minor useful changes for gaming (you might disagree on this though). I am therefore questioning the benefit of using scripting languages in gaming if you have a nice game library/engine to support the development. Of course scripting languages are often considered because it is possible to see changes in real-time while developing. With the introduction of JSR 199 into java 1.6 this is now also something that is possible for the java language.

I still have an issue regarding the security and stability that I need to work out. Nevertheless, I will go with the traditional java approach for now.

I could have sworn that I mentioned this before on this thread but I can't see any evidence of it- Steve Yegge put together an interesting comparison of different JVM scripting languages where he wrote a simple but complete application with them. An interesting read.

I'm learning how to use this, so far it's amazing as to what it can do.Dynamic typing is awesome(I remember saying this before in a discussion about Ruby).No more need for things such as Vector2f. Instead "v = Vector2(0.0, 0.0)" or "v = Vector2(0.0f, 0.0f)".Closures are supported.Classpath modifications, so I can import my assignments and dynamically modify things from within my code to test it before it gets finalised.I'm wondering if this can output into bytecode for re-use.

I wonder if there is anything like this for C++. Interpreted C++ would be awesome to sort out bugs and really mess around with things.

Soon I will be loading in OpenGL libs (LWJGL) into my scripting to complete my second assignment for Computer Graphics, then write it into C++.Testing out algorithms on a scripting language saves heaps of time.I can't believe I only realised the usefulness of this just recently, I've read and been told millions of times before that scripting can save tremendous amounts of time but I've never personally realised it until I got myself a complex problem, scripted it and compared it to production code.

Debugging complex code is hard. Debugging scripted code is easy.Finalise the algorithm in the scripting stage and throw it into the fire after sorting it out.It takes very little time to go from A -> B, even if you're implementing a complex design.

-tools.jar is rather big (6.8mb vs less than 0.5mb for any scripting language)

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.

Also it is against the sun license to redistribute tools.jar..... just a head up for anyone that is doing it.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org