@Garthy
Thank you for posting all this! It's one of the questions I've wanted to ask for so long :D  I've tried lua, squirrel, and ruby, but none of them doesn't work for me. Well, Lua kinda does, but I was so frustrated with the syntax that I don't feel like using it anymore. I also got ruby to work (1.8.1 or something) It wasn't that bad but I haven't worked more on it yet since the language is pretty slow. Squirrel doesn't work for me at all due to the lack of documentation and examples.

Not a problem. Since I've been struggling with it for so long, I'm surprised I didn't stop and think "well, perhaps I should ask around" much earlier.

I haven't tried python since I've heard that it isn't designed to be embed. However,I've tried AngelScript and it works great for me. It also does what you ask in the first post. So in case you feel like embedding the whole python is overkill, you should try angelscript The creator is very nice too. On angelscript gamedev.net forum, he answer questions pretty fast and very clearly too.

Anyway, reading this make me wanna try my hand on python too.

Apart from the initial pain (much of which you can avoid with the notes from the previous page, I think!), it has been a positive experience. The Python OO stuff is a bit poor in comparison to say Ruby, which I didn't remember from my previous uses of Python, but it's certainly "good enough". The API is good, and documented.

Re Angelscipt, an active, responsive maintainer is a *big* plus. I've added it to my "must try some time" shortlist.

(discussion on Minimal)

Minimal certainly sounds very interesting. I like the no-nonsense host functions.

Ruby can do this and is extremely awesome.

Ruby is an awesome scripting language, by far my favourite, and I use it heavily in my project. IMHO, as a language, it is superior to every other scripting language I have used, bar *none*. When I first tried moving on from LUA, attempting to embed it was a natural choice. Based on my experiences, my recommendation is to try it only if you have a lot of spare time free and a good plan B. As mentioned previously, my experiences in this regard were very poor.

I could go into a lot of detail, but the gist is:

- The documentation for embedding/extending is poor. You'll be hitting Google and mailing lists quite a lot to get any basics done. At the time, not many people were doing it.
- The means of performing even basic operations is extremely unintuitive through the API.
- I uncovered a bug in the garbage collector that caused intermittent crashes when Ruby is in heavy use, which made embedding Ruby completely useless to me as it made my app buggy. Until I produced a test case, it was "must be your code". When I did, along with hours of testing results and a highly detailed description, it was silence, or "works for me on my system" (the bug only affected some systems, so such a statement is useless and misleading). Nobody seemed to know what to do with bug reports. I tried submitting a bug report on a couple of systems I found. On one, I was told, after a while, that "nobody really uses this one any more". The "correct" one was down for days. Every so often I was asked to try it on the latest version. After spending my time doing so, and confirming it was still broken, no response. So basically, I was given busy-work to try to make the problem "go away". Each time by someone new. This was in response to my offering to help where I could. I tried digging around to find the proper place to submit a report on the Ruby homepage, and (at the time at least) I just couldn't find it. At this point I just gave up in frustration, and won't touch it again until there is someone both passionate and knowledgeable enough to clean up the documentation and take bug reports seriously. I know that person won't be me, due to the experiences I had.

Now don't get me wrong, I *love* Ruby as a scripting language, I just hate it as an embedded scripting language. I wasted huge amounts of time trying to get it to work, and afterward too, when trying to do the right thing and get the details to the right people.

@Garthy:
Forget the part about not being able to call script functions from the host program. I just added this feature to the base Minimal code :-P.

You are very obviously proud of your work on Minimal, with your natural response to hearing about a shortcoming being to immediately add a feature to address it. Good libraries are the ones that are worked upon by people who obviously care about the code. I sincerely hope that a whole bunch of people pick it up and have positive experiences with it.

I'll probably have a skim through it at some point, even if I don't use it, simply because your discussion of the tech behind it is intriguing. That, and a bytecode-based embeddable VM may have other uses in my current or future projects.

