Opinions about scripting in a C++ environment

[Radikalizm]

As some of you might know, a lot of scripting languages out there are focused on interacting with a C API (think Lua, Python, etc.), C++ support is possible in most of them but requires some annoying workarounds

I'm working on a system for interacting with scripts, allowing a C++ program to call script functions and allowing a script to call C++ functions and class methods, and I'm fully able to register classes with my scripts right now
This makes heavy use of templates however and generally requires me to move away from the coding style used throughout the rest of my library, which is a rather huge game-breaker for me since I want the registration of these classes used by scripts to be handled through a common interface (designed in the same style as all the other interfaces in my library), and since I want the entire process of working with scripts as clean and easy as possible

One solution I'm considering now is to ditch support for registering classes altogether and to wrap the class methods I want to expose with a simple C-style API (which is completely possible in my current setup), which makes everything so much easier
This would also mean of course that anyone wanting to register any functionality they built through my library would be forced to write wrappers as well

I'm worrying about whether this would be considered as a good practice, and if there might be a better solution to this problem, since I don't believe people like to be forced into writing C-style wrappers for their classes

Any suggestions?

[Alpha Omega]

Maybe you should express what you want the people using this scripting tool to be able to accomplish as an end result. I am still a little confused on what the main point is? If someone uses your library (game engine?) and wants to run C++ code, why can't they just code that into the program? Why would someone want to have this script engine run C++ code? Unless the script will only access elements within the library itself? Explain what you want the whole thing to do at the end. I am a little confused.

[shadowslair]

