Which script-engine for a full game?

[Preston]

Which script-system would you use/recommend for your full game? (Mainly for your AI, but not only.)

Say, you would consider these three options:
a) the game is pure Java.
b) the game is "Dirty Java": some parts of your game are in C++, some in Java, some in Xzy.
c) the game is pure C++.

Would Java fit well as script engine? (Like they used it in the Vampire game; please see list below...)
Did you ever run the funny Robocode game? Isn't that a kind of nice "scripts" (actually small but real Java programs) which can be loaded, compiled and run during the game?

What would be the pros of some other script languages, like Python, LUA, or ... ?
(One disadvantage of them, compared to Java, is: they're - much - slower.)

--

A list of some "Dirty Java" games, several of them using Java as script engine.
(Quoted from a danish Java Games report some years ago. Let's forget its benchmarks for a moment :-)

° Probably the best example of Java in games is the highly acclaimed game Vampire -The Masquerade: Redemption (2000) from Nihilistic software. This game uses Java JDK 1.1 as its scripting engine. The rest is written in C++. This game runs with very high performance, has excellent graphics and gotten fine reviews. According to [Huebner], Nihilistic Software was very satisfied with the use of Java.

[Huebner] Huebner, R.: Postmortem of Nihilistic Software?s Vampire: The Masquerade ? Redemption. Game Developer Magazine. July 2000. Also available online at Gamasutra: http://www.gamasutra.com/features/20000802/huebner_01.htm

° IL-2 Sturmovik (2001) by Maddox Games: Uses dirty Java by mixing Java with C++, such that logic and part of the game engine is in Java but all the graphics are in C++. This game has gotten very good reviews.

° Worthy of note in this category is Who wants to be a Millionaire (2000) developed by Jellyvison and based on the popular TV-show of the same name. It topped the game sales charts for months. Here the game logic was written in Java and the rest in C++.

° Of other commercial games using putting the game logic in Java and the rest in C++ can be mentioned You don't know Jack (1995) by Jellyvision and Majestic (2001) by Electronic Arts.

° The Sega Dreamcast games Skies of Arcadia (2000) and Daytona USA (2001) both by Sega includes a Java virtual machine. Especially Skies of Arcadia got fine reviews.

° Starwars Galaxies uses a Java script engine?

° Chrome (2003) {edit}

[abies]

Another game using java as scripting language is Chrome (http://www.chromethegame.com, 3D FPS similar to UT). Their java code is totally ugly, but it works.

I would certainly advise against creating your own language+runtime from the scratch. There is a possibility of creating your own language and running it on jvm - this way you will have solid runtime and need to play only with compiler.

Big question is how much customizability you want to expose for end user. For example, in NWN Bioware has created system where everybody and their dog were supposed to be writing scripts for modules. They have decided to stick to most basic C subset (no pointers etc) for scripting language and it still was too high bar for majority of people. Bioware ended with creating 'wizards' which would take few inputs and generate code for you. I hope you do not plan to target same audience - in such case, ONLY thing which is important is ease of use for non-programmers (which is impossible anyway, because if you are non-programmer, you cannot think in algorithms, regardless of how easy language is).

For mod community (like UT/Quake), you can basically use anything - they will even learn assembly if it is needed

I think that you know most pro-java  arguments yourself. I would like to point my personal worries, why it is NOT so perfect for gaming scripting language (in no particular order):

1) It is overly verbose as far as standard library is concerned. While it helps in big system programming, in scripts you may prefer function points per line rather than fully self-documenting readable code.

2) It requires a lot of context to do anything. Helper methods, setters, constructors, a lot of writing to get simpliest things done. Please look at http://www-users.cs.york.ac.uk/~susan/joke/foot.htm Java entry to see what I mean here. Again, for enterprise-level, extensible systems it is beneficial, for game scripts it can be tedious.

3) For mixed language engine it is non-perfect. You need to non-OO at languages boundary to use JNI - you will need either to mirror most of data to java (which will cause synchronization problems and memory bloat) or ask for everything through non-OO interface which means you can as well use any procedural language.

