Assorted comments, mostly quoting Trapper Zoid...

Quote:There's two questions I'm unsure of: whether it's better to aim for embedding Python within the library or extending Python with the library; and if extending, whether to plan for using C++ or C for the code.

I'm going to say extending is better.

Firstly, Python simply is not designed to be embedded. There's no getting around that - the API has lots of global state, subinterpreter support is barely existent and not maintained, you typically have to recompile the Python DLL to match your current runtime (including building a debug DLL), etc.

Secondly, it goes against normal software wisdom to write the main part of your app in the lower level language and then to add a higher level language on top. <speculative>These bolt-on solutions probably originated in things like Excel where the need for user-defined formulae grew into scripts, and have crossed over to become prevalent in game development thinking because we are unable to give up the C++ legacy for various reasons.</speculative> Yet developers without such legacy code to worry about will almost always prefer to code in the most expressive, most high level language available, and then drop down to lower levels to optimise, if and when needed.

Quote:If extending, I'm also not sure whether it would be best to use C or C++ as my language of choice for the library functions.

It's not really an issue. If you use a helper library to extend Python, it'll sort that out for you. If you don't, you'll be binding C functions through necessity. (Probably wrappers for your C++ functions.) Or just build them as .dlls and load them via ctypes.

Quote:

Quote:There are downsides to this. In addition to the points in the article you mentioned, multiple threads and embedded Python do not mix well.

Me too; my apps haven't been advanced enough for me to worry about multi-threading. Consider everything I plan to do to be single-threaded for now.

Yet Python offers ways to make the move to multi-threading quite easy, eg. the queue module. That's one of the many benefits of working in Python.

Quote:

Quote:Also, the Python community isn't very friendly to people who embed rather than extend, so getting help from them can be an exercise in frustration if you embed.

That sucks; is there a strain of elitism in the Python community?

It's a community of Python users, who presumably like using Python and consider it the best tool for many tasks. If you go in there asking them how to use the language in a way it wasn't designed for, and as essentially subservient to a language that (a) they are less qualified to help with, and (b) is probably worse for many of the tasks you'll put it to, then they're less likely to be able to offer you anything positive. They will probably be a bit frustrated because if you chose to use it the 'proper' way, they could provide more help.

Trapper Zoid,

I thought PyCap might be right up your alley, or at least interesting to you.

Both the games on the website and the sample game in the download are using the PyCap library (Python bindings for the PopCap Framework).

http://www.farbs.org/pycap.html

It has a fishie game (you made that fishie game right?)

Quote:Original post by Boder
It has a fishie game (you made that fishie game right?)

What, another one button fish game! Must be a catching trend...

Thanks for the link; I'll look at that later. Unfortunately I'm currently using Mac OS only, so I can't use PopCap. I'm planning on starting with simple ASCII games until I've got the basic Python data structures down pat, then I'll move on to something with graphics.

I would recommend Game Programming with Python. I originally picked it up hoping it would have some info on embedding/extending python, it does but its buried at the back of the book, and to get a grasp of what python was about. It uses PyGame throughout which may be more up your alley. Its fairly informative and an easy read.

Also saw this Beginning Game Development with Python and Pygame which is more recent. Not sure if its good but it seems to be getting decent reviews.

Hi,

I already said this here, but I've made a little C/Python engine, with embedded python.

And my principal grief against embedding is that I miss a real Python debugger in my appli.

In the past, I had succes with SPE and HAP, but the process is quite heavy so I tend to always launch the game without any debugger, and to debug with printf.
I have the feeling that by extending, you can always launch from the IDE / debugger, and you have access to much more convivial IDEs.

If I had time, I would change my engine to be able to switch from a extended version to an embedded one. It doesn't look that difficult to support the two.

Hope it helps,

Emmanuel