[New feature] Angelscript support (was Lua support)

[StefanP.MUC]

I just added Lua (5.1.4 with latest hotfix patches) and a LuaWrapper class to initializes it to the project.

Maybe we should link to pre-compiled Lua libraries instead of incuding the whole source (like I did it for now). But that's something oln has more experience with than me (change it as you like).

With this and the new console we can now start to convert the commands to Lua scripts. I never worked with Lua before, so if anyone wants to give it a try:
What needs to be converted for a start would be the ODFrameListener::executePromptCommand() function in ODFrameListener.cpp.
Not sure what would be the best practice with Lua. Separate functions for each command? Or even sperate .lua files for each command? Or simply convert the whole 1k line function to Lua code?

[svenskmand]

I also have no experience with Lua. But when we get to the point of mapping for the game I will try and learn Lua so we can make some serious levels During this initial implementation of Lua into the game we should make good documentation on how to interact with important game objects in the Lua code, e.g. how do you adjust creature properties, creature AI routines, keeper AI, spell properties and such. Also regarding the spells when we get a particle system running it would be nice to be able to make new spells completely from scratch using only Lua and the built in particle editor (which should be implemented with the particle system).

[charlie]

Ghoulsblade is a Lua guru (at least, all the schattenkind projects seem to be based on it) so is a good person to go to with questions or for advice (PM him or on irc).

[TheAncientGoat]

Nekotaku and I both know Lua decently, so shout if you need any help here as well. Heck, if only I could get OD to compile, then I'd test it out!

[StefanP.MUC]

Do you know only know the language of Lua, or also what are good coding practices in C++ to get a decent Lua<->C++ binding?

All I figured out, is that if we want to use Lua quickly, we would need another dependency, namely LuaBind, that supports C++ binding (while Lua without LuaBind only supports C-style binding, e.g. no class-binding). But LuaBind seems to need Boost - but not the Boost version that comes with Ogre, so we would then have two concurrent Boost versions in the project.

I'm currently googling my way through the web for some real-world code that uses Lua and C++ to get some inspiration.

[ghoulsblade]

lua manual/ref : http://www.lua.org/manual/5.1/index.html
lua introduction book : http://www.lua.org/pil/index.html

if you have questions regarding lua contact me in irc : i go by ghoulsblade/ghouly/ghoul or similar in #freegamer on freenode


If you want to go deep into lua and access ogre classes in lua scripts, have a look at this file:
It provides lua-bindings for not all but most core ogre classes, contact me if you need help setting it up.
Most of it is automatically generated by a script parsing the ogre headers, i can provide that too if you want to extend it.
https://github.com/ghoulsblade/vegaogre ... s_ogre.cpp


Something a lot simpler :
for creating luabindings i use code like this, contact me if you're interested in the headers required to set it up :
keeps code nice to read and saves you meddling with the lowlevel lua stack thing in most cases.

{l Code}: {l Select All Code}

#include "lugre_prefix.h"
#include "lugre_luabind_direct.h"

// some c++ class that isn't aware of lua, can also be in a separate file of course
class cSomeThingy { public:
   
   cSomeThingy   ();
   ~cSomeThingy   ();
   
   int   SomeMethod   (int a);
}


// luabinding class
class cLuaBind_SomeThingy : public cLuaBindDirect<cSomeThingy> { public:
   
   // methods
   virtual void RegisterMethods   (lua_State *L) {
      LUABIND_QUICKWRAP_STATIC(CreateSomeThingy, {
         return CreateUData(L,new cSomeThingy());
      });
      
      LUABIND_QUICKWRAP(Destroy, {
         delete &GetSelf(L);
      });
      
      LUABIND_QUICKWRAP(SomeMethod, {
         // index of the parameter, 1 is the implicit this/self/object handle, 2 = first parameter, 3 = second parameter....
         return PushInt(L, GetSelf(L).SomeMethod( ParamInt(L,2) ) );   
      });
   }
   
   virtual const char* GetLuaTypeName () { return "somelib.somethingy"; }
};

   
// this function has to be called once during lua init
void   LuaRegisterSomeClasses         (lua_State*   L) {
   cLuaBindDirect<cSomeThingy>::GetSingletonPtr(new cLuaBind_SomeThingy())->LuaRegister(L);
}

/*
lua example code :

local o = CreateSomeThingy()

o:SomeMethod(5)

o:Destroy()
*/


[StefanP.MUC]