4) Java is designed to be very generic. Maybe for your game, some other progamming paradigm would be more useful ? Best example for me is Stackless Python used in Eve Online. With very light threads/continuations, they just run separate program for every object in world, being able to write code which just pauses for a moment if needed - not acceptable in shared thread environment (doing it with java/C threads is not possible due to amount of stack memory needed per thread/OS limits).

5) Rapid prototyping isn't really a java strength. You can try to do tricks with class reloading, but migrating state can be hard or impossible. Language/environment in which you could edit script while game is live and see effects at very instance can be a major productivity gain.

1,2 and 5 can be solved by using some kind of other language built on top of jvm. Maybe beanshell (http://www.beanshell.org/) ? It is opensource and with a bit of tailoring you should be able to add few tricks for it (like prototyping new behaviour on single instance of object). For routines which will turn out of be performance hogs, you can always port them to java and call from beanshell (which should be mostly trivial).

3 is not a problem if you will write game in pure java. For mixed language, interfacing will be always a problem - but AFAIK, some other languages have more explicit constructs for overcoming the barrier.

4 - Stackless Python rulez I'm a bit afraid about performance of heavy code (like pathfinding/AI), but for object behaviour it seems like a really reasonable solution.

To reassume: If you will decide on core engine in java, use jvm to run scripting language - I would propose beanshell (second choice would be JPython) plus java helper classes, all of it having access to internal engine classes if needed. If you want to have engine in C++, consider Stackless Python. C++ and jvm as scripting engine - be prepared to see that your java code will be just C (not C++) as far as programming style is concerned.

IMHO, AFAIK, my 0.02$ and all other disclaimers follow...

[Preston]

Thanks for that comprehensive answer.
This Javagaming forum is really nice with many people with good knowledge, ideas and friendly feedback.

I'm going to consider what you said with my "script engine" (mini-) research. I'll be back in a few years (just kidding).

Btw basically the scripts won't be used for pathfinding, but your mentioned "object behaviour". Also no "mod community". ;-)  However some "no real programmers" will probably have to be able to modify some scripts.



PS: "Chrome" - thanks for the hint; I've edited the list.

Games published by our own members! Check 'em out!

[Preston]

Say, you would consider these three options:
a) the game is pure Java.
b) the game is "Dirty Java": some parts of your game are in C++, some in Java, some in Xzy.
c) the game is pure C++.

Oops, I did forget option
d) the game should be portable to Consoles.

Which means the scripting language should be portable to, say, PS2, too, for option d). Would this apply to Python, LUA, ..?
OK, later on I'll continue to dig on www.pyhton.org and www.lua.org and Gamasutra maybe.

[DaveLloyd]

Whilst I appreciate the arguments away from Java, I'd still vote for Beanshell if you're using Java anywhere in your project. Beans are a good way of encapsulating game objects - particularly for persistence. The Beanshell is that bit easier than real Java and should be very easy to experiment with. But the real win is introspection - no need to keep the script engine up to date with the game engine internals - so when you try to bolt on a big bit of AI like a Rete rules engine (e.g., http://www.drools.org) or a neural net engine, it's just there and works.

Games are a prime target for component-orientated programming which is why Java is the natural choice IMHO.

[Jeff]

So my two cents...

Another game using java as scripting language is Chrome (http://www.chromethegame.com, 3D FPS similar to UT). Their java code is totally ugly, but it works.

I thought the Chrome guys told me that was pure Java ontop of their own OGL bindings, actually.

1) It is overly verbose as far as standard library is concerned. While it helps in big system programming, in scripts you may prefer function points per line rather than fully self-documenting readable code.

I'd disagree but then again I always thought verbosity was a BAD argument.  Verbosity  == readablility which IMO is always good.

I'm a Wirthian, not a Ritchien.

2) It requires a lot of context to do anything. Helper methods, setters, constructors, a lot of writing to get simpliest things done.

