Scripting languages

[princec]

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

[pythonlover]

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

[pedro]

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 )

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?

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

[princec]

I use XML for configuration. Better than INI files.

Cas

[Sanxion]

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

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.

[abies]

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 ?  

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.

[Jacko]

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.

[blahblahblahh]

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!