Thanks for the input. What do you think of this:
http://lua-users.org/wiki/LunaWrapper
Looks pretty straight forward.
Is this any good in your opinion?

[ghoulsblade]

haven't used it yet, but looks good on first sight, so if it works for you, use it =)

it does have some drawback that i avoided, but they are mostly personal taste and coding practice-dependent :

* "class Foo" has to be aware of lua (the method "foo" takes a luastate as parameter, whereas my "cSomeThingy" can be any c++ class, even existing ones, and ogre classes etc, no modification in the class needed)

* { "foo", &Foo::foo } : 1x classname and 2x methodname + a lua aware method-variant for every method-binding ,
with the LUABIND_QUICKWRAP in my example you can embed code directly :

{l Code}: {l Select All Code}

LUABIND_QUICKWRAP(SomeOtherMethod, { print("hello world\n"); });

(so only 1 methodname, and no classname due to being located inside method code, avoids redundancy)
It's all in one spot and doesn't need a separate list of methods, which can become annoying with a growing number of classes.

* be careful that an instance of the c++ class Foo in the example you linked would be destroyed by the garbage collector (__gc/Luna<T>::gc_obj called) at some arbitrary time after you removed the last variable referencing it.
I prefer explicit c++ like destruction, especially when working with long-living objects that don't belong to lua alone and might still be used by systems in the c++ code.

[MyEmail]

Just as a quick heads-up: Lua gets messy when dealing with pointers, and pointers are kinda needed when doing OO-programming. To call C++ member functions you have to setup this terrible C-callback system that passes the C++ object to the callback, then the callback calls the appropriate member function inside the object (huge hassle). In addition, any extra parameters have to be passed to Lua, to the callback, and then to the C++ member function (aka: its slow).

[StefanP.MUC]

All I read was that Lua is one of the fastest scripting systems out there.
But assuming you are right: What alternative would you suggest? A game like OD needs a scripting system to allow a good and "flowing" development process in the future. So just saying "no, we don't add scripting support" is no alternative.

[StefanP.MUC]

I did some further reading, especially on comparison of different scripting engines:

The outcome was that I reduced the engines suitable for OD down to:
* Lua
* Angelscript (http://www.angelcode.com/angelscript/)

Since I did not yet started to convert classes etc. it would be no lost work/time to decide to use another scripting language.

What are the pros/cons for us? ([+]/[-] pro/con, [++]/[--] double pro/con, [0] neutral)

Lua:
[+] We have at least two people that know Lua
[+] There are lots of books, articles, tutorials available
[--] C-style, stack-system, needs wrapper classes

AngelScript:
[+] script langauge has C++ syntax and types (bool, int, double...) -> easier to learn for the main OD devs
[0] not so widely known, but a lot of tutorials and docs seem to be available
([+] license is even slightly more libre than Lua's licence)
[++] a lot easier intergation into existing C++ code

From the developer viewpoint I have to say that I'd prefer AngelScript because of it's much easier integration into C++ code and its similarties to C++ code.

[svenskmand]

I would vote for AngleScript given that it is similarly to C++, that is a huge benefit.

[charlie]

What about squirrel? Has C++-like syntax as well, was used by S.C.O.U.R.G.E.1 although I can't give specific information about performance etc. (i.e. just for your consideration.)

AngelScript also sounds good.

[StefanP.MUC]

OpenTTD uses Squirrel as well. But I read that Squirrel is inspired by Lua. And according to their wiki we would need again not only squirrel, but also additional packs that give us the C++ binding abilities (if we don't want to do this ourselves), just like Lua.

Especially when it comes to classes, AngelScript seems to be extremly flexible:
You only do somethling like AngelScript->RegsiterClass(foo, "foo") and that's it, you can then exchange data between objects of this class between the angelscripts and C++ (with something like this: "getVariable(name)", "setVariable(name)").

[svenskmand]

This description of AngelScript sounds like it just fits perfect into our project. The bindings are also very easy, you just register the class in AngelScript and then you can use it, as has been said earlier.

Squirrel seems to be more widely used, it has its own Wikipedia page, which AngelScript does not. Squirrel also seems to fit nicely with our project, it also has C/C++ style syntax although I could not see if it has easy usable bindings.

[StefanP.MUC]

By the way, a question, possibly directed directly at oln, about the threading in OD (as this is also in discussion and planning currently): Has the script engine to be multi-threaded? What features does it need to have in this context?

It seems that only AngelScript is natively fully multi-threaded (that also allows to control the different threads manually, etc).
Lua needs addons, squirrel is not fully multi-theadable (or also only with addon).

[MyEmail]

What alternative would you suggest?

Well, there is Guile (a Scheme implementation, which is a form of Lisp). If you don't mind adding Boost to your dependency list you could use ChaiScript (very active project, designed specifically for C++. Only downfall I see is Boost, which IMHO is the worst thing since Vista). You could use Lua, it is just a hassle in a C++ project (if you where doing an ANSI-c project then Lua would be perfect). You could use Boost.Python to add python scripting.

Or if you want to go hard-core and get a language just right for your game, then implement your own (hand-code your own parser, or just use something like Bison to make one for you).

Heck, you could even use C++ as your scripting language if you really wanted too (there are several libraries to implement this, but please don't even think about it).

[charlie]

Boost, which IMHO is the worst thing since Vista

You're the 2nd person in a few days to say this on the board. Would be great if you could elaborate. (As a non-C++ programmer I've not ever had to deal with boost.)

[MyEmail]

Would be great if you could elaborate. (As a non-C++ programmer I've not ever had to deal with boost.)

Then be glad . Its an extension to the C++ STL, and I don't want to get into a "theory of C++" debate, but IMO it expounds upon C++ in a bad way (it takes the bad features and magnifies them 10x, using them (the bad features) as if they where the best thing since sliced bread).

[svenskmand]

By the way, a question, possibly directed directly at oln, about the threading in OD (as this is also in discussion and planning currently): Has the script engine to be multi-threaded? What features does it need to have in this context?

It seems that only AngelScript is natively fully multi-threaded (that also allows to control the different threads manually, etc).
Lua needs addons, squirrel is not fully multi-theadable (or also only with addon).

Allow me to answer this since I have proposed the thread model that oln is currently working to implement. The general idea is that every game object have two states, the current (the state for this turn) and the future (the state for the next turn, which we are going to calculate). Now there will be a thread-safe list of all game objects (think of it as a producer of work), then there is a thread pool (approximately one for each processor) of consumers. These threads take a game object computes its future state from its current state and the current state of all other objects that it depends on (notice that these are never written into by any thread). When all the work in the thread-safe list is performed, i.e. all threads have performed their work, the future state becomes the current state and the current state is now garbage that can be overwritten in the role of the future state in the next turn.

So since the scripting will have to involve game objects, the most obvious way to handle this would be to make each thread also execute the scripting relevant for each object. So if the scripting code also takes into account the whole idea of the current and the future state, then everything should be okay.

[sireus]

Sorry I interrupt here, but are you sure you need multi-threading? I don't even want to imagine how much work it would be to make a whole game fully thread-safe.

[MyEmail]

Meh, thread-safe games is a piece of cake if you do it right. Put the game-logic in one thread, rendering in another, pathfinding in another, physics in another, etc. It ends up having very nice performance. If not done right, it can be very detrimental to a project.

[svenskmand]

Meh, thread-safe games is a piece of cake if you do it right. Put the game-logic in one thread, rendering in another, pathfinding in another, physics in another, etc. It ends up having very nice performance. If not done right, it can be very detrimental to a project.

That will not scale well, what do you do when you have 32 or 64 or even more processors? The way we are going to do it, as I mention above, will be completely scaleable and use all available processors as long as the number of processors is at most the number of game objects, and if you have more game performance will not be an issue for you.

[MyEmail]

That will not scale well, what do you do when you have 32 or 64 or even more processors? The way we are going to do it, as I mention above, will be completely scaleable and use all available processors as long as the number of processors is at most the number of game objects, and if you have more game performance will not be an issue for you.

Sanity check: Does OpenDungeons need 32 or 64 processors?

I would be surprised if it ever needs more than 2, in fact it shouldn't be planned to ever use more than two. Take a look at this. 49.36% of computers have only 2 cores. 40.93% have 4. Unless you want to eliminate 49.36% of your potential client-base you can't plan on OpenDungeons using more than 2 cores. Unless you want to eliminate 90.29% of your client-base you can't plan to use more than 4 cores.

TBH 2 cores is more than enough for a RTS game. Planning to use more than that is overkill, completely unneeded, and totally impractical (not from a coding perspective, but from a client-hardware perspective).

[svenskmand]

You do not get it we do not plan to use any more than one cpu, but we are going to support as many cpus as you want. Hence our game will be ready for the future where the number of cpus is the performance measure of a computer and not its speed.