Have you considered putting up a page showing examples of the language in use, and examples of using the API, so that a casual browser can see what it looks like as a language, and how easy it is to use in their own applications? Just a thought. I'd be very interested in such a thing. Don't do it for me, of course, just if you'd like to attract more people to using it and think it would be a good idea. If you already have, and I just don't know the link, my apologies for assuming that you hadn't done this!

I'll propose my Minimal scripting language. Its very simple and a good starting point for making your own scripting language (the code is hopefully easy to follow and its just a pair of .c and .h files). Personally i use it as a starting point for game/engine-specific scripting languages or configuration files so the Minimal lang itself doesn't have much stuff.

At this point I'm probably looking for something a bit more established and documented, with concrete examples, and no need for a great deal of additional work. This is not to disparage your work *at* *all*. It just might not be suited to what I am looking at doing at this point. However, if it came down to rolling my own, I'd be looking around at other people's work, and something with a minimal starting point as you have developed would have a great deal of appeal in such a situation.

Out of curiosity, does it handle the A->B->A stuff I've mentioned, ie. call the script from say C++, and the script can call back?

Another option is AngelScript which can use C++ functions and classes directly and i think even extend them.

This looks interesting- seems like it is designed from scratch to do just what I am describing, and from the doco I *think* it handles the extending/A->B->A stuff I've mentioned. Very interesting.

What aspects in particular rubbed you the wrong way?  I'd be interested to hear more about your experiences integrating and using it in your game.  Such accounts are pretty hard to come by, and I'm quite curious to hear how things play out for other developers.

I'd made notes somewhere- can't find the cursed things though. Here are a few things off the top of my head, forgive any rustiness, it's been a few years:

- Manually managing the stack is a pain. This makes A->B->A-style extended calls rather painful to work with. They work, but they're a pain.
- Arrays aren't *really* arrays, they're basically maps.
- Arrays begin at 1. Kind of. But not.
- Numbers are actually floats, no separate int type. Justification talks about how floats won't always lose precision, but sometimes you just want an int to be an int.
- Language itself is a bit unwieldy. Some clever things are possible, but it feels more like you are *fighting* the language than *using* it. I ended up simplifying my use of it considerably because it just became too frustrating.
- The API has a nasty habit of changing. The calls that worked for you yesterday may break or refuse to compile when you upgrade. Backward compatibility doesn't seem to be a concern- at least one upgrade *could* have been done with backward-compatible wrappers.. but it wasn't! The "offending" functions were just removed.
- Despite a decent amount of documentation, there tend to be a few ways to do various value manipulation, but it's never clear what the *right* way is. Guess wrong, and the next upgrade will kill your code. Again.
- Weird implementation decisions, such as it being decided that it was actually acceptable to call exit() in an embedded scripting application.

I'd like to emphasise to any LUA fans that these are just my personal experience, and that I'm not looking to debate/argue its merits or hurt anyone's feelings. It just didn't suit my needs, sorry.

I would still always recommend looking at it. It is a well-established embedded scripting language. Some of the problems mentioned above may have been addressed since.

I know what you mean... at first LUA looks like the end all solution, untill you learn the catch is that you have to to a bunch of stack work to pass data to and from it (which its website actually lists as a benefit of the language for some reason.)

And a few more reasons given above. Yeah, agreed. It's a bit of a letdown as it seems to be the perfect solution before you begin.

I think I'll still end up going with LUA though, I'll just have to go down the twisty road of keeping all my game specific data inside LUA. Actually, I was just thinking about making an Interpreter class to interface all the LUA in C++, but that's still a bit further down the development road.

I'd definitely look into writing a A->B->A-style callback function into your code, unless you want to be stuck either putting everything or nothing into LUA. If need be, just write one or two interface functions, and use the args to go off and do useful things, rather than writing a thick interface. LUA is definitely capable of doing such things, even if it is a bit painful.

