Sign in to follow this  

Scripting Alternative

This topic is 4483 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is there anyone on this planet who has ever created their OWN scripting language? I've spent over six months now - off and on - creating a core library of functions I can reuse for practically any project. What I want to do now is add scripting compatibility. From what I've read in this forum, the main scripting languages - Python, Lua, Squirrel - all have their own problems and quirks. So I've decided it would be easiest - in terms of integration - to create my own interpreted "language" specific for my game "engine" (quotes because it's at a pretty early stage right now). I've already set up the basic structure of the language, and it looks like I could really develop this into something usable. What I want to know is, has anyone done anything like this before, or am I really, REALLY using the wrong approach here? If you have done something similar, do you have any advice? Thanks in advance.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?)

Share this post


Link to post
Share on other sites
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, javascript, 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).

Lunatic Python 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).

Also see Ruby, GameMonkey, Small, etc.

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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++.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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... :)

Share this post


Link to post
Share on other sites
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".

Share this post


Link to post
Share on other sites

This topic is 4483 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this