Scripting help /guidance wanted

Hi,

I’m trying to plan out a game. I was thinking that the scenarios might be better set up with XML and/or Scripting. Then I was looking at all these different languages Lua, ruby… why learn something else? I read this article where this company actually uses Java itself for its scripting language.

http://www.gamasutra.com/view/feature/3147/nihilistic_softwares_vampire_the_.php?print=1

[quote]3. Using Java as a scripting engine.
We knew from the start that allowing the user community to edit the game was an important part of the design. After working in the first-person action-game market, we saw the benefits of supporting the user community and wanted to carry this idea over into role-playing games, where it is not the norm. A built-in scripting system makes a game engine much more extendable by fans. In Jedi Knight, we created our own customized game language called COG. Creating COG took a lot of effort from the development team; several months of work went into creating the compiler, testing the generated code, and implementing the run-time kernel used to execute the scripts. The end result was worth it, but it cost a lot in terms of time and resources to pull it off (for more about COG, see my article, “Adding Languages to Game Engines,” September 1997).
The ambitious design included parties of up to four 3D characters, each with interchangeable weapons and armor.

When starting Vampire, we looked for ways to incorporate a scripting engine more easily than creating our own from scratch yet again. There were several scripting systems we examined and tested. At about that time, another game development company, Rebel Boat Rocker software, was getting a lot of attention for its use of Java technology. After exchanging a few e-mails with lead programmer Billy Zelsnak, we decided to give Java a try. Up to this point I knew very little of Java, and had largely dismissed it as a language suitable only for making icons dance on a web page and the like.
A set of four interactive 3D head models at the bottom of the screen are skinned and animated in real time to give lifelike status for each party member.

After a crash course in Java, we did a few simple tests incorporating it into our game engine. It passed each one with flying colors. In a matter of a few weeks, we had solved the major challenges involved in interfacing a standard, freely distributable Java virtual machine to our 3D RPG engine. From that point on, the only maintenance required was to add new native functions to the scripting language, which we did whenever we added new engine functionality that we wanted exposed to the script writers. We also trained several designers in the use of the scripting language, and they started creating the hundreds of small scripts that would eventually drive the storyline of the game.

Ever since those initial tests, I kept waiting for the other shoe to drop, so to speak. I expected to come to work one day and find out that the Java thread was chewing up 100MB of RAM or eating 50 percent of the CPU time, but amazingly, the system was trouble-free throughout development and never became a significant resource drain. If for some reason we had hit a dead end with the Java system late in the project, it would have easily taken three to four months to get back on track using a different scripting technology. In the end, the gamble paid off. We saved months of programmer time that would have otherwise been devoted to creating a scripting environment, and the result was a system significantly more efficient and robust than any we could have created ourselves.
[/quote]
Okay so a couple of questions (not easy)

  1. How would one set something like this up? Seems like a cool idea. Is this doable with Java using java as the scripting language?

  2. Does anyone have any code links for medium complexity scripting engine tied to a scripting language? I want to set up things like variables, graphic positions, timers, dialog, and events. Perhaps AI.

Any help or direction would be appreciated.

Darrin

IMHO: XML is a solution searching for a problem. It’s fine as an interchange format, but see no real reason to use it otherwise.

As for using Java as a scripting language, there are a couple of basic questions that jump out. What language is the base game going to be written in? What features do you need from your scripting language? How is it going to interface with the “base engine”? And what runtime are you going to use?

Whatever solution you decide on, I’d strongly suggest using an embedded VM. This is so you don’t need to deal with ensuring that end-user has a specific “external” runtime installed and to deal with issues of various versions from (potentially) various vendors.

Personally I don’t think I’d use Java if the base language was C/C++. I’d probably embed V8 (JavaScript). A big issue here is that I don’t know of a usable Java VM for embedding.

However if the engine was written in Java, I probably would use Java as well for scripting. I’d use some “glue” code with Janino (mainly a custom ClassLoader structure for loading/unloading of scripts). If used for AI, I’d probably modify Janino to support continuations in a similar manner to Kilim.

A nice thing about using java for your game that requires scripting is that java has support for it built-in. Google for javax.scripting or BSF.
Personally I’ve only used BSF so far but the built-in javax.scripting is basically a formalised continuation of BSF as part of the java runtime.

The cool thing about it is that you can interface your game engine to BSF (or javax.scripting) and you’re free to use any scripting language that supports BSF/javax.scripting.
You can then choose to use, say, javascript, but some modder might think that Groovy or Rexx or Ruby or whatever is waaay better. He can then just add the scripting engine .jar to the classpath and he can just code away in the language of choice.

In regards to your original idea, yes there is nothing to stop you using Java as your scripting language. I’m pretty certain (as certain as I can be without having done it myself) that the Java compiler is available as a Java library, so you can just call it from an app. Once it’s outputted code you can then load this using a class loader.

This has lots of advantages in that you can have the same code loaded multiple times (thanks to class loaders) and do lots of other tricks you might find useful. However the down side is that you need to work with class loaders, which are one of the more complex libraries that Java comes with.

