In the last 2 weeks, I looked over (not actually tried) all the scripting languages known to man (ok, known to google ). The one that stood out most was, of course, Lua. Everyone said a lot of nice things about it, and it seemed like Lua is the cure for cancer. I spent quite some tiem looking at how to bind it with my code, how it''s syntax looks like, etc. What I didn''t like was the stack mechanism used to pass values lua<->host. I also didn''t like the syntax at ALL. I mean, I know 2 assembly languages, I know C, Basic, and I know PHP. Knowing 3 different grammar sets (php/c and z80/x86 ASM are relatively gramatically equivalent) is enough, I don''t want to learn somethign as unstanadard as LUA. I skipped over Phyton because it is ugly looking, BIG, and I heard it''s slow (I even seen it in action, as a Blender plugin, and it IS slow). Next I looked over a Forth dialect scripting engine, and I kind of liked it, but there were 2 problems: 1. There was no (apparent) way to call various functions, from the host (only one entry function) 2. Forth is very low level, so a lot of people might not like writting scripts in Forth. Ruby had a syntax nightmare, and a pure OOP design, and I totally disliked that. Then there were some GPL C like languages, but I didn''t like the fact they were GPL (couldn''t live with the GPL license). I looked over the SpiderMokney JS thing, but no matter how hard I tried to find out, I couldn''t determine if it was an interpreted thing, or it actually had a VM. For safety reasons, I decided not to use it. Finally, I found a language, called SMALL, that has ALL the things I wanted: 1. It''s fast 2. Is multiplatform 3. Very easy to integrate in your host program, and it''s easy to call any function from/to your scripts. 4. It is very C (or PHP) like. 5. Has a very fast VM (especially the ASM build) 6. It''s under the Zlib license, which allows you to do pretty much everythign with the code, as long as you mark your modifications, do not claim you wrote it, and include a copy of the license with your distribution. Anyway, if you want a flexible, robust, lightweight, free, c like scripting language, then Small is the way to go! I am very very happy with it

hey, that''s pretty cool. And to think, I''ve been rolling my own all this time.

Actually, writing scripting languages isn''t as hard as it seems (of course, they will be ungodly slow, for the most part). The hardest thing is actually integrating them into your game.

Max Payne, from what I understand, ran off of a C backbone with Pythong (my spelling) scripts out the wazoo. Pythong is a very interesting language, and you are right about it being incredibly slow. However, it''s developement time is very fast, almost making it a RAD language.


capn_midnight | Captain Midnight | deviantArt
ACM | SIGGRAPH | Generation5

I contemplated writting my own, but I realised that I have more important things to do (like actually working at my game) than writting my own scripting.
Also, a scripting language that is developed for years is better than a scripting language written in 1 month, as a small side project.

quote: Original post by Raduprv
Then there were some GPL C like languages, but I didn't like the fact they were GPL (couldn't live with the GPL license).

Gaahk... I thought I had read somewhere that you could use a GPLed module in your own software and you'd only have to release the source code the the module (with changes), while keeping the rest copyrighted (using a sound library in a commersial game).. I wasn't certain though and after extensive reading in the GPL faq I discovered I was horribly wrong. Jeez.. I'm glad I haven't started using any GPLed modules!

So thank you for making me question my knowledge of the GPL and for the info about SMALL... I've been looking for a scripting language myself (though I've decided to start out with c#, and I don't think it's necessary to add external scripting to that.. )

EDIT: I had mixed up GPL and LGPL.. It is legal to use a LGPLed library in a closed source commercial product, but it must be dynamically linked (or if statically linked, all source code must be included, but all doesn't have to be GPLed/LGPLed). The end user must be able to make changes to the library and still use the program. The interface must not be changed though

[edited by - frostburn on May 12, 2004 1:49:47 AM]

Yeah, only LGPL allows you to include the library in your code without having to release the source of your code.
I think a scripting language is usefull if you want to allow your users to change stuff without giving them access to the source code. Scripting also adds security to your application, as opposed to the DLL way, which makes your application insecure (malicious users can include viruses and such).

quote: Original post by Raduprv
Yeah, only LGPL allows you to include the library in your code without having to release the source of your code.
I think a scripting language is usefull if you want to allow your users to change stuff without giving them access to the source code. Scripting also adds security to your application, as opposed to the DLL way, which makes your application insecure (malicious users can include viruses and such).

I discovered it myself just as you posted probably (I started editing before you posted )..
I don''t think viruses is the biggest problem with DLLs/open source though.. After all if you use it in a commercial product they''re not allowed to distribute the rest of the application, and thus not easilty be able to change the dll for other users. If they add a virus to the dll source and publish it, other users will probably discover it and remove it (and possibly the haxxor). If they pirate the entire app, they can as easily add a virus to the main exe.
I think a bigger problem will be that with the source for the scripting system easily available and moddable, it will be easy to discover and create holes and exploits.
Another thing is that the folder looks so much tidyer with only an exe and datafiles and not a whole bunch of dlls and source code.

What I meant was, if you make an engine that allows mods (such as Quake, Unreal, NWN, etc.) there will be modders around, sharing their newest modifications. If you use the DLL way to extend the engine, then malicious people can add malware to their mods, and the game engine will happily execute the binary code that contains the virus.

As for the "yuck" factor, associated with having 100 DLLs or code files, this is where Small (but other scripting languages as well) makes a difference: You don''t include the sourcecode of your scripts, but you compile them first. For example, my way is to put all the script files into a single file (keep thems eparate but include all of them in the main file), compile it as p-code, and include that p-code file in the distribution.

Malware: Won't you have that problem with other solutions as well? I don't know much about modding... Of course if the entire mod is just a new script then it'd be hard to cause destructive behaviour (I assume that any disk access etc. must be handled by the engine). But then there would be no need for people using the mod to "update" the dll (they could be fooled by malicious users, but instead they could just exchange the game.exe with a program that formats all harddrives or something).
EDIT: I don't think it's possible to be 100% sure that all mods are kosher with a moddable game. At the moment a user downloads a mod or patch from another user/modder it's out of your hands.

Yuck factor: My point exactly.. keeping the libraries statically linked removes clutter (but it might cause other problems?). Script source could be available to modders (on cd or something).

[edited by - frostburn on May 12, 2004 2:35:08 AM]

You lost me at: "I skipped over Phyton because it is ugly looking, BIG, and I heard it''s slow "

For one, its PYTHON... (but, hey we all typo.)

And for two, its a beautiful language. Clean syntax, somewhat standardized formatting.
I cringe to hear it called slow (What would that make java then? ... Frozen molasses?)

Anyway, all that aside - it has a huge following, is widely used, and is definately not something that should be skipped over.
Perhaps you should jump on by http://www.python.org/ again and take a second look.
I did, and I am thankful for it.

- Jacob

Yes, sorry for the typo
Well, the problem is, a lot of people, including me, don''t like the fact that you have to obey some strict allignment rules, or else your code gets messed up in various unfunny ways.
Second, it is slow, I seen a Phyton script exporting an MD2 out of Blender, and it took like 6 seconds to do that, on a XP 1.7 GHZ
I need all the speed I can get, because the scripting language is embedded in an MMORPG server (which is not threaded).
I also heard that it''s kind of complicated to embed it in your host, and that phyton is meant more as a programming language which you expand with external modules than as a glue language (which is what most of the games need)