Hi,so I saw this talk recently that mentions how important scripting languages are in game development.http://www.infoq.com/presentations/Functional-Architecturefrom 7:30 to 19:20If I understand that guy correctly it is usually better to just write a game engine in a language like C++ or Java and then write the game logic in a scripting language. So I was wondering, does that really speed up the development process? And what kind of scripting language is best for games?And what about creating your own language/DSL? If you could design your own language what do you think the syntax should be like to simplify writing of games? Maybe a more descriptive language than a procedural one? For example you could describe all the locations and the properties of objects in the game with an XML based language. XML seems like a good choice because it's easy to parse.

Writing the game engine certainly doesn't speed up the process, but the scripts certainly do. When picking a scripting language, you want one that will integrate well with your engine, be as flexible as it needs to be for the job, and not eat up too many resources. Lua is popular for this reason. If you're working alone, you can pretty much stop there, but another factor is how quickly the others on your team will pick up that language.

XML is fine for encoding static object data, but do you really want to write programs in an AST encoded in XML? And if you could tolerate it, would anyone else?

I have a fair bit of experience with scripting languages. Here is what I have to say about it.

Quote

So I was wondering, does that really speed up the development process?

Well, not really. If you are talking about straight design. It is always quicker to write the entire development in hard-code than it is to use a scripting language. However, the one thing scripting languages do provide is flexibility. When designing large databases, it is cumbersome to deal with compiling code over and over again for logic errors. With a scripting language, you can skip all the problems with logic errors and handle them at run-time. The larger the project, the more beneficial scripting becomes.

Quote

And what kind of scripting language is best for games?

To be honest, I think Lua is very solid for gaming because of the sheer flexibility and ease of use. But, XML and JSON are also very strong candidates for designing a very easy to read scripting language. Mostly, you want scripting languages to be easy to read, and be flexible. (You don't really need AST to script with XML, just a good DOM parser would do the trick.)

Quote

And what about creating your own language/DSL?

I don't actually recommend this. It ends up taking a lot more time than it is worth and you end up bouncing back-and-forth between tools that have been tried and tested (like Lua), and your tool. In the long run, it would probably save more time to just use one of the available ones.

Quote

If you could design your own language what do you think the syntax should be like to simplify writing of games?

I am a big fan of tag based systems, like HTML and XML. When it comes to organizing game objects, it is very annoying to try to picture in your mind how objects interact. Tag based systems help me visualize what functionality is available for each object. It is very vital for game development for me.

Quote

Maybe a more descriptive language than a procedural one?

Nah, descriptive languages usually end up being very confusing. It is all about the procedure and getting things done as simple as possible. A scripting language is as close to assembly as human readable programming can get. It is very important that the language is fast and modular rather than descriptive and slow.

In conclusion, if you are building something small, then just code it straight out; No one needs a scripting language for Pong, Pac-man, or Tetris. However, if your game is larger than those it might save you some time to consider a good scripting language. It totally helps you fix logic errors a lot cleaner than you would if you had to recompile 1000 times.

Just a small correction: XML is not a language. It is a family of languages, or a meta-grammar for defining languages. Saying XML is good/bad for scripting games is like saying C notation is good/bad for scripting games.

XML is my field, but if I had to use a scripting language for a game I would use something friendlier to the writer - something using C syntax.

One of the great things about Age of Mythology was the script-based system for defining maps and AI players - using scripting for game assets opens up the game to a modding community.

Using interpreted Java as a scripting language for a compiled Java core has got to be weird. What you REALLY want to be using is my new PoppetScript language I am developing - declarative, with pluggable functions. It is a thing of beauty... will I ever get round to writing that game?

In my day job, we use Groovy as a scripting language around our Java core. That allows the use of Java objects directly within the script - maybe what you are looking for princec?

Offtopic: I've been wanting a plug-in/add-on system that uses a subset of Java as a DSL for a while now. If someone made a portable Java compiler that let you restrict what classes/packages a user could use and change the default package imports (like replacing java.lang.* with org.mygame.pluginsapi.*) that would be awesome.

Janino is a pretty good java compiler. No generics or annotations, but beyond that, it's very nice. I tried Groovy first - it wasn't a good experience, and the Eclipse plugin for it was lacking. I forget the details - it was a while ago - but basically, couldn't do the things I wanted to do. Mostly it was the poor IDE support, though. If auto-complete (or whatever you call what happens when you ctrl-space in Eclipse) doesn't work well, I'm pretty much done with it.

Now, I've got a setup where I'm writing the scripts in Eclipse, and Eclipse compiles everything (for compile-time error-checking, auto-complete, refactoring, etc), but the game doesn't use those class files and compiles them on startup with Janino instead. Using a custom ClassLoader (really, a thin wrapper) to filter out some undesired classes from being loaded, though reconsidering that - may switch to a SecurityManager instead, or just let go of the paranoia about letting scripts use java.io.

Having some stuff in scripts is useful for making the game mod-friendly. Other than that, I'm not sure why you'd bother. Unless, maybe, the core game took ages to compile, and you wanted to avoid that? Non-issue for Java, though.

Janino sounds interesting. What's the story behind not having Generics or other Java 1.5 features? Is it still being maintained? Other than that, it sounds great.

I haven't listened to the talk, but I will speak about scripting in games in general. Implementing game logic in another language seems like a bad idea. You will want something that makes it easy to write relatively low level code and is fast to execute. I would compile game logic with the rest of the game and, if it make sense, load some constants from a properties file (JSON or XML). Scripting won't make designing/programming the game any faster, but it might save time in creating and distributing extra content after you've done all that. In that case, the benefits are essentially the same as using a game specific map editor (whether it's available publicly or only internally). After your game engine/logic is reasonably polished you can start designing levels. Then a high level Domain Specific Language might be useful because it will save time by eliminating repetitive or complicated tasks.

