What scripting language do you use in your games?
I was thinking to use BeanShell as it seems to fit in nicely with Java. The interpreter is also quite small (140kb). Anyone used it? Anyone got experiences of Jython?
Thanks.
I know the search on this board sucks, but do a search for “beanshell” and set it to 300 days and you will find several threads.
Q: Would this be better in the tools category?
I like rhino/javascript. If you compile it to the ‘small footprint’ version it comes in at about 200k. Rhino is very simple to use, you can embed it in your game/app with very little code. My understanding is that jython or beanshell would be just as easy to embed.
One reason I like rhino is the fact that javascript is well known to any possible end user.
Well…I don’t know Javascript, but I do know Java (hence beanshell).
Although, since I know LotusScript, automatically I know 90% of javascript, vbscript, etc ;D. And I hate the name (I still can’t believe they got away with doing that!)
Gregory Pierce has some really interesting stuff on scripting languages for Java. Look for his shootout whitepaper :
I’ve used BeanShell in a couple of projects. It’s quite nice, except for performance: it’s extensive use of reflection to access Java classes ends up creating a lot of small objects (eg. every call must create an object[] to pass the parameters). This causes the GC to kick in too frequently for any chance at realtime performance (if you call a script every frame, anyway). This was under 1.4, so maybe 1.5 has some upgrades that can handle this better, haven’t checked.
One other language I looked into (but didn’t get a chance to use in practice), was DynamicJava. It has many (though not all) of BeanShells language features, but compiles down to bytecodes, so it’s fairly optimal performance-wise. The project seems inactive now (last update was mid-2002), but it appeared stable an feature complete. Plus the source looked fairly clean, so hacking it shouldn’t be too scary. Interpreter is a big bigger (~450k).
Snacks for thought.
[quote]Gregory Pierce has some really interesting stuff on scripting languages for Java. Look for his shootout whitepaper :
http://www.jroller.com/page/gregorypierce
[/quote]
I noticed gp kicked rhino from the shoot out; I’m not sure if the last part of the test suite is really a scripting language job? Sounds like more of a low level fundamental behavior that should be handled by the game engine, imo;
[quote]* Ultra combo - will test all of these in a real world scenario based on a 3D object moving through 3D space and checking to see if it collides with anything as it passes through that space, the result being the maximum frames per second a rendering engine would be able to render a scene if it depended on the scripting engine for that logic operation
[/quote]
The link to the paper didn’t work for me.
Thanks for all replies, I guess I’ll be trying Pnuts first, instead of BeanShell.
[quote]What scripting language do you use in your games?
[/quote]
That’s an easy one: Java
Why would I introduce an interpreted language on top of an already interpreted language?
Before everyone comes along and starts flaming Bob that Java’s interpreted don’t bother, we know what he means 
The question is: why are people feeling a need to resort to scripting languages at all? What is it about the syntax of Java that just makes it no good for getting stuff to work?
I’d also like to ask, is it legal to ship Jikes with a game? Which basically would amount to a the most powerful scripting language on the planet as it’s the entire Java language and SDK at your disposal…
Yes, you can ship Jikes (http://www.research.ibm.com/jikes/license/license3.htm) - so you really do have the most powerful scripting language ever devised…
Now, if only Java’s syntax wasn’t so bloody awful.
Cas
[quote]Before everyone comes along and starts flaming Bob that Java’s interpreted don’t bother, we know what he means
[/quote]
Even some of Sun’s documentation says its interpreted (without qualification).
I believe you can ship javac from the Sun JDK too.
Assuming you’re not trolling…
No systems language is ever good at being a scripting language. They are two different tools for two mutually exclusive purposes.
You cannot have a language which simultaneously does everything of a systems lang and a scripting lang - either it’s very quick and easy to use, and does little or no checking and enforcement, or it mandates correctness prior to runtime, and enforces it, and sacrifices ease-of-use for runtime efficiency. There are all sorts of interesting compromises/trade-offs, and in some areas you can increase everything at once, but in general you cannot reconcile fundamentally opposing aims.
NB: my definitions of scripting and systems languages are to follow the spirit of the original uses, not to slavishly re-use definitions that are meaningless in the world of the PC.
Java is not a scripting language. It’s a poor fit in most places where a scripting language is called for (leaving aside the many exceptions). IMHO it’s also “incomplete” as a systems language due to a few omissions such as structs (although in the original definitions structs are really a scripting language feature) which are invaluable for a modern systems language.
Well, that brings me full circle on the whole languages debate. What is the point of writing anything in Java when a scripting language lets me get stuff done without checking errors etc.? Or conversely what is the point of using scripting languages when they’re so prone to error and have such poor performance?
The only reason I can think of for scripting languages existing is that you can actually dynamically load and compile from proper source code at runtime.
I just don’t seem to get it otherwise.
Cas
[quote]Well, that brings me full circle on the whole languages debate. What is the point of writing anything in Java when a scripting language lets me get stuff done without checking errors etc.?
[/quote]
(recalls that it was Cas who said he tended not to use Exceptions properly…)
In general, this is exactly the right question to ask (see my last comment below).
If you want to code poorly (i.e. write code that will be fragile - but will generally be MUCH quicker to write first time), then java is not the best choice. In particular, if you will never need to maintain your code (very rare) or won’t be affected if it’s hard or expensive to maintain (much more common!), and if you’re the only person working on it - then a scripting language is generally much better for coding than java.
e.g. Never use J2EE to do a site that meets the above criteria because you’ll be able to achieve exactly the same site in 1/3 the time using PHP4.
Scripting languages don’t necessarily have poor performance. This has been one of their marketing problems - a few famous ones are utterly dismal, performance-wise, usually due to being originally an academic project (speed is irrelevant) or written by naive inexperienced programmers (terrible code and design).
Ironically, the earliest scripting languages (on mainframes) were often fast or very fast :).
IBM (and others) did many studies over the last third of the 20th century on programmer efficiency in different languages. One of the results was that the number of KLOC (thousands of lines of code) each programmer specified, coded, tested, debugged, and deployed in unit time (usually measured per year, IIRC) was approximately constant independent of language used.
(another result was that different programmers’ KLOC counts varied by a factor of up to 40, IIRC?)
So, really, the question ever since has been “Why the heck should you ever program in a system language?”.
What this then comes down to is looking at the benefits of a system language on a case-by-case basis and deciding if you really need them. Most of the benefits are to do with long-term savings - reduced optimization effort, reduced maintenance, etc - BUT there are also long-term increased costs with systems langs, the biggest one these days often being refactoring: it’s generally much more expensive to refactor systems code compared to the equivalent scripting code (and in the latter case it’s less often necessary, simply because the code itself is looser to start with).
Now, why would I want to write code that doesn’t work though, and that I wouldn’t find out about it not working until it broke, just because I spelled something wrong in it? It just doesn’t make sense not to have a compiler check it for you beforehand.
Cas
A trivial example is complex calculations.
e.g. if you want a script that does the equivalent of one of Excel’s built-in advanced functions (e.g. the interest-calculators that require about 8 parameters).
Type-checking will save you nothing here - the only way the result will be right or wrong is if you typed the equation correctly or not (assuming you don’t accidentally insert a letter in the middle of a number or something equally moronic).
Exactly - you could type the equation in wrongly such that it was a syntax error. A scripting language won’t detect it until runtime. Perhaps it only gets run 2/3rds of the way through the game in an obscure circumstance. This is why we developed compilers!
I still don’t get it. Keep talking!
Cas
Using a jump-n-run game example like super mario bros you might have the following type of different platforms:
platforms that you can jump thru from the bottom
platforms you can’t jump thru
stationary platforms
moving platform that follows a simple path
moving platform that follows a complex path
platform that desintegrates when you stand on it x seconds
platform that make you bounce really high
platform that moves you like a conveyer belt
platform that is a transition to another part of the level
platform with a switch that can follow different paths
So too code a level in java you could parse a level file and use a singleton platform factory getPlatform() with potentially ALOT of arguments. In your project you would have ALOT of files that subclass simplePlatform. And if you wanted to mix and match behaviors that would mean even more files?
Is there another way to do this in java?
With a scripting language you could concievable describe each behavior with a script so long as the versatility is built into a base object or platform class.
I think I prefer the latter, although I haven’t done it yet…
All those examples are too low level (and very important to gameplay, so they should deserve special attention) to be considered for scripting in some way.
Scripting should (IMHO) be really high level stuff, probably specific to a single encounter in a level, a special weapon or behaviour etc. For a platformer it might be cut screens mid-level, or set pieces. Or perhaps for an unusual character like a co-op NPC. In short, scripts should be so easy to make (and debug!) you can let a level designer go nuts and make up loads of new ones for every single level.
I’d plug V-Script here, but at the moment the most complex thing you can script is a button that turns on and off a light… :-[
Well, it’s good that I can still start a debate rolling! 
The current track seems to be questioning the actual semantics and expressivity (sp?) of a particular language. This is currently a hot topic all over the programming world. If you’re an OOPSLA watcher, you’ve seen all of the hoopla on domain specific languages (DSL’s) where one definition of DSL is:
… a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain.
(taken from http://homepages.cwi.nl/~arie/papers/dslbib/)
I’ll just cut to the chase: I use an appropriate DSL (which is sometimes custom for an application) that I either compile directly into Java byte code or first translate into Java and then compile.
Rob