Hi,
so I saw this talk recently that mentions how important scripting languages are in game development.
from 7:30 to 19:20
If 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?
[/quote]
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?
[/quote]
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?
[/quote]
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?
[/quote]
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?
[/quote]
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.
Were I to start using scripting I’d use something that basically interpreted ordinary Java.
Haven’t exactly found a need to use one yet though 
Cas
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?
Nah, I’ll just use plain old Java I think Half the time I can just tweak whatever it is I’m working on in the debugger anyway.
Cas
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 is pretty nice. The main point of a DSL is to be application specific, so there are any number of reasons to use one. Notable, easier to use for scripter and/or higher level functionality.
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.
Cas
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.
Cas
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.
(EDIT: type-o)
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! ;D ).
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!
I have also used Janino and it worked great. It was for an L-system.
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.
For the record: I disagree with first two of these points at any point in time. Seriously I think that the fad-factor is/was its biggest draw.