Michael Torrie wrote:
And such bindings may need to be two-way. For example in Python code you may want to instantiate some new instance of game object, and you'll need to make sure that the wrapper code will create the appropriate in-game object.
Another thing that can be tricky about this is object lifetimes. Python uses reference counting and garbage collection to manage the lifetime of its data. If your game engine has its own ideas on how to manage lifetimes of its data structures, you may have difficulties. Typically you end up with a situation where each game object has an associated "shadow" Python object, with the two joined together like siamese twins. You need to worry about keeping the Python object alive as long as the game object is alive and vice versa -- while making sure that they don't keep each other alive forever. If you have enough freedom, you may find it easier to turn the problem around -- instead of embedding Python in the game, embed the game in Python. Implement the game engine as a Python extension module, where the game objects are all inherently Python objects, and Python is responsible for all of the lifetime management. All the above headaches then go away, and a bonus you get to write all the high-level logic of the game in Python. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
