Annwvyn Experimental 0.2.6 Scripts! Scripts everywhere!

I was looking for some time into integrating a scripting language to the engine. This makes content development easier and quicker because you don't need to re compile everything after each changes.

I've thought about Lua, and even though about putting python on the engine, and then I discover a really interesting project called ChaiScript.

ChaiScript is a scripting language for C++. It's made to be easy to bind with C++, and it is.

So, this release add the possibility to attach "behavior" scripts to AnnGameObjects (in a similar way Unity deal's with this).

The Scripting API itself is documented here : http://api.annwvyn.org/namespace_annwvyn_1_1_chai_script_a_p_i_doc.html it's functional but not actually finished. The inner working, syntax and naming conventions could change (but I don't expect to do it)

Each behavior script is defined in a file with it's name and the ".chai" extension. They are written in ChaiScrip, a language that will appear fairly simple for any C++ developer (the syntax is more JavaScript-like than anything else).
Scripts define a class bearing the name of the script file, implementing a constructor taking the name of the "parent" AnnGameObject that own the script. An "update" method with no arguments is called at each frame of the game.

They can optionally implement any of the "Event" method of the AnnEventListener class as method. They will be called accordingly with the correct event type as parameter. These are usable as described in their representation in the API documentation.

class MyBehviorScript
{
    attr Owner;
    def MyBehavirScript(owner)
    {
        this.Owner = owner;
    }

    def update()
    {
      //This is called at each simulation frame
    }

    def KeyEvent(event)
    {
        //This is called at each keyboard event
    }
}

Now AnnGameObject are globally identifiable by a name, and can be retrieved from the AnnGameObjectManager, or via a function in scripts. Level owned "ID" for object has been replaced by this for the AnnGameObjects, but API-wise it's the same thing.

Some cleaning has been made on the template project, and some code cleaning has been made too in general thanks to ReSharper's static analyzer, and making it more C++14. In the effort of improving the quality of the code, some processing of object collection that was done by hand has been replaced with std algorithms. This makes the code cleaner and the standard implementation of theses algorithms is probably better than anything I could come up with myself.

There's still some work in that regard, but this is not a priority.

Collision now push event through the event manager. Overriding the CollisionEvent and PlayerCollisionEvent methods of a listener permit you to get them.

In the previous release statement I was talking about either running the logic or the resource management in a separated thread as the rendering. This proves a bit more difficult to do because of Ogre's non thread-safeness in this regard. I've done some experimentation and concluded that I shouldn't bother with this before porting the graphics code to Ogre 2.1