Personally, I think that once a library or language starts significantly impacting on your design, then there is a problem, either with the library/language, or how you're using it. A good library or language simplifies what you are doing. A bad one changes it. IMHO!

I have yet to check out python. I've been learning the language to help a friend get into programming and it looks usable, but I haven't taken a look at the C api yet. I also don't think the language itself is as elegant as LUA (for scripting at least), but that would be moot if its implementation into C was better (i.e. shared variables).

Python is a good language, it's one of the reasons I was willing to gamble some time on getting it going as an embedded scripting language even though it wasn't really designed for that purpose specifically. Personally, my preferred language is Ruby, but after some horrible experiences and masses of wasted time trying to get it working as an embedded scripting language, I doubt that I'll try it again.

If you prefer LUA scripting over Python, you might prefer LUA overall, for while the API is painful at times, and changes, it's designed to specifically fit the embedded scripting role. I happen to prefer Python over LUA as a language, myself.

I know there is also SWIG, but meh...

SWIG is definitely worth playing with. Whilst I'm not using it for the embedded scripting, I have used it for creating Ruby modules that use some of my C++ libraries. It is very useful.

Quick question - why did you ditch LUA? I was thinking of using it primarily since it is able to do exactly what you are looking for.

Nevermind, got mixed up, thought you meant that you were looking to call functions in script not that you wanted to do more.

Actually, you're quite right- I am looking to ditch LUA. Or, more accurately, I used LUA for embedded scripting in my last project, found a few aspects er... not to my taste, and was looking to try out other options for my next one. I would highly recommend investigating it and experimenting with it as a potential candidate. It it basically my fallback option if I can't get a more preferred language to work.

On that front, as of today, I've now got Python driving one of the two key parts of my project that need scripting. Thus far, pretty stable. At this point I'd offer even odds that it will be the final thing that I use.

there is a chance flash player gets open source this year. now imagine that! not only you have a powerful scripting language but you also have control over it's graphics engine. what 2D is concerned, your set. and i'm sure with some modifications you can directly inject AS3 and run it. this was removed due to security reasons, but it's still there in AS2 (run at script level). anyway, a swf is the script and graphics resources mainly, so there should not be any problem to make a console out of it.

i'm beginning to feel like adobe's paladin.. good.

I have to admit that this post has completely and utterly baffled me. Personally, why do you feel that Actionscript would be a good solution to this problem?

Ah, cheers, thanks for that.

I used InitModule with a table of calls too. Just the table started getting long. It wasn't really a problem with python/c++, I think the problem was with my implimentation. I'd do it differently the next time around.

As for the missing data, I think everything got lost when the function returned back to c++ because it went out of scope. I'd need to learn more about Python to stop that from happening.

When wrapping some parts of Python I considered doing some sort of clever wrapper to manage those tables, but decided against it as the implementation I'm working on will likely only have a small number of calls (maybe a dozen), and they'll generally only change statically. Of course, experience could prove my guess wrong. :} I think I understand what you mean with respect to those tables now- each time you changed them, you'd need to re-init the same module, and you'd have hassles if anything was using that module at the time.

I didn't regret it, because I learnt a lot. The larger problem was that I found out that I didn't know enough about Python to actually impliment anything worthwhile. I'd have to learn Python from the ground up as well as making a new game as well as working with Python/C++ at the same time. It was chosen because it meant the game could be edited without having to recompile.

Sounds good. My Python is very rusty, but I imagine I'll be learning it again in very short order. The sort of stuff I'll be doing is quite well suited to scripting: too dynamic for it to be conveniently built into an executable, but too complex to be data-driven. And, once it's in there, I'll probably find a dozen other uses for which a scripting language is more maintainable than a more detail-oriented language such as C++. :}