In regards to XML, personally I’d recommend JSON instead. Much nicer to read, edit, takes up less space and if you use JavaScript then it is trivial to generate (as you can put your data into a JS object and then JSON it). I’m sure there must be a JSON library out there to use with Java.

In regards to scripting languages; BeanShell is your best solution. It parses Java and was designed to be a small embedded scripting language. It also supports some language extensions allowing you to write more dynamic Java-like script (so you have that option).

Another easy option would be to use Rhino, Mozillas implementation of JavaScript written in Java. The plus here is that it comes bundled with Java 6. Although by modern JavaScript standards it’ll be quite slow and I’d personally recommend BeanShell instead. This is also a good option if you chose JSON instead of XML for some of your config stuff (as JSON is JavaScript).

As nice as it is I would avoid JRuby; as well as Groovy, Jython and the idea of using a ‘proper’ language (or at least put them to the bottom of the list). The main reason is because they were built as implementations of those languages on Java rather then as embeddable languages. They might be trivial to incorperate, or you might hit some snags and issues as a result of this. Either way they will be quite bulky (at least several megabytes) so bear this in mind if your planning to deploy as an applet or via Java WebStart.

That said, Ruby is one of my all time favourite languages. Whatever you pick make sure it’s mature and in use by several projects already to help avoid the likely hood of running into implementation bugs (which JRuby mostly is today).

I hope that helps!

Wow now that is a really old article, alot has changed since then.

If you want fast scripting with java go for Janino

I am also interested in picking good script languages.

Beanshell looks very good but hasn’t been updated since 2005. The examples on the webpage still works though, but I am a bit concerned about it anyway.

I use Rhino and Janino at the moment and it works very well. Janino is very fast compared to Rhino but requires signing if you want to use it in an applet.

The same is true about Rhino, which you recommended. ::slight_smile:

Rhino is included with Java 6, so no it doesn’t add several megabytes. It’s also my impression it’s aimed more at scripting then the other languages I mentioned.

Thank you for the replies.

The app will be in Java / LWJGL. It is a bit more complicated than I thought. Is anything easy in game programing? At this point, I think I’m going to write a couple of scenarios is Java, then see how I can extract them to something like Janino. I think I need to get more design and engine done before I try to separate out the campaigns into a full blown scripting language. It would probably be better to plan it out first but I don’t think I’m ready.

I’m also wonder what functions and commands etc should be limited for a single player game if any? I guess you set up an API for the script to you. Does anyone have code links to show how someone integrated a scripting language with java?

Here’s a really minimal example using java6’s built-in javax.scripting.
It shows how a script can interact with java objects and call methods on them in a remotely gaming engine context.
Maybe that helps…


import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;

public class Main {

    ScriptEngineManager manager = new ScriptEngineManager();
    ScriptEngine engine = manager.getEngineByName("JavaScript");

    // better to load this from a file, but we hard-code it for now
    // This script moves our actor one position, and every 10 positions it will
    // shoot
    static final String UPDATE_SCRIPT = "actor.x += 1; if (actor.x % 10 == 0) { actor.shoot() }";

    Actor actor = new Actor();

    /**
     * @param args
     */
    public static void main(String[] args) {

        new Main().run();

    }

    private void run() {
        // put a reference to our actor in the scripting engine
        engine.put("actor", actor);

        // our main game-loop
        while (true) {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException ignored) {
            }

            try {
                engine.eval(UPDATE_SCRIPT);
            } catch (ScriptException e) {
                e.printStackTrace();
            }

            System.out.println("Our actor is now at " + actor.x);
        }

    }

    public class Actor {
        // actor's position
        public int x;

        public void shoot() {
            System.out.println("ACTOR: Pow pow!");
        }
    }
}

EDIT: some more examples are here, if you want to get more fancy about it: http://download.oracle.com/javase/6/docs/technotes/guides/scripting/programmer_guide/index.html
For example, you might want to look at ‘Invocable’ to add some more scripting functionality besides just calling a script every update.

Rhino has the same type system mismatch as Jython, etc.

Unless you really want to use a different programming paradigm, I don’t see a strong reason to use javax.scripting. Using janino is same amount of work, you’re not requiring a new VM for end-users and you’re taking advantage of the JIT.

I don’t know enough about applets to comment on these issues. However if you want JIT’d code that’s unloadable, you have to be using (directly or indirectly) multiple classloaders.

Some more “pros” of using janino is that you can “defer” your scripting related work since you’re just programming in Java. One can start by simply having all “scripts” statically compiled with the rest of the engine. This gives you the chance to work out all the details of how scripts will interface with the base engine and not to worry about bugs in your loading/unloading source base.

But, like I was indirectly saying in my first post:

Q: What scripting language should I use?
A: It depends.

Yeah I think this is bigger than I think it is. I’m sure there is going to be feature creep and some major scenario changes. This would probably be good work out first and lock down before going to a scripting implementation.