Id say thsi is directly related to how much of that work your evnironment and the obejct your provide to program it off-load.

Your choide as a game developer how much hand holding/restriction you want for the mod developer.

3) For mixed language engine it is non-perfect. You need to non-OO at languages boundary to use JNI - you will need either to mirror most of data to java (which will cause synchronization problems and memory bloat) or ask for everything through non-OO interface which means you can as well use any procedural language.

Dont quite follow you here. Whats wrong with native byet buffers for communicating with native-level code??

4) Java is designed to be very generic. Maybe for your game, some other progamming paradigm would be more useful ? Best example for me is Stackless Python used in Eve Online. With very light threads/continuations, they just run separate program for every object in world, being able to write code which just pauses for a moment if needed - not acceptable in shared thread environment (doing it with java/C threads is not possible due to amount of stack memory needed per thread/OS limits).

Hmm why cant you pool threads?

5) Rapid prototyping isn't really a java strength. You can try to do tricks with class reloading, but migrating state can be hard or impossible.

I havent foudn it so.  just the oppsotie.  Al lthats necessary is to over-ride the SerializationUID.

Language/environment in which you could edi
t script while game is live and see effects at very instance can be a major productivity gain.

Well then use IBM's VisualAge for java

just my 2 cents

JK

[princec]

Lua is looking to be one of the very best scripting languages for games. It's not Java though. But what you ideally want is a Lua execution engine written in Java.

PomPom used Lua to great effect in Mutant Storm. Lua takes care of the game mechanics; the game "engine" is a C++ renderer which Lua simply controls. It certainly seems fast enough.

Cas

[abies]

Dont quite follow you here. Whats wrong with native byet buffers for communicating with native-level code??

If your underlaying C++ code is object oriented, you still need to create interface in non-OO way. Either you will create mirror hierarchy of most objects in java, or you will need to call purely static methods to communicate with C++ without exposing object nature of native classes. Some kind of more-C++ aware binding could for example extend C++ classes, or at least be able to call their methods (with virtual methods resolved correctly etc.)

Maybe I'm not very clear here - so let's look at simple examples. OpenGL is non-OO and creating java binding for it is simple - just expose all functions, one-to-one. Now imagine that you have to expose bindings to STL container/iterator classes - without rewriting it to java. You will probably end up with some kind of totally ugly construct, having nothing in common with neither STL and java style of coding.

Hmm why cant you pool threads?

You cannot stop a thread in middle of method and reuse it for different code. I cannot just write Thread.sleep(5000) and hope that this thread will be reused, but after 5000ms code will continue with same local variables/stack/etc.

[nonnus29]

I'm curious how exactly you would go about using Java for scripting a Java game.  Anyone care to give a quick example?

To me the epitomy of game scripting is the unreal sdk and unreal script - a full on oop language with game specific features.  To my knowledge Beanshell is not oop at this time (unless a new release has come out since I checked?).  JLua's api seems quiet cryptic plus jlua implements Lua 4 which lacks the 'oop' enhancements of Lua 5 (oop in lua 5 still seems very forced, not natural or intuitive at all, at least in my opinon).  Jython I have not tried.

I've been using rhino to write what I think of as 'general purpose javascript game console' that will give the user the features of an old 16  bit console, like 3 layer tilemaps, x number of sprites, 6 buttons of input etc....  Its alot of fun.  You can also access you java classes with rhino thru its 'live connect' feature.

[abies]

Beanshell is OO - you can create real classes in Beanshell 2.0. Anyway, IMHO, it is not so important for script language to be OO itself - just the fact that it interfaces to OO code in reasonable manner.

Just remember that if you use Beanshell, you either need to fully trust script writer, or create nice sandbox - Beanshell is powerful enough to call System.exec("rm -rf /");