Personally, I would recommend something very similar to what Hajo has said- basically implement an abstraction layer that you use to load a level. Your initial implementation should just load it from disk, no cleverness. I'd then do what nitram_cero suggested. Gloss over it, work on the game, optimise later. And when "later" arrives, if you decide you want to be clever, you can change the implementation of your abstracted layer to either preload the whole thing, or cache the last n levels, or selectively modify things, so forth. You might also want to improve the loading earlier if the load times end up annoying *you*.

I managed to get Python embedded successfully through C++ a while ago.

Problems I found with it:

Every function in C++ that needs to be called from Python needs to be initialised. Eventually the script class that handles it gets a little complicated from all of the different types of calls.

I'm presently exposing such functions via Py_InitModule(), a table of calls, and in the script it imports that "virtual" module, and makes the calls. Did you do something similar? If so, is there a gotchya that I'm about to run into? Would love to know about it in advance if I can.

I'm also not sure what you mean when you say that every function needs to be initialised- apart from my Py_InitModule() call, I don't actually do any other prep for the callback/A->B->A-style functions.

The other thing I couldn't solve: I could call a function in Python, but then when it returned I'd lose all the data in Python. I solved this by just staying in Python the whole time and calling needed functions in C++ from Python. It ended up being like an extension, except the environment and engine set up in C++ before the Python was called make embedding better than extending. If the Python values were persistant then I wouldn't have to do it that way, but it worked.

If anything, I've found Python was too keen to hold onto information than too willing to give it up. Could it be related to not bumping up the reference count on certain objects, causing the GC to go crazy on it and discard it? Just a guess. Either way, I'll keep an eye out for things that match these symptoms.

Apart from the gotchyas mentioned, would you say that using Python in an embedded sense was a decision you were happy with, or something you ended up regretting?

Just posting to provide an update on this.

As of a couple of days ago, the time finally arrived where I had to make a call on my embedded scripting environment, and I gave Python a shot based on this thread and in particular Ben's helpful feedback.

It has turned out reasonably well thus far. There were some undocumented frustrations (what is the best way to get feedback back to the people who write the embedded docs?), and I almost gave up on it due to one thing in particular [1], but in the end, I was able to get a basic test case going, that did the A->B->A thing I needed and described. Since then, I've developed a light wrapper to handle some of the more tedious aspects of embedding for me, and got it going in my project under both Linux and Windows, where it works equally well.

It is of course, still very much an internal "test case" (that just runs a few dummy operations), and I won't know how it works in "real life" until I've got it driving the bits of the code that need the scripting, which doesn't fully exist yet. :} But from what I've seen, it looks very promising. My plan at this point is to develop the main code that requires scripting, and increase the scope of what is covered as much as is reliably possible.

I generally like the API- decent reference documentation too. And as for the quality and ease of use of the Python language itself- there are few equals.

Anyway, I'll share a few tips and workarounds in case someone else tries going along the same path. Hopefully I can save someone the few frustrating hours I spent discovering these things the hard way. Note that these are in addition to the documentation, which is reasonable, but incomplete (IMHO):

- (This cost me some very frustrating hours to find out) To load a module from a file, it either needs to be in the PYTHONPATH environment variable already (!), or in sys.path. To, say, load from the current working directory, issuing these commands right after Py_Initialize() will do the trick:
  - PyRun_SimpleString("import sys");
  - PyRun_SimpleString("sys.path.append('.')");
  - IIRC, the file should then be called "foo.py" if you wish to import it as "foo", although I haven't got an easy way to doublecheck that at present.

- (This took some experimenting) If you want to load a Python script from memory (or a string), without it ever ending up on the filesystem, you need these two calls: Py_CompileString(), then PyImport_ExecCodeModule(), using the result of the former.

- (I was lucky on this one) You probably want to issue: "Py_NoSiteFlag = 1;" before Py_Initialize(). If you do not, it'll search for a suitable "site.py" file, which you probably won't always have, unless you include one with your app. You wont always notice this, since it tends to find it on a development environment.

