   Chaiscript? Scripting paradigms that it might support?
  I've been messing with this language for a few hours, and I don't know what to make of it. I am intrigued by its premise; a scripting language designed from the ground up to be interoperable with c++.Providing you are familiar with c++ template syntax, this language is trivially easy to bind with c++ objects. Here is an example of a (very crude) implementation of the factory pattern, bound right together with chaiscript. I chose to give each class a static member for binding itself. (The language in its vanilla form only supports boost::shared_ptr but I have sneakily converted it to use tr1::shared_ptr instead because this is what my codebase uses)#include <exception>class Entity{std::string message;public:Entity(const std::string& message):message(message){}const std::string& getPrototypeName(){return message;}static void BindChaiStuff(chaiscript::ChaiScript& chai){using namespace chaiscript;// typechai.add( user_type<Entity>(), "Entity" );// ctorschai.add( constructor<Entity(const std::string&)>(), "Entity" );// functionschai.add( fun(&Entity::getPrototypeName), "getPrototypeName" );}};class Factory{int i;public:Factory() {}void hello() { std::cout<<"hello world"<<std::endl; }std::tr1::shared_ptr<Entity> getEntity(const std::string& msg){Entity * a = new Entity(msg);return std::tr1::shared_ptr<Entity>(a);}static void BindChaiStuff(chaiscript::ChaiScript& chai){using namespace chaiscript;// type chai.add( user_type<Factory>(), "Factory" );// ctorschai.add( constructor<Factory()>(), "Factory");// functionschai.add( fun(&Factory::hello), "hello");chai.add( fun(&Factory::getEntity), "getEntity");}};int main(int argc, char *argv[]) {using namespace chaiscript;ChaiScript chai;Factory::BindChaiStuff(chai);Entity::BindChaiStuff(chai);try{chai.eval("var t := Factory()");chai.eval("var i := t.getEntity(\"Freddy\")");chai.eval("print( i.getPrototypeName() )");}catch(std::runtime_error& err){std::cout << err.what() << std::endl;}}There are a few things I'm not sure of however; the primary thing is what kind of paradigm one would use with a language of this kind. Theoretically one could bind every single high level object the "engine" uses and write the actual game code in chaiscript. This means the game loop would be totally written in chaiscript.Another architecture I can think of would be to use a callback based paradigm, where all responses to callbacks (key presses, creatures spawning and dying, etc) are chaiscript but the basic structure of the game is still c++. I certainly think that UI responses (or even UI building) would benefit from this architecture, even if the rest of the game used something else.Are there other architectures that I could consider? I've not found many references to chaiscript on gamedev.net, probably because the language is relatively new (and niche) and because the industry is currently using lua.   
  Binding generators like Swig and Boost.Python have alleviated much of the burden of binding C++ to scripting languages; the binding code you've listed there looks roughly on par with those in terms of length and clarity. (I'll talk about high-level languages  (Lua or Python or Spidermonkey or Chai or whatever)  in general in the remainder of this post.Quote:Theoretically one could bind every single high level object the "engine" uses and write the actual game code in chaiscript. This means the game loop would be totally written in chaiscript.This is a very nice way to program in a high level language and still get C++ performance... start with everything in your high level language, see what's slow (or guess ahead of time), and rewrite the slow or need-hardware-access stuff in C++, bound through a binding generator. There's a reasonable argument to be made that you can still get nickeled-and-dimed to death on performance with that much code in your HLL, and it also requires that you have a HLL in which someone can write a large codebase that doesn't suck, and that you have coders who specifically can do that.Quote:Another architecture I can think of would be to use a callback based paradigm, where all responses to callbacks (key presses, creatures spawning and dying, etc) are chaiscript but the basic structure of the game is still c++. I certainly think that UI responses (or even UI building) would benefit from this architecture, even if the rest of the game used something else.This is the most common approach. It's difficult to come up with a nice, small interface between the two, but it can be done, and ideally it lets gameplay programmers do what they need to without having to touch C++ or engine code. The danger here is ending up with a HLL interface that doesn't adequately hide the structure of your engine, losing you the advantage of a domain-specific language for scripting while adding the complexity of bilinguality.Quote:Are there other architectures that I could consider?Sure, plenty. You mentioned your game loop being written in C++ or your HLL.... what does that matter? It's just a while-loop. Imagine a C++-based game loop that does nothing but chai.eval("game.Tick()"); renderer.RenderFrame();... the HLL used for game updates but not for rendering. Or per-entity script processes, which each tick per-frame. The architectural implications of these can be surprisingly small, and the organizational implications for your coders can be quite large.   ;  C++ actually isn't the best language to use to create scripted content, it's too rigid with its class hierarchies, inheritance model programming and it's unmanaged memory puts too much burden on the scripter. Exposing the entire C++ object set to the scripters would be forcing them to write C++ code in a C++ meta language and have all the associated problems.Most companies go with a higher level language like Python, Lua, Scheme, custom language etc.. bound to the backend C++ engine through a very controlled API or scripting harness.Designing a scripting framework is actually a difficult task, usually requiring a full time programmer or team to the task (varies based upon project). You have to balance the need of the designers for ease of use, understandability, and productivity but also handle the backend side of the C++ resource management, efficiency and persistence issues. There are a few language which emulate the C++ syntactically and are easily bounded to it, i believe AngelScript is one (see http://www.angelcode.com/angelscript/)Good Luck!-ddn   ;  I've checked out boost::python and it appears just as easy as the chaiscript example. I would certainly prefer to use python, but there is one lingering question; Could python natively support shared_ptr's?IN the case of chaiscript I had to replace boost::shared_ptr with tr1::shared_ptr, but apart from that it natively supports the shared_ptr's; note how in the "scripts" var t and var i are both set to shared_ptr's.How would I do that with boost::python?Also, there won;t be teams of programmers or dedicated scripters because this is just my messing around hobby project with no real aims to it :P   ;  Using Boost.Python, returning shared_ptrs to Python from C++ functions Just Works. To be able to use it as an object rather than an opaque type, see here.   ;  Would I also be able to embed python into the game, rather than having to expose objects to python through a DLL? I ask this because I suspect that the latter architecture I mentioned, where the scripting language operates on messages it receives, is a lot easier than binding every high level object. The other reason is that I'm using havok, and the usage agreement states that havok cannot be exposed as "any kind of dll". I would have to drop havok if I was to extend (rather than embed) python.   ;  Yes, you can embed python and define C++ objects and functions in the executable that can be used from python. However, it's not really any easier or harder than extending python with a DLL.   