One of the recent things that I'm starting to learn is python, and it seems really slick for the most part. It doesn't have the control of c/c++ in a lot of ways, but it has a lot of benefits too. For one thing python is portable.
As someone new to scripting languages, I wonder what the pros and cons of building a large scale project like a game engine in a scripting language such as python would be. Would it hinder performance so much that it would be unmanageable for big games?
Scripting language game engines
My qualifications
I've released a commercial game with a scripting language (LUA) embedded. I had some of the same concerns but they worked out relatively well...
C/C++ Binding
Boost::Python does allow better integration of C++ and Python. You should be able to embed python in the application and extend it using modules defined by boost.
When writing my lua bindings (yes I also used luabind) I found it very useful to use boost::bind to create callback methods associated with a specific instance of a class. THis might be LUA specific because Lua has something called a 'closure'.
Performance
As for performance of scripting languages in games, I think you'll find they all boil down to the same simple principles. First, {Python, Lua, etc...} allow you to compile the script files into byte code. This increases performance(however, one minor release of my last game slipped out with non-compiled files because no one noticed a performance hit).
The trick is in how you use the scripts. It's a good idea to setup some sort of callback system for the program to forward and receive events from the script.
It's a bad idea to put any sort of rendering thread in script.
It is possible to have an update function in script but it should run at a relatively low rate and probably only check goal states (not continuous animation). You should be able to fire off a timer that automatically runs a callback after X milliseconds. If the callback returns true, then the timer will fire again. If it returns false, then the timer is removed from the system.
State Machines
Try to think of the script as a state machine. It can receive and generate events in the form of callbacks. A lot of code will still run on the C++ side, just some of the decisions are made in script.
Try to keep script side states in a larger, single table. It's temping to have a ton of little 'bool's and 'int's here and there sprinkled in your code, but when it comes time to implement the save/load mechanism you'll find yourself pulling your hair trying to pickle everything.
Setup Code
You'll also find it quite handy to do certain setup in scripts. It's best to keep this code separate from the state machines. The state machine's ..state... will be saved/loaded but the setup files will always run in the same manner.
I've released a commercial game with a scripting language (LUA) embedded. I had some of the same concerns but they worked out relatively well...
C/C++ Binding
Boost::Python does allow better integration of C++ and Python. You should be able to embed python in the application and extend it using modules defined by boost.
When writing my lua bindings (yes I also used luabind) I found it very useful to use boost::bind to create callback methods associated with a specific instance of a class. THis might be LUA specific because Lua has something called a 'closure'.
Performance
As for performance of scripting languages in games, I think you'll find they all boil down to the same simple principles. First, {Python, Lua, etc...} allow you to compile the script files into byte code. This increases performance(however, one minor release of my last game slipped out with non-compiled files because no one noticed a performance hit).
The trick is in how you use the scripts. It's a good idea to setup some sort of callback system for the program to forward and receive events from the script.
It's a bad idea to put any sort of rendering thread in script.
It is possible to have an update function in script but it should run at a relatively low rate and probably only check goal states (not continuous animation). You should be able to fire off a timer that automatically runs a callback after X milliseconds. If the callback returns true, then the timer will fire again. If it returns false, then the timer is removed from the system.
State Machines
Try to think of the script as a state machine. It can receive and generate events in the form of callbacks. A lot of code will still run on the C++ side, just some of the decisions are made in script.
Try to keep script side states in a larger, single table. It's temping to have a ton of little 'bool's and 'int's here and there sprinkled in your code, but when it comes time to implement the save/load mechanism you'll find yourself pulling your hair trying to pickle everything.
Setup Code
You'll also find it quite handy to do certain setup in scripts. It's best to keep this code separate from the state machines. The state machine's ..state... will be saved/loaded but the setup files will always run in the same manner.
-James
Best possible pro vs con of python I can give or have heard was that: (Might not apply for vers. 3.0 and up, mind you)
Pro: Probably the best scripting language you can find out there. Easy, stable, versatile, well develloped, integrate well.
Con: EACH FRIGGIN VERSION BREAKS BACKWARD COMPATIBILITY! That is a VERY bold point. Multiple versions installed on c:/ gives it a look of infestation.
But apart from that, it's a great scripting language.
Pro: Probably the best scripting language you can find out there. Easy, stable, versatile, well develloped, integrate well.
Con: EACH FRIGGIN VERSION BREAKS BACKWARD COMPATIBILITY! That is a VERY bold point. Multiple versions installed on c:/ gives it a look of infestation.
But apart from that, it's a great scripting language.
Yeah, if you embed the python interpreter into the program, then it doesn't matter about backward compatibility.
LOL, I do remember this problem when I was learning/testing out Python. I eventually discontinued pursuit of Python because my Lua was already working, but I will say that python looks like a more powerful language.
I found a Python book in my parents house. Nobody knows how it got there (I think my sister left it), but there it was; this mysterious book. So I started reading the book and couldn't put it down: It really is a great language, I'm not surprised about the following it has garnered.
LOL, I do remember this problem when I was learning/testing out Python. I eventually discontinued pursuit of Python because my Lua was already working, but I will say that python looks like a more powerful language.
I found a Python book in my parents house. Nobody knows how it got there (I think my sister left it), but there it was; this mysterious book. So I started reading the book and couldn't put it down: It really is a great language, I'm not surprised about the following it has garnered.
-James