- PyRun_SimpleString() is your new best friend. It runs a single command in the current Python environment, and the results are persistent.

- If you load a module with the same name into the current environment, it will effectively overlay the functions in the same space. However, if you have already done an "import sys" via PyRun_SimpleString(), and then issue a "del sys.modules[\"modname\"]", you'll get a clean import. Note that there are issues with lingering non-visible modules that occur if the module was in use somehow at the time.

- Inside extended functions in an embedded environment, the "self" object may be NULL, and the "args" object is generally a tuple, that you can confirm with PyTuple_Check(), get the size of with PyTuple_Size(), and raid with PyTuple_GetItem().

- If you change the library name under Windows, also update the mention in the pyconfig.h file, or you'll get linker errors. Also, don't forget to copy the pyconfig.h file into the right place when building under Windows.

Hope this saves others a bit of time.

[1] Embedded Python by default will import modules based on the PYTHONPATH environment variable, which doesn't include the pwd and generally isn't set to what you want when embedding, and there's no hint that this is the case- this makes loading your own test module difficult unless you guessed the issue ahead of time.

I would suggest that if the second link doesn't give you any help, you dig around in the code that SWIG barfs out and see how it wraps a C pointer into a PyObject. I think that it may generate functions that will do that

That's a neat idea. I could probably get the appropriate unwrap code in a similar way too.

Thankyou Ben for the detailed description- it has helped immensely. And to top it off, the first link you've provided is PURE GOLD. It's basically a howto of *exactly* what I want to do, and the specific A->B->A case I was after is documented in section 5.4 of the link you've provided. Plus, there are actual code examples. My problem was effectively that I was looking in the wrong part of the manual- it *was* documented properly, I just failed to find it...

The description you've provided has also helped with respect to how I can get some of the local functions in there as well. If I have a great number of them, and my understanding is correct from what you have said, I can use SWIG to quickly get them all in there. Basically the output of SWIG should generate the init_* calls that I need to add, or something very close to that anyway. I'm not sure how I'll go with opaque types, but my guess is that second link is going to give me a hint, and worst-case I'll just pass in integers and map it back to pointers after (which *will* work, is just messy). From the sounds of things, starting off getting the basics going directly with the Python API is going to be the best thing to begin with, and then I can check out SWIG to simplify function wrapping, and I might give Boost::Python a miss for now.

Okay- this is really good news. Quite exciting actually. I'm not used to embedded interfaces actually having decent documentation as a general rule. Ben, thankyou so much for persisting! (for all others: Ben also posted in my original thread trying to help).

With any luck I'll probably be needing to brush up on my Python again.

Now, the last question would be: Has anyone actually done this (with Python specifically), and if so, how did you find it? Any snags or catches to be aware of?

I've recently ported my code to build with MSVC++ 8, and as part of this I directly built every external library I planned to use, being extremely careful to always select the same runtime linking option (eg. either MT DLL Debug or MT DLL Release) for each. In my first attempt I didn't do that, and ran into countless problems. I also used Dependency Walker (free) to check my exes and DLLs to see which DLLs they were actually searching for. It appears to work fine, but who knows what it will be like out in the real world?

In hindsight, maybe I should have looked at just statically linking the darn thing.

nitram_cero: I enjoyed reading that rant, thankyou for the link.

Just curious, but what compiler are you using that allows you to declare main as static?  That's very much illegal, and should result in a program that can't run, since the linker should be unable to find the entry point.

Fixed. Consider the above pseudo-code, to illustrate the thing I am trying to achieve.

I was about to comment that the linked example was extending rather than embedding- and then I scrolled down to section 1.6. I'm having a read through now.

EDIT: Turns out it was just how to call a Python function from C that was already called by Python. So it still seems to be extending rather then embedding- I'm happy to be shown to be wrong though.

