Hello I'm in the process of looking for solutions on how to embed a scripting language into my game, and I thought python would be nice since I have some experience with it and I really like it. But before I start I would like to get some help with understanding some things. Here are the things I'm wondering about: - Is it possible to compile a small python interpreter INTO your application? I'd very much like it this way because I am planning on showing my game to my not so computer-savvy friends/girlfriend, and it'd be much better if I could just tell them to "copy this folder to your hard drive and click the executable" than having to tell them to first install a python interpreter and THEN run my game. - The python.org embedding tutorial says something about python trying to figure out my module path. I suppose this is kind of the same question but I would like python to use only the compiled in modules, or the ones that I supply myself through C++. Can I disable this? - Boost.Python seems quite nice (especially since I already use (b)jam to build my projects), but I can't seem to find anything about embedding python with it, only extending it. Would you recommend Boost.Python when embedding python? Would you recommend it at all? Any other thoughts on alternative scripting languages or approaches to my "problems" are greatly appreciated. What I'm planning on using it for is GUI customization (i.e I execute a python-gui-file that creates all my GUI components and handles their input etc), running my game level editor, and AI for my game characters. Thank you for your time :)

Quote:Original post by moussen15
- Is it possible to compile a small python interpreter INTO your application? I'd very much like it this way because I am planning on showing my game to my not so computer-savvy friends/girlfriend, and it'd be much better if I could just tell them to "copy this folder to your hard drive and click the executable" than having to tell them to first install a python interpreter and THEN run my game.

Yep. Alternatively, I believe that there are tools which will compile your python into an executable-ish form... that is, they won't be native object code, but there will be a .exe and you don't need a standalone interpreter.

Quote:- The python.org embedding tutorial says something about python trying to figure out my module path. I suppose this is kind of the same question but I would like python to use only the compiled in modules, or the ones that I supply myself through C++. Can I disable this?

IIRC, embedded Python doesn't do this search when invoked from a host program unless you tell it to.

Quote:- Boost.Python seems quite nice (especially since I already use (b)jam to build my projects), but I can't seem to find anything about embedding python with it, only extending it. Would you recommend Boost.Python when embedding python? Would you recommend it at all?

Boost.Python talks about extending rather than embedding simply because pure embedding is easy and you don't need any tools for it. When we talk about embedding, though, we usually don't just mean "embedding" as in having a naked Python interpreter in your program to execute pure Python scripts, but rather a combination of that and "extending" the embedded interpreter to be able to do things with your program rather than just doing its own thing. That latter part is the difficult part, and it's what Boost.Python will help you with. Personally, I prefer SWIG aesthetically to Boost.Python, but either will work for this.

Quote:What I'm planning on using it for is GUI customization (i.e I execute a python-gui-file that creates all my GUI components and handles their input etc), running my game level editor, and AI for my game characters.

It's a good use for an embedded high-level language. In terms of GUI toolkits, though, you really owe it to yourself to check out the existing offerings (many of which embed scripting languages) before rolling up your sleeves and making it from scratch. Designing and programming a GUI toolkit is a particularly difficult, involved, and thankless task, and unless you have lots of experience with programming GUI toolkits already, the result will be considerably less flexible and usable than a premade toolkit.

1) Yes, though it's more traditional to ship the python DLL with your application.

2) Yes, you can modify sys.path.

3) I use boost::python for embedding. I've written a basic tutorial for it here.

Allright, thank you both for your answers. You have been very helpful. I didn't know I could just ship the DLL (as SiCrane mentioned). That seems like a smart solution (no need to install any additional software if I just pack the python interpreter DLL along with my other game files). This might be a dumb question but I searched the python documentation once more but didn't find any obvious mention as to whether this was what they recommended when embedding python. This is of interest because otherwise these questions come to mind: Will I have to build this DLL myself or are you saying that it already exists and that I should just go into my python install path and grab it from there?

Quote:Part of Sneftel's reply
It's a good use for an embedded high-level language. In terms of GUI toolkits, though, you really owe it to yourself to check out the existing offerings (many of which embed scripting languages) before rolling up your sleeves and making it from scratch. Designing and programming a GUI toolkit is a particularly difficult, involved, and thankless task, and unless you have lots of experience with programming GUI toolkits already, the result will be considerably less flexible and usable than a premade toolkit.

I've looked into a couple of GUIs but I most of them are waaay too complex for me. What I have right now is a std::list of GUIItem-interfaces that have three methods of significance:
-update() handles input and all logic associated with the given GUI component
-draw() displays it to the user
-sendRequests() lets it commonicate with its "engine" (right now there are only 3 requests: TO_FRONT, TO_BACK, REMOVE.
Do you still think I should search for already available "GUI toolkits"? This doesn't seem like a whole lot of work to me (I have yet to start implementing any GUI components. I just finnished the design and the engine) but I might be wrong seeing as this is the first time I use a GUI in my game really. Also I think it'd be a good learning experience to embed and use python myself this way.

Oh and I should thank you once again, SiCrane, for your tutorial. It will be of great use to be :)

[Edited by - moussen15 on August 19, 2006 3:37:38 PM]

Hi

Shipping your exe with the good Dll is definitively the way to go.
If it still bothers you, one solution is also to link with python as a static library, but it involve tweaking python to create this library, for quite no gain.
You can find the python Dll in your system32 windows directory. Grab it from there ( it is named python23.dll, python24.dll, according to the version ).

As for the rest, SiCrane has already done most of the job. His tutorial is great.
One other great tutorial is there :
http://www.ragestorm.net/tutorial?id=21
http://www.ragestorm.net/tutorial?id=25 (second part )

As saying by other posts, embedding is really easy. But you will need to have your python script call your C engine also, and this is the most complex part.
Boost is there to help you with this task. Swig is another option, although perhaps less friendly ( involving some post-compiled steps ).

Last thing tricky is to find a good debugger.
First step is to have access to the python stderr ( the tutorial explain this step ).
For real debugging of embedded python, I found two tools : HAP and WinPdb.
Neither of the two are perfect for me, but it's far better than nothing.

Hope it helps,

Emmanuel

Quote:Original post by moussen15
I've looked into a couple of GUIs but I most of them are waaay too complex for me. What I have right now is a std::list of GUIItem-interfaces that have three methods of significance:
-update() handles input and all logic associated with the given GUI component
-draw() displays it to the user
-sendRequests() lets it commonicate with its "engine" (right now there are only 3 requests: TO_FRONT, TO_BACK, REMOVE.
Do you still think I should search for already available "GUI toolkits"? This doesn't seem like a whole lot of work to me (I have yet to start implementing any GUI components. I just finnished the design and the engine) but I might be wrong seeing as this is the first time I use a GUI in my game really. Also I think it'd be a good learning experience to embed and use python myself this way.

The reason that GUI toolkits tend to be complicated is that they straddle the code/data line. Is a window layout data, or code? Tbhe fact that virtually all languages are better at that than C/C++ is why scripting languages so often come up in that context. But there is still a great deal of complexity in front of you. Those premade toolkits aren't complicated just for the hell of it: They're complicated because it's a complicated task. Also keep in mind that if you find the toolkits you have seen complicated, getting to know them will be a good learning experience. (Never underestimate the value of being good at absorbing and applying outside libraries-- it is a crucial skill for game developers.)