@Alpha Omega: The idea of every script engine is to implement logic, behaviour etc. outside the main engine. Meaning if you change a resource file content you`ll observe different behaviour in the engine right away (no rebuild). I guess that`s what he`s talking about. He wants to implement his own version.

@Radikalizm: I presonally had similar idea some time ago, but it turned that coding such a thing is quite a pain, needs a lot of knowledge what and how to do it. Sure, it`s a great learning practise, but I`d personally use some of the already made libs if I was you.

[Radikalizm]

My original post was kind of written in a rush and rather late at night, I'll try to explain it somewhat more clearly

The library I talk about is in fact a game engine, and as you know a lot of game engines expose their API to a scripting language, some even going as far as encouraging users to build their entire game through scripts. Engines can also allow users building games to expose their game functionality as well to extend the API
The reason for this of course is ease of development, being able to rapidly make changes, being able to make changes on the fly while the engine is running through a dev console, creating effects and animations without needing to override some sort of animator class, GUI transitions, etc. without having to recompile your entire application every time you make a change

Normally seeing when you'd want to expose a class-based C++ API to a scripting language you'd want your classes to be accessible directly in said language, but most scripting languages however do not directly support exposing C++ classes without any nasty workarounds (in some languages like Lua you even need to hack in class functionality in the language itself)

The problem I'm having is that when I would 'hack in' the functionality to expose my engine's classes I would completely break the coding guidelines I've set up for the engine, these guidelines being mostly based on a clean interface-implementation model (like irrlicht uses). Because I would need to make extensive use of templates I would effectively break this model, since there's no such thing as a virtual template function in C++ (which would be required to build an interface)

The solution I had in mind was then to drop support for classes completely and only allow regular C-style functions to be exposed to the scripting language, resulting in a procedural/imperative API
This is still somewhat hacky to implement, but I can maintain my coding guidelines, and registering an engine or game function with the scripting language becomes as easy as a single function call (in my current implementation you only have to do: ScriptEngine->registerFunction("functionName", &namespace::functionName), and you'll be able to use this function from your scripting language)
The downside of this of course, as mentioned, is the fact that you absolutely can't directly expose engine or game classes, forcing you to write C-style wrappers for these, which can be quite an amount of work (not to mention the fact that you're actually kind of re-writing already existing functionality)

Personally I don't have much of a problem with this, in my engine it's rather easy to write these kinds of wrappers, the thing I'm worrying about is how other people see this. Would the practice of having to write these wrappers be considered acceptable, or would it just be considered a major pain in the ass?

@shadowslair:

I already have 2 completely functional prototypes for both Lua 5.1 and Python 3.2, for Lua I also made a prototype using the proposed solution of only being able to expose C-style functions (which works like a charm while fitting perfectly inside my engine architecture), so building the actual script engine is absolutely no problem as it's kind of already there
I've set up a rule for myself that I want to try to avoid directly exposing a user to the libraries I've used to build the engine (eg. bullet, Lua, etc.), so I write wrappers for these which work intuitively with the rest of my engine, and which make sure the user can't do any weird stuff causing the engine to crash (ie. trying to take over memory management form the engine, etc.), so directly allowing access to a third-party library is a big no-no for me

[Alpha Omega]

I think you have only two choices, either change your coding guidelines or try a different implementation. It sounds like this is a very important part of the engine and you are trying to tack in on the end kind of half ass. Could you reconfigure your scripting engine into the core of the engine, which kind of sounds were it belongs if your going to use it mostly for configuring the game. This project sounds more like your trying to build a platform into an already existing program? I would start with the platform first and then guild the game engine on top of it. Plus if your platform is good you could use it for other things later on.

[Radikalizm]

I think you have only two choices, either change your coding guidelines or try a different implementation. It sounds like this is a very important part of the engine and you are trying to tack in on the end kind of half ass. Could you reconfigure your scripting engine into the core of the engine, which kind of sounds were it belongs if your going to use it mostly for configuring the game. This project sounds more like your trying to build a platform into an already existing program? I would start with the platform first and then guild the game engine on top of it. Plus if your platform is good you could use it for other things later on.

I believe you're seeing this all wrong
This is certainly not a half-assed attempt, I don't do half-assed code in important projects like these (the fact that I engineered multiple working prototypes for different languages which could be integrated into the engine directly already makes it not half-assed)
The scripting engine is part of the core engine, the engine has been in development since june 2010 (with months of planning before that) and it is built from scratch, it is completely built by my own design and that design has proven itself over and over again throughout the entire development cycle, so just ditching my guidelines and going with something else is completely out of the question

I never made any mention of trying to integrate this into an already existing program, all other engine components have always been built with a scripting engine in mind, but I have waited with implementing it until now since you actually need functionality to expose before you can start writing scripts (and writing systems like your own rendering engine and audio engine, among others, completely from scratch requires quite some time designing, implementing and debugging, you know)
What you might consider a platform (math libraries, memory management, low-level utilities) is already there, and it has been there for over a year

This is not a matter of the scripting engine working or not, this is not a matter of my coding guidelines being correct or not, this is a matter of doing a tradeoff between ease of use (ie. a clean interface and easy registering of functionality) vs extended functionality, with that functionality not being essential to the functionality of the scripting engine or the scripts it should run, but being quite handy in some cases (history has proven that you can completely live without classes, or the entire object-oriented paradigm for that matter)

I think I've made up my mind about it anyway, I'm going to stick with the Lua implementation I have now and keep the simple API. It has never been my intention to use the scripting system as a complete replacement for writing games with the engine in C++, so scripts are assumed to be relatively short, which means a procedural API would work out great. Lua doesn't even support classes natively anyway, unless you want to start messing around with tables and such

[3DModelerMan]

Squirrel is a pretty convenient language. It has class support, and it's really easy to integrate if you sqrat. There's some nice wrappers for LUA too. There's luaplus and luabind. Luaplus is probably the better one of those because it has less dependencies. And you might want to check out SWIG.

[Radikalizm]

Squirrel is a pretty convenient language. It has class support, and it's really easy to integrate if you sqrat. There's some nice wrappers for LUA too. There's luaplus and luabind. Luaplus is probably the better one of those because it has less dependencies. And you might want to check out SWIG.

Looked into SWIG and luabind alread

Luabind was a good option, but I didn't really like the boost dependency
With SWIG I didn't really like the fact that there's another pre-processing step involved to create your bindings, since I'm already working with some pre-processing steps related to string tables and such

I'm going to go with the method I have now and see how that works out, a game is being built with the engine so I can immediately evaluate whether I made the right decision or not

I appreciate all of the input, I'll keep it in mind throughout the engine development

[serengeor]

@Radikalizm: What do you think about V8 script engine and mono?

[Radikalizm]

@Radikalizm: What do you think about V8 script engine and mono?

I checked out mono for C# scripting (not a big VB fan), since I used to work with C# a lot a couple of years back, and since I still use it for developing tools and such
The thing is that if you want to use mono for free you've got to abide the LGPL license, and since I'm not sure about whether I want to give out my source code in the end I'd like to avoid all GPL-related libraries, even if they're less restrictive like with the LGPL
The LGPL would also force me to dynamically link mono with my engine, while I would prefer to link it statically

[3DModelerMan]

You wouldn't have to give out all your source code. You just have to link dynamically, and if you change the source code of mono you have to release the mono source with changes.

[Radikalizm]

You wouldn't have to give out all your source code. You just have to link dynamically, and if you change the source code of mono you have to release the mono source with changes.

I don't really want to clutter up everything with DLLs so I try to do static linking when reasonable en when possible (I know that's kind of a weak argument)
It's just that I want to keep my options as open as possible I suppose, if I want to make an alteration to a library I need to be able to do just that without having to treat every piece of code differently

[serengeor]

And what about V8 scripting engine?

[Radikalizm]

And what about V8 scripting engine?

I don't really know that much about it, it's from google right?
Since I'm pretty comfortable with Lua I think I'm going to stick with that though, also the idea that Lua has proven itself in so many AAA titles makes it quite attractive

[serengeor]

And what about V8 scripting engine?

I don't really know that much about it, it's from google right?
Since I'm pretty comfortable with Lua I think I'm going to stick with that though, also the idea that Lua has proven itself in so many AAA titles makes it quite attractive

Yeah it's Google's open source JavaScript engine (used in chrome).
It can be embedded into c++ aplications.

I'd like to hear someones opinion about it.