EDIT 2: Seems to be a brief mention of embedding on that page starting with the text "When embedding Python", along with a brief example of initialisation, and a reference to some external code that may also be an example. Still lacking a concrete example of the whole thing though, which is frustrating. It's a shame that embedding frequently is approached as an afterthought with these sorts of things. Has anyone succeeded in embedding Python directly in this way?

Thanks for that.

I'm not entirely sure how that example is going to map back to the problem I am trying to solve- this might be because my SWIG knowledge is still very basic. Also, I'm pretty sure that doesn't touch the A->B->A scenario I described. The general question in the link above (and below) provides a better explanation of what I'm after. I don't suppose you've personally done embedding (not extending) of this nature- either just simple Python invocations from C/C++, or ideally the A->B->A style described above or in the link here:

http://forums.tigsource.com/index.php?topic=9707.0

?

Okay, I'm asking a more general question on scripting languages here instead:

http://forums.tigsource.com/index.php?topic=9707.0

I seem to have been fighting this problem for years. I'm wondering if anyone can help. I'm trying to find a embeddable scripting language that will allow me to do this:

In a C/C++ program, set up a scripting environment, load a script (from a file), push some local C/C++ functions into the environment, and then call the script, which may contain calls to the functions I pushed into the environment. Basically:

A (C++) calls B (scripting language) which calls a function in A (C++).

An opaque type needs to be passed in through the chain, and it needs to be able to handle simple things, such as passing around integers, floats, and strings.

Note that being able to include C/C++ code in a scripting language as an extension is *not* enough. I know that a lot of things can do this- it's not what I'm trying to do, and not what I want.

Now, there's a bunch of languages that *might* do it, and tools that *might* help. I'm after something sufficiently advanced that it *specifically* presents a clear and easy-to-use example of this sort of thing in their documentation.

So far, I've got this sort of thing working with LUA, but I'm after other options. Unfortunately, for most things that claim that they can do this, there's minimal documentation and rarely an example of how to do it. Most of the examples end up focusing on extending the scripting language, rather than embedding it in an existing program. I end up sinking a whole bunch of time into trying to figure it out, then find out that I can't *really* do it, the minimal doco that hinted it was possible was actually wrong, or there's some nasty catch that is being glossed over.

Here is a concrete example of what I'd like to do:

*** foo.cpp:

Code:

class Bar
{
  public:

    Bar();
    int foo(int b, int c);
    
    int run0(int e);
    int run1(int e, int f);

    ScriptingEnvironment env;
    int d;

  (other, really complex definitions)
};

// Just an adapter to turn the opaque type back into a class, then
// call a method. I'm assuming the environment handles opaque types with
// (void *).
static int call_foo(void *a, int b, int c)
{
  return ((Bar *)a)->foo(b, c);
}

// The function that may be called from the script after passing through the
// adapter.
int Bar::foo(int b, int c)
{
  return somecomplexfunction(b, c, d);
}

void Bar::Bar()
{
  // Create the environment.
  env = ScriptingEnvironment::create();
  // Add our local adapter function "call_foo", accessible as "foo" from
  // the script.
  env.add("foo", call_foo, "pii") // Pointer, int, int.
  // Load the script from an external file. I don't mind if I have to load
  // first then add funcs, or add funcs then load- works for me.
  env.load("somescript.ext");
  // Any explicit exporting would be done here, if needed.
  env.export("somefunc", "pi");
  env.export("otherfunc", "pii");
}

int Bar::run0(int e)
{
  // Setting "d", which we end up using in "foo" if it is called, but not
  // otherwise.
  d = somemagicfunc(e);
  // We pass in "this" as an opaque type, so that if it calls "call_foo",
  // we can convert it back to the class via the adapter.
  return env.call("somefunc", "pi", this, e); // Pointer, int.
}

int Bar::run1(int e, int f)
{
  d = somemagicfunc(e+f);
  return env.call("otherfunc", "pii", this, e, f); // Pointer, int, int.
}

