Scripting Alternative

Lots of game engines have their own scripting languages and this is not new. Sometimes though its worth putting up with the quirks than writing your own. I've done both... probably won't do it again, but only because its not worth it to me.

I've tried both ways, creating my own language and integrating existing languages, and integration quirks aside, it's much easier to integrate an existing language. Pretty much because if a script screws up, you know it's either the script or your bindings to the scripting system. If you roll your own and a script screws up, it can be one of those or a bug in the scripting system too. And bugs in scripting languages are annoying to track down. (Is it a parsing bug? No? Is it a problem in virtual machine? Maybe it's a problem in the byte code generator?)

I think it's the wrong approach to write your own. You didn't mention Angelscript, which is "sponsored" more or less by gamedev.net. It has its own forum on gdnet.

1. Python: biggest, most powerful, most overhead and most difficult to integrate (and oldest, most mature).
2. Lua: well sorted out at version 5.x, relatively small, easy to integrate, more complicated when garbage collection and C++ class support is desired.
3. LuaPlus: garbage collection issues should be resolved via the built-in reference counting system, powerful but complicated template metaprogramming (porting issues). C/C++ class support reasonbly clean but not as good as Squirrel.
4. Squirrel: smallest and simplest, inspired by Python, &#106avascript, Lua, and is partially derived from Lua (table code). Does not have a large feature library as with Python and LuaPlus (if you write your own language, you'll have to write your own feature library). However, for game scripting with C/C++ and classes, it is comparatively trivial to integrate and use compared to the other languages in this list (see the sqplus example).<br/><br/><a href="http://www.gamedev.net/community/forums/topic.asp?topic_id=292109">Lunatic Python</a> allows Lua to be called from Python and vice versa. Some companies use both languages (for example, Python for tools/utilities, Lua for game scripting).<br/><br/>Also see Ruby, GameMonkey, Small, etc.<br/><br/>If you have the time/desire to create a custom scripting language, perhaps modify+improve one of the existing languages. Otherwise, you may end up spending most of your time working on the scripting language and not on your game.

I created my own scripting system once, but it started off as a simple list of commands, and only later did I add variables and the ability to pause and resume scripts, and later I will add some sort of array object and the ability to call one script from another... but I could have used a pre-made language for that.

I think making your own language is one of those things that requires a fair amount of skill and time to do properly. And often that skill and time can be more fruitfully applied elsewhere. Integrating Lua and other languages like it is usually very easy, and probably wouldn't take more than a week, in contrast to spending up to 6 months developing and integrating your own language. You have to decide if it is worth it.

Thanks for the input.

I guess maybe I didn't clarify the type of "language" I was creating. I'm not about to create a COMPILED language - nothing that complex. All I'm going after is an INTERPRETED language. I know it's a little slower, but since I'm parsing the entire script (or group of linked scripts) right at the beginning, the scripts should run pretty fast.

"I created my own scripting system once, but it started off as a simple list of commands, and only later did I add variables and the ability to pause and resume scripts, and later I will add some sort of array object and the ability to call one script from another... but I could have used a pre-made language for that."

Kylotan, that's pretty much exactly what I'm doing. The reason I'm hesitant about using a pre-made language like Python is that the "hooks" everyone keeps referring to - from what I know they basically translate the C/C++ code into the language I'm using. But that's going to cause problems, right? Unreliable conversions? Correct me if I'm wrong, but that could create a lot more hard-to-find bugs than writing my own language.

Not really, at least with boost::python as long as you have RTTI enabled, there don't seem to be any problems with types getting mixed up when transfering data between Python and C++.

Quote:

Original post by Lord Caius Kylotan, that's pretty much exactly what I'm doing. The reason I'm hesitant about using a pre-made language like Python is that the "hooks" everyone keeps referring to - from what I know they basically translate the C/C++ code into the language I'm using. But that's going to cause problems, right? Unreliable conversions? Correct me if I'm wrong, but that could create a lot more hard-to-find bugs than writing my own language.

As SiCrane noted with boost::python, there will be no major issues with types as template-based methods will tend to show errors at compile time (as the template code is compiled into specialized instantiations). This will also be true for LuaPlus, Luabind, Squadd (for Squirrel), etc. If your are doing really basic scripting, it will be hard to beat Lua or Squirrel in terms of time and effort (relative to creating a custom solution). At which point you want more complicated features, they'll already be there if one of these existing languages is used. All of these languages are interpreted, and all are parsed and converted to (interpreted) byte code before execution (this is what occurs when you see "Compile" syntax in the API: not the same as a C/C++ compile to machine code bytes).

Perhaps try the sqplus example (minutes to download, compile, and test with MSVC7.1 (trace through with the debugger to see how it works)). Next try Vanilla Lua (examples from the etc directory, such as min.c and trace.c), then LuaPlus (trace through the tests/examples), then Python (I have not yet tested Python; perhaps a Python user can recommend a good starting example).

It's also relatively easy to integrate and test multiple languages at the same time, in the same program (I'm currently testing LuaPlus and Squirrel in my game app).

It's a useful thing to study. Language design and implentation is sort of the foundation of Computer science in some ways.

It depends on your game really and what you want to do.

I've been working on my own scripting language for about a year now. I'm doing it because I enjoy it, it's quite relevant to what I'm studying at the moment (uni classes) and I think the simplicity and functionality in the language will pay off in the end when I start to program with it.

Having said that I've had to draw deeply on obscure parts of computer science and it's very challenging. But then I'm going for a fairly complex system.

As others have said, unless you actually want to sink a lot of time into the development of a scripting language it's much easier to use an already existing one.

However if you're still interested in developing your own, I'd recommend the book "Compiler Construction: Principles and Practice" by Kenneth C. Louden. Although be warned, it can be heavy going. But it will give you a good idea of grammars & parsing, as well as runtime environments (i.e. what you do with the parsed code & keeping track of variables etc). The stuff about machine & object code generation you can safely ignore. And don't be fooled by the title, it still applies to an interpreted language.

Personally I couldn't be bothered & prefer to go for the tried & tested. The emphasis being on the "tested" part. Designing a grammar without pitfalls can be a pretty annoying task on its own.

I'm finding that out right now.

I knew it would be tough when I started, but in the end, I think it'll be worth the effort.

I've got the basic structure set up (function and instruction objects in linked lists, and local and global linked lists of variable structures. The tough part now is getting a good parsing system to work. I've decided to use a recursive approach, since that seemed best for several of the components, but I'm having a little difficulty getting the system to work. Right now, I'm reading in words from a file - but since the "language" resembles C so much, I'm starting to think I should be reading in single characters at a time.

Oh well. If I ever finish my engine I'll post it - probably as freeware... :)

Have you looked at other languages than those you have mentionned?

Louden has an example language called TINY which implements his C- language (a subset of C. Royally pisses me off when computer scientists do that kind of naming stuff. And I am one), the source for which you may be able to get hold of. That'll definitely help you out.
His site is supposed to be here www.mathcs.sjsu.edu/faculty/louden/cmptext/cmperr2.shtml but I can't get to it - it might be blocked to people outside of that domain :(

Also look into Yacc/Bison and Lex/Flex for taking a lot of the tedious work out of generating the C code for the parser. There are some win32 versions somewhere, though the linux ones do "just work, first time".