T
The_Incubator
As the subject suggests, I am interested in using Python as a scripting
language for a game that is primarily implemented in C++, and I am also
interested in using generators in those scripts...
Initially I was justing looking at using Python for some event
scripting. So basically an event would trigger an object to run the
appropriate Python script, which would be run in it's entirety and
return control to the C++ code.
After looking at the Python docs and a few articles I've found, I'm
really excited by the idea of using Python generators as micro-threads
for game AI. I've been playing around writing play Python applications
with classes that use generators as update methods, and it's cool as
hell. I've also managed to write a C++ program with an embedded Python
interpreter than runs a script, and I've used the Boost Python library
to expose some C++ functions to Python.
Where I would like to go from there is to be able to associate a Python
script with a C++ object, so that on every frame update I could run the
Python script (which would have functionality implemented as a
generator) until it yields, then move on to updating the next object,
and on the next frame, have the generator continue from where it left off.
I haven't really attempted this yet, because I'm not quite sure where to
start. I'm not sure how to have a Python script persistently attached to
a C++ object so that execution can be returned to C++ from a yield and
continue where it left off on the following update cycle. I am beginning
to suspect, based on the docs and articles I've read, that to get this
sort of functionality I should be looking at exporting all my C++
objects to Python, and then using Python as the glue to write the main
loop of the application, calling out to the C++ objects as required. Is
this assumption correct, or can I get the functionality I want while
still keeping this a C++ application? Should I be looking at writing the
AI modules as Python objects and attaching these to my C++ objects at
runtime?
Initially I was just looking for something to use for simple scripting,
and we were planning to do a custom scripting language, but I know just
enough about language design and implementation to be very weary of
having to maintain our own language when there are proven embeddable
languages out there than are more powerful (and if I wanted to stick
with simple I'd use Lua, which was just a breeze to embed). But the more
I look at Python, the more ambitious I'm getting about how much we could
potentially do by using Python at least as a scripting language and
possible as glue... however, I'm not necessarily sure we need all this
functionality (generators included), but that doesn't mean I don't want
it, and I do like the idea of having more power and flexibility than is
strictly necessary, so that we will have the power to do things we
didn't necessarily plan for or expect. We are using Gamebryo as our
rendering library, so that is a major constraint. That is very much a
C++ library, so this is very much a C++ application. I am also a bit
concerned about scaring other developers on my team... We need a
scripting language, and everyone can deal with that as long as we
pretend that the scripting language is a separate thing for designers,
but I'm afraid if I start suggesting the programmers write our main
application in Python and export the C++ code, I'm in danger of becoming
a heretic
I'm not even sure if that's practical, given our C++
middleware and performance concerns, but that's why I'm posting here, to
get some assistance from the experts.
Thanks in advance for any advice
Nick
language for a game that is primarily implemented in C++, and I am also
interested in using generators in those scripts...
Initially I was justing looking at using Python for some event
scripting. So basically an event would trigger an object to run the
appropriate Python script, which would be run in it's entirety and
return control to the C++ code.
After looking at the Python docs and a few articles I've found, I'm
really excited by the idea of using Python generators as micro-threads
for game AI. I've been playing around writing play Python applications
with classes that use generators as update methods, and it's cool as
hell. I've also managed to write a C++ program with an embedded Python
interpreter than runs a script, and I've used the Boost Python library
to expose some C++ functions to Python.
Where I would like to go from there is to be able to associate a Python
script with a C++ object, so that on every frame update I could run the
Python script (which would have functionality implemented as a
generator) until it yields, then move on to updating the next object,
and on the next frame, have the generator continue from where it left off.
I haven't really attempted this yet, because I'm not quite sure where to
start. I'm not sure how to have a Python script persistently attached to
a C++ object so that execution can be returned to C++ from a yield and
continue where it left off on the following update cycle. I am beginning
to suspect, based on the docs and articles I've read, that to get this
sort of functionality I should be looking at exporting all my C++
objects to Python, and then using Python as the glue to write the main
loop of the application, calling out to the C++ objects as required. Is
this assumption correct, or can I get the functionality I want while
still keeping this a C++ application? Should I be looking at writing the
AI modules as Python objects and attaching these to my C++ objects at
runtime?
Initially I was just looking for something to use for simple scripting,
and we were planning to do a custom scripting language, but I know just
enough about language design and implementation to be very weary of
having to maintain our own language when there are proven embeddable
languages out there than are more powerful (and if I wanted to stick
with simple I'd use Lua, which was just a breeze to embed). But the more
I look at Python, the more ambitious I'm getting about how much we could
potentially do by using Python at least as a scripting language and
possible as glue... however, I'm not necessarily sure we need all this
functionality (generators included), but that doesn't mean I don't want
it, and I do like the idea of having more power and flexibility than is
strictly necessary, so that we will have the power to do things we
didn't necessarily plan for or expect. We are using Gamebryo as our
rendering library, so that is a major constraint. That is very much a
C++ library, so this is very much a C++ application. I am also a bit
concerned about scaring other developers on my team... We need a
scripting language, and everyone can deal with that as long as we
pretend that the scripting language is a separate thing for designers,
but I'm afraid if I start suggesting the programmers write our main
application in Python and export the C++ code, I'm in danger of becoming
a heretic
I'm not even sure if that's practical, given our C++ middleware and performance concerns, but that's why I'm posting here, to
get some assistance from the experts.
Thanks in advance for any advice
Nick