int main()
{
  // Construct a "Bar" named "bar", which will load the script and do the
  // needed setup.
  Bar bar;
  // Make multiple calls to the loaded script and environment.
  cerr << bar.run0(4) << "\n";
  cerr << bar.run0(5) << "\n";
  cerr << bar.run0(6) << "\n";
  cerr << bar.run1(4) << "\n";
  cerr << bar.run1(5) << "\n";
  cerr << bar.run1(6) << "\n";
}

*** somescript.ext:

Code:

#NB: "foo" is impemented back in the original C++.

# This is called from the C/C++ side.
def somefunc(a, e)
  return foo(a, e) + foo(a, 5)
end

# This is called from the C/C++ side.
def otherfunc(a, e, d)
  return foo(a, e) + foo(a, 6) + foo(a, d)
end

..............


So the question is: Is anyone aware of an embeddable scripting language (apart from LUA) that *can* do this, has personally done it themselves, knows the official documentation has *actual* easy-to-use examples that show the officially-supported way of doing it, and can also recommend it?

Ah:

http://wiki.python.org/moin/boost.python/EmbeddingPython

"Boost.Python does not provide all the constructs necessary for embedding Python in a C++ application"

"Note:  Because there is very little documentation on a lot of this, I am not entirely sure that the methods I am describing are the best to accomplish the task. If there is a better way, please write it up here."

Bugger. Another incomplete solution.

I didn't have many problems with the docs, though I didn't dig very deeply.

I did, however, find it to be rather clunky compared to, say, SWIG (which serves nearly the same purpose, and with which I have more experience). I think that B:: P handles Boost:: shared_ptr better than SWIG, but otherwise they're pretty even functionality-wise. And B:: P requires far more typing, and the templates take forever to compile. I also find SWIG to be cleaner since it doesn't rely on confusing template black magic. On the other hand, SWIG is an additional step in your toolchain that might not be worth it.

So I can't contrast them technically very well, but I can give you the general impression that I got, which is that you should look at SWIG as a possibility if B:: P isn't doing it for you. Hope that helps.

Yes, it has, thankyou.

Interesting. I do use shared_ptr rather extensively already, but I *also* use SWIG a little bit- mostly to export some segments of code that can be run in Ruby scripts- ie. extending rather than embedding. What I'd like to do is the other way around though- embedding a script into my code, rather than setting code up to be called from a script.

Basically if I can do a call from A (C/C++) to B (eg. Python) back to a different function in A (C/C++) that I pushed into the scripting environment somehow, then it's doing what I'm after. Anyway, is this the kind of thing that you worked with? A quick skim of the swig docs seems to give the typical "extending" examples, but skimps on the "embedding". I find that enormously frustrating, and it's why I have to ask rather than just being able to look up the docs for a solution.

I was wondering if anyone has had a look at Boost::Python in the context of embedding a scripting language into a C/C++ game. In this context, what did you think of it?

I know that Python is a quality and mature scripting language (not my favourite, but it doesn't have to be), so that bit isn't a problem. I'm a bit underwhelmed by the poor Boost::Python documentation though- it looks like it might be a good reference, but it's pretty awful for a new user. I'm trying to figure out if it's going to be worth the trouble.

Has anyone undertaken this particular journey before? Was it worth it? What were your experiences, both good and bad?

I should point out that I'm probably not going to be digging into this seriously for a while- I'm just exploring at the moment to find out what other people think of it, so I have an idea if it is likely that I'll be successful if I try to use it.

Another approach is to get everything working with just boxes initially, and go back and add slopes later. That way you can get everything stable, and then make adjustments and improvements later on. If they're a pain at present, I'd leave them out. You may not need them, or might feel more confident implementing them later.

Re special member prefixes (eg. "m_"), I'm in the "don't do it" camp, but to each their own. There are pros and cons. I can work with code that does it, or doesn't. Doesn't bother me that much.

I will slap any non-rookie developer who regularly embeds type information into variable names though.