A coupla quick followups:
[*]The literature is claiming that approximately half of current game development time is spent writing tools (so, no, writing a translator, for example, is not out of scope).
[*]Given the Eclipse framework (no, I’m not looking to start an IDE discussion) it’s essentially trivial to write a context assisted, etc, etc, etc langauge editor. Integrate that with the AST and you have a DSL spitting out Java in an afternoon.
Which literature?
The obvious fundamental problem with DSL’s is that you’ve created a new language. Cue: all the support and re-training costs inherent to that. You can’t just go out and hire people who already know it in and out.
[quote]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 
[/quote]
In 99.999% of situations you will visually spot the syntax error. But writing that equation has taken you 3 seconds. Writing a class to house a method and a method to house the equation, and choosing an immutable signature and choosing (and possibly defining) types…all this takes a lot more than 3 seconds. You usually use a script in such a situation (IF you decided it was appropriate) because:
[] The equation would be edited by people who won’t or can’t edit java files - or can’t be trusted to - but who can just about manage basic algebra (or, indeed, classless basic).
[] or: The minutes saved in not adding the java baggage, and compiling, and recompiling for each and every minor change, outweigh the time lost for the occasional syntax error that slips through and wastes a lot of time in one go.
[] or: You need to save time NOW and you are willing to do that at the expense of losing even more time in the future (e.g. “demo has to work tomorrow morning; we can re-code next month, after GDC is over, and gradually replace the scripted bits with systems bits”).
[] or: You want people editing this who don’t have access to a compiler (perhaps they’re editing code in a web-browser and wouldn’t have the nous to intrepet compiler errors even if you redirected them to the web browser; nb: I’ve been involved in a game project where this actually happens - people with 0 programming experience are able to edit complex scripts in web forms; this is appropriate for their use case, and works very nicely)
[*] or: …many others…
Really, though, there isn’t much cause for a debate about whether you should or shouldn’t use scripting langs (it only makes sense to evaluate each situation separately). They’re merely another tool, and AFAICS it’s pretty obvious what their main pros and cons are compared to more proscribed languages, like Java. You just evaluate them for each part of your project, no?
Well, it would just seem that every time I think about such an evaluation I end up at the same conclusions: that the whole reason I use Java at all is because of a bunch of benefits it seems to offer over using any other language. And with javac shipped along with the game the only other advantage I can see in scripting - that source is compiled and loaded at runtime - is out the window too.
There are a couple of issues with the syntax but they are as nothing compared to what even PHP looks like.
I still don’t get it really 
Maybe I just don’t have any need of scripting for anything…
Cas
Surely your environment can provide a template class to suit the context so that the ‘scripter’ just has to fill in the body of the method. You can choose whether or not the surrounding templated text is visible (or editable). The code that the scripter writes does not now differ significantly from say JavaScript. You can either compile the code immediately or just before use.
[quote]The obvious fundamental problem with DSL’s is that you’ve created a new language. Cue: all the support and re-training costs inherent to that. You can’t just go out and hire people who already know it in and out.
[/quote]
It should be noted that DSL does not imply a new language. Cas, for example, is saying that Java is the DSL of his choice (though the “domain” in this case is a bit broad).
If it’s easier to write your FSM’s in Prolog, then do so. Some things are better in functional langauges whereas others are better in procedural languages. Use what makes sense for the particular situation.
Of course. And you can always simulate every scripting language in java. Or C++. Or probably in pretty much anything. For instance, every time we use BSH it’s not far off from doing what you describe. But I don’t understand what point you’re trying to make? Other than that you could write a new scripting language similar to BSH but with only the most basic of the features very easily?
You were talking about the time taken to write a java class instead of using scripting. However when you permit scripting at some point you are defining the context in which the script operates, which is much the same as defining the class ‘template’. So if we eliminate the effort needed for the user to copy that template themselves, both ways of proceeding require very similar effort from the user. The remaining difference is one of weak vs strong typing for variables declared in the ‘script’. This is what really (in my opinion) makes script languages easier; you don’t have to know the appropriate types. However if you are scripting a games (or other application) that you wrote yourself, this advantage probably doesn’t apply (you know what the type is).
With some scripting languages you can benefit from operator overloading and other constructs which makes the code more compact (and possibly more readable). OTOH if you stick with Java, you are tied to its syntax : great for robustness and security, but painful for quick and dirty prototyping.
Another point that is sometimes mentioned in favor of scripting languages is that scripting is easier for “artists” than C/C++ like languages. A simple, game-specific AI language would be much more efficient to test and fine tune gameplay than its C++ equivalent.
So far no one has really explained how to go about using java to, for example, script a cut scene…
[quote]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.
[/quote]
I disagree, all of the different platform behaviors I listed can be derived from a few simple properties;
physical opacity (jump thru from the bottom or fall thru)
elasticity
motion/motion on a path
collision response
attaching ‘teleporters’ to transit to another part of the level
attaching script objects to trigger different paths or events
So you would have one meta-platform class such that all these properties can change and are exposed to the scripting language.
Am I way off base here or what?
I think you’re dead right, that’s all setting property stuff. And the rest of so-called scripting seems to be about events and event listeners.
Cas
See:
http://www.beanshell.org/manual/intro.html#Scripting_vs._Application_Languages
For a good description of the different between scripting and application languages.
-Michel
Here is some very nice stuff: http://www.javaworld.com/javaworld/jw-10-2003/jw-1003-beanshell.html
I’m developing a sort of 3d scene editor, and scripting is the way I use for the user to control objects in the scene. Probably other solutions would be better, such as some sort of visual input to signal actions. The issue is that scripting still has the disadvantage of being a programming language, while it would be ideal, from an artists or layman point of view,to have the user using natural language to achieve what he wants – I’ll have to finish this project for uni, so I guess no time for complex AI parsers :P)
It seems that every one is going crazy about XML at the moment, and do people think it has any use in the game industry (load properties, custom characters, scene, opengl commands, etc…)? Since people are talking about achieving cross-platform solutions for game development, is worth considering XML?
I use XML for configuration. Better than INI files.
Cas
[quote]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
[/quote]
Scripting languages are excellent when you want to open up bits and pieces of your game to content developers. This allows them to script NPCs etc. It’s about making your game accessible to people that not necessarily are hardcore programmers. Hence I’ve chosen Rhino as javascript is a common fairly easy to learn language.
I get the impression that some of you work on your projects solo. In that case I agree. Scripting languages are not optimal until you invite creative ppl to extend your game.
And what in case of improbable accident, when programmer from this board is creative ? ;D
Seriously, there are some other reasons for using scripting languages. Ability to reload them in middle of running game, without having to rely on hotspot class replace, which often go awry. Ability to write macros/shortcuts, so you can use 1/5th of the code to express same thing for given domain of use. Powerful, in-game console for free.
Has anyone looked into SISC (http://sisc.sourceforge.net)or any other scheme or lisp impls for scripting? As it is so easy to dynamically compile and load Java anyway, I reckon this could be a good bet for a scripting language, as Scheme gives you a completely different approach.
I just spent the last 24 hours converting the GrexEngineShell (gesh) from beanshell to compiled java.
The good news is that … it only took 24 hours (conversion isn’t complete, but we’ve got the virual FS navigation up and running again, which is the most important part). Also, because we’re no longer constrained to beanshell’s “open a telnet port for every hacker in the world” design I’ve also integrated it into the GrexEngine as a full service - which means I only need to edit an XML file or two and I can make it HTTP, HTTPS, Telnet, or anything I fancy (just by changing a single word in most cases) - and get all the benefits of a secure login system wherever the protocol offers it. The 24 hours included the time to do this integration (and I feel quite smug that I could get a new grexengine service up and running so quickly, even though we’d not had any command-line services before :)) - and included a good night’s sleep, in case you were wondering! 
The bad news is that it was necessary at all. The beanshell source is just too damn hard to work with (at the moment…we’ve posted to the beanshell SF project with our problems, and made some suggestions - there are even some people who might step forward to help clean it up) and it was costing us more time in fixing beanshell’s problems than we were saving in being able to use a scripting language :(. That’s a pretty serious problem (hence voicing our concerns on SF as a sort of “test case”).
Also, there is of course the fact that it’s incredibly slow for any loop iteration at the moment, which almost killed Survivor dead in the water :(. I have strong hopes that the next version of beanshell may be literally 10-100 times faster, if (as rumoured) they move to more intense use of bytecode generation / mangling. But for now, it’s not usable unless you can avoid loops!