Multiple scripts (Feature request)

I would prefer to have a class system to adding scripts, it's much more professional. If your going to make a entity, why keep repeating it like in unity, aim for something like the source engine\neo axis engine with pre-defined entities. Individual scripts is messy.

Iceheart: Well okay fine, I haven't used those engines but it sounds like a good way to do it. Although I'm not sure what you mean by repeating it in Unity though. You can define behaviours easily in Unity iirc (I don't really use Unity but I've played with it).

anael: Well yes, like I said you can emulate it with dofile, but that ends up being really messy. The point I'm trying to make is that with the speed of todays computers it's really fine to have the engine in C++ and handle the logic in scripts. Development efficiency has for the most part become more important than game performance (since it's usually fine, and if not, THEN port the hogs to something like C++). The scripting API should really be almost as robust as the core API through C++. I know C++ fairly well so it's not that I'm afraid of it. I just want to be able to move forward quickly. Something that might be an option though wold be to connect the entire C++ API to AngelScript as some kind of plugin to Maratis. As that requires much less work than designing a Lua API.

I understand why you feel attracted to multiple script files, but it poses some potential problems like the sequence of execution call (if there is multiple scripts, which one is called first, second etc ?).

Could you give me your view about why dofile is more messy than multiple scripts ?

About the scripting vs c++, I agree for prototyping, but not for production, even if lua is fast, it is 10 to 100 times slower than c or c++. I always have this first repulsion to go to c++ like you, but I try to code reusable behaviors in c++ and at the end it's a gain of time and it's optimal.

But yes, the lua binding is still missing some important functionalities only available in c++,
I would like to make it possible to prototype behaviors in lua, but I didn't find a good way to do it (too slow if the behavior is too complex).

My other taught is about JIT (just in time) compiling, to allow simple c++ "scripting" with an embedded compiler. (so you don't have to create a project file, have a compiler installed etc)

Ireheart: The reason I mentioned Angelscript is because it seemed to be quicker and closer to the metal when it came to ease of binding to C++ APIs. But on further research I found out that it doesn't natively bind to a C++ class so that you can inherit it from AngelScript code so it turns out it was less great. Squirrel on the other hand using the Sqrat library seemed ridicusously easy to bind to C++ APIs so that you could inherit from squirrel code. And it's faster than both AngelScript and Lua. Don't think I'll be spending any time on that though for a while but it sure would be interesting to bind the full C++ API to Squirrel.

anael: Well I guess the larger goal with having multiple scripts is that each script should more or less be independent from the other and as re-usable as possible. That way you could run them concurrently. And if you want even further nice stuff, implement message passing between the different threads/scripts. It would also be nice to be able to attach a script to an entity (which I guess would be a behaviour in maratis).

The reason that I feel that using dofile for this behaviour is bad is mostly for semantic reasons building this huge tree of scripts just feels a bit wrong and also clutters the lookup table (or whatever you'd call it). It also seems like if more files calls dofile on the same file they effectively copy all the code into them selves, I guess it's the difference between #include and import (modules vs headers). I'm not quite certain about how dofile works, if I make a lua module the way you would normally make a module in lua (module(..., package.seeall)) would it get imported/required properly? Unless I've possibly (and probably) misunderstood lua wouldn't it say that the script file is first this module from the dofile, then the other and then that one etc until you reach the final one and then the script would be the module of that file (as if I'm using the module function multiple times in a script). I might be wrong though.

Well yeah basically what I'm trying to communicate is that I'd basically like to have full access to the API you can use in C++ and pretty much the same power as far as fully accessing the core engine goes (not power as in I can reach the hardware and deploy malware via exploits etc etc), but from a scripting language. Because If I had access to it, I could easily write reusable behaviours like you would in C++. But with less pain and in less time.

For some further thoughts on AngelScript I had after doing some research today, have a look at what I said to Ireheart. Anyways, syntax has nothing at all to do with why I find AngelScript (or any other scripting language for that matter) more attractive than C++ for logic. It's more because I can rapidly make changes to a script and see the results immediately without recompiling or anything like that. Plus the fact that AngelScript has a C++ syntax does not lower it to the level of C++. Again though, further research showed that Squirrel is supperior when it comes to pretty much everything. Another benefit of using a scripting language for logic rather than C++ is because it opens the possibility for awesome one click export to multiple platforms. You could package maratis so that it has access to MaratisPlayer executables for all supported platforms and then when you click export to say Mac from linux it will grab the MaratisPlayer stuff for mac and you now, export all the things! And additionally when exporting you can add additional optimizations like precompiling scripts to bytecode (which will make people who are afraid of having their code visible happy, myself not included for the afraid part, I'd be happy about the saved processing time). I suppose the MaratisEditor also could go ahead and not cache scripts and maratisplayer cache scripts for gained performance. You know, things like that. I could pretty much just click export to Mac and trust that the game now runs on Mac (won't even need do add a bunch of ifdefs for different platforms) without having to boot OSX (or even owning a Mac!) and compile all my behaviours (and if I'm really paranoid, send it to a mac user and see how it runs) since it's already compiled to cross platform bytecode.

I don't know if I'm coming through here, but for me being able to access full Engine API from some awesome scripting language like Squirrel to write behaviours seems godlike in many ways.

I'm already using LuaJIT with maratis, but I couldn't figure out how to build LuaJIT from source with this scons build system, so I had to build it separately then add its library to maratis replacing Lua 5.1.

I suggest that we fully move to LuaJIT at some point. The classic lua_xxx bindings will still slow things down as it stands, but it's still a nice performance boost until we have working FFI bindings.
LuaJIT also supports some Lua 5.2 features/extensions and some other enhancements that makes it good to have in both the Editor and Player for completeness.

As for multiple scripts, I believe require() should be used to import other scripts/modules rather then doFile() for reasons BitPuffin mentioned. Otherwise I'm personally fine with one script per scene.

Thanks anael, I didn't hit any issues moving to LuaJIT, I think it is (should be) Lua 5.1 compatible with some features from 5.2 that doesn't break the compatibility with 5.1.

I'm not sure about any differences in error handling.
However, when dealing with C types in LuaJIT and error messages, then it shows type names as numbers, like: 'struct 95' which can be cryptic.
But there may be other things here that I'm not aware of yet.

I'm still experimenting a bit with maratis and LuaJIT, especially trying to make better use of the FFI. I believe the only way to do it without changing to much is to get a table of C functions (maratis script API) into LuaJIT and then use ffi.cast to convert each function in the table to the correct function type. We can avoid most of those classic lua_xxx functions then. Also, it makes it easier to pass C data from and to functions if needed, like vectors and stuff.

I have uploaded a test here, maratis+LuaJIT, but it's only for Linux 64bit.
This patch should be applied ontop of the svn 200 version. Overwriting files, then build as normal.

https://dl.dropboxusercontent.com/u/784 … tch.tar.gz

And this is the Linux 64bit binary with the patch above already applied:

https://dl.dropboxusercontent.com/u/784 … -lj.tar.gz

Hope it works if someone want to try it out.

Oh, and the API now lives in a 'maratis' table (my personal choice). That is: getObject() now becomes maratis.getObject() etc.
Same with onSceneUpdate(), now should be written as: maratis.onSceneUpdate = function() ... end