There are a number of benefits. Saving time. Keeping content separate from the main code. Enabling non-developers to design content without assistance or knowledge of game internals. Potential for user generated content. The ability to deliver new content in bytecode or text format instead of requiring binary patches... But the benefits of using Java for 99% percent of your code means you would not want to start integrating scripting until the only thing slowing you down is hard coding levels or characteristics of new content. Then you might decide to invest time into something like a DSL or other tools.

If Java or something like it could be used as your "scripting" language, then I would definitely use that over something else.

I worked on a game in C++ which used Lua as the scripting layer and it sucked big time. The problem was that the main code called into script and script called into the main code and Visual Studio wouldn't debug over those boundaries. Hence debugging was very very frustrating.

Scripting, I suspect, is a solution which was born of the colossal inadequacies of C++. I really struggle to find a great reason for it to be used with a Java game. I suppose you could argue that having a DSL might make writing it a bit easier... but then we could argue about the merits of particular language syntaxes all day long as we know, and not get anywhere. The real killer is, as usual, the debugging.

WRT: Tools - yeah, that issue can't be overstated.WRT: C++ being poop. There is probably some truth to this, but I don't know if I'd go too far with that notion. DSL can be a godsend..they can also be over-engineering wankery.

Just look at how shit Lua is. Wilfully different lexical syntax to anything else, borrowing at random from other languages and styles of language. What fun. When you look at how hard it is to do anything safely in C++ you realise why people resort to this sort of horror. We are nice and cosy here in Java land.

C++ is awful, and Lua I find pretty awful as well and have never understood it's popularity. However consider, for instance, all the folks that insist on using a prototype based model (via component based). IHMO, there's a very high likelihood they'd be better off using Javascript for their entities as Javascript is getting a major overhaul in performance and interoperability. Let someone else do the hard work and use a syntax that is actually designed for what you're attempting to do. I should note that, as a guess, a very high percentage of DSL usage in games is leaning toward the over-engineering side.

Janino sounds interesting. What's the story behind not having Generics or other Java 1.5 features? Is it still being maintained? Other than that, it sounds great.

I use Janino for the live-coding functionality in Praxis (video here). This sort of thing could be great for game modders - imagine modding the class files of a game while it's running! A major benefit is that the code will be just as fast as any other code in your game, so you can do things you might not be able to do otherwise (I realise JIT compiling of scripting languages is getting better, tho I assume not for DSL's! ).

