Topic: Multiple scripts (Feature request)

Hi, I would like to suggest that you please reconsider adding the ability of attaching multiple scripts to projects and scenes. It would make scripts clean and very modular which is a very good thing. I know that it can be emulated (kind of) with dofile, but that is very (very) messy IMO .

What I mean by adding to projects AND scenes is basically that you add scripts to a project and it's available to all scenes, but scene scripts are local to the scene itself so you can do level exclusive scripts (maybe you want to trigger stuff when the player is somewhere for example!). Maybe this would require some modifications to the scene editor, I don't know, I'm literally JUST getting back into Maratis smile

Cheers!

Re: 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.

Re: Multiple scripts (Feature request)

It's a logic, you can link files into files with doFile and get the same result,
multiplying running scripts is not always very good, having one script per scene also makes users aware
that script is a high-level langage best for scene-specific game logic.

Ireheart > that's exactly the purpose of the behavior system, it just has to be written in c++ (faster)

At some point when a gameplay starts to reach some level of complexity, the best way is to implement a game plugin with custom behaviors. For example you will have a "Player" behavior, a "Enemy" behavior with variables like "Speed", "Power" etc.

Gameplay complexity unfortunately means code complexity and structure complexity, the question is not how to manage to do that in script but should I learn c++ and create custom behaviors/game plugin or should I find a developer to do it.

Re: Multiple scripts (Feature request)

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.

Re: Multiple scripts (Feature request)

BitPuffin wrote:

Ireheart: 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.

LUA is more powerful than AngelScript and including files via dofile is simple enough.

Re: Multiple scripts (Feature request)

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)

Re: Multiple scripts (Feature request)

I have another question, you mentioned AngelScript as a good scripting langage,
and I just looked at it, AngleScript is using the same syntax as c++, so in theory using AngelScript to script would be the same as using the SDK in c++. For you, why is it more attractive ? Is it because you don't have to create a project setting, linking the libraries and having a compiler installed (like I said about the JIT thing) ?

Re: Multiple scripts (Feature request)

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.

Re: Multiple scripts (Feature request)

Thanks for the feedback,

I think the best will be something in-between, running multiple concurrent lua scripts is not safe,
but multiple "static" (non callable) scripts could be loaded like a plugin system to extend behaviors.

For the speed issue, we first need to find a performant way to define behaviors in lua,
and later add the option to use luajit (at least for publishing) : http://luajit.org/

Re: Multiple scripts (Feature request)

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.

Re: Multiple scripts (Feature request)

Thanks esodax, did the transition you did to luaJIT went without compatibility issues ?
and, how did you find the debug/error system compared to traditional lua ? (when error is found in the script).

Re: Multiple scripts (Feature request)

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

Re: Multiple scripts (Feature request)

Thank you esodax, I'll try to study that when I find some time,
let us know how your experiment goes smile

Re: Multiple scripts (Feature request)

Yes, thank you anael. I'll continue my slow progress on this smile
I'm just afraid that I will clutter the API to much with my own personal stuff so it becomes unusable as a contribusion in the end.
But maybe some parts of the code can be used at least.

Also, I forgot to mention that setVisible() is broken in the test above (forgot to remove it). But it contains a Lua module loader so require() now can be used instead of doFile() if preferred.