There have been some updates to Janino recently, primarily to allow use of javax.tools / javac as a compiler (Janino is far more than just a compiler, it's also the infrastructure such as classloaders, expression wrappers, etc.). Unfortunately, I don't see the inbuilt compiler getting Java 1.5+ features, which means no generics / enhanced for loops, and no lambdas (which will be great for live coding); and I'd rather not get into shipping a full JDK or relying on all users having it installed. Therefore I'm currently looking at the options for shipping a minimal javax.tools / javac solution - any links very much appreciated!

Incidentally, I'm not averse to DSL's. Praxis has one for interacting with its specialised actor model (multiple layers of continuation-passing in Java is not fun!). They're useful if nothing else provides what you need!

C++ is awful, and Lua I find pretty awful as well and have never understood it's popularity.

It's small, fast, and integrates well with native code, and at the time there weren't a lot of alternatives. Still not that many that satisfy all three. It's certainly not an ideal fit for Java codebases. I'd probably go with javascript just because of all the people out there that know it, plus Nashorn in JDK8 is supposed to be pretty fast. If I need something faster, compiled code in OSGi modules.

Indeed - legions of C++ programmers from the games industry who were desperate for anything, just anything to get them out of the hell of doing recompiles jumped on the first thing that wasn't utterly utterly abysmal. The poor things don't know any better. (If they did they'd have been using Java in the first place, hey ho)

There have been some updates to Janino recently, primarily to allow use of javax.tools / javac as a compiler (Janino is far more than just a compiler, it's also the infrastructure such as classloaders, expression wrappers, etc.). Unfortunately, I don't see the inbuilt compiler getting Java 1.5+ features, which means no generics / enhanced for loops, and no lambdas (which will be great for live coding);

You could also use clojure as a scripting language. Clojure compiles source code to bytecode on the fly just like janino, but it has lambdas.

I want one where i can do autocomplete one the netbeans framework and setup some 'special' global objects filled in from the larger program. Guess Janino would work except for the lack of generics (one of the 'special' objects would be a map).

Currently thinking of groovy too. The idea of the program is not some general thing, just some 'unit of code' that are executed unconditionally if the selected thing is selected, so having the declare classes and stuff like that would only be harmful.

There have been some updates to Janino recently, primarily to allow use of javax.tools / javac as a compiler (Janino is far more than just a compiler, it's also the infrastructure such as classloaders, expression wrappers, etc.). Unfortunately, I don't see the inbuilt compiler getting Java 1.5+ features, which means no generics / enhanced for loops, and no lambdas (which will be great for live coding);

You could also use clojure as a scripting language. Clojure compiles source code to bytecode on the fly just like janino, but it has lambdas.

clojure and janino are definitely aimed at two very different use cases. While even idiomatic clojure can be fast, it depends on which idioms you use and which you avoid. Even then there's a runtime library dependency, difficulties in calling back in to clojure code, and finally there's the small matter of the source language being completely different ...

Janino can run on just a JRE, but if you already have a whole JDK, you can just as easily use javac itself through the tools interface. And I don't think it all that unreasonable to require anyone using the script development features of your app to have a full blown JDK.

One of the awesome things about Java is not just that you can dynamically load stuff using classloaders and thus partition mods, but that you can just plonk a jar or three in front of the class path and actually override existing behaviour (especially cool if you give away the source in the first place!) Then anyone with a JDK can basically tweak your game to their hearts content without actually having to do a full build.

And I don't think it all that unreasonable to require anyone using the script development features of your app to have a full blown JDK.

Unfortunately, that's the one thing I'm wary of doing - this wouldn't just affect people using the script development feature, but then anyone who used the projects with custom scripts, including when they're distributed as standalone apps. They're always compiled on the fly.

If you allow people to edit scripts or use custom ones, then yeah, they're using the script development features. My take is if you're using Java as a source language, you're probably dealing with java devs anyway. Otherwise you should really use a DSL that's more appropriate for the domain.

I'm told Groovy is really quite fast these days, or at least can be made to be if you use static types.

My take is if you're using Java as a source language, you're probably dealing with java devs anyway.

Without wanting to hijack this thread too much more ...

In Praxis LIVE you can create a project with custom scripts. You can then distribute that project as a standalone executable to people who aren't Java devs - the scripts will still be compiled on the fly, but I think it's unreasonable to expect all the recipients to have a JDK installed. Of course, I could have projects include the compiled bytecode too, but there are other reasons not to.

It could be the same with game mods - there's something nice about allowing mods to be distributed but enforcing that's done in source format.

And while I appreciate your point about DSL's, the other options do mean you lose speed! Unless you wrote one that compiled to Java source and you then compiled that on the fly, but that's going around in circles now!

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