Spring is almost here. There are a lot of birthdays in my family in the month of March, so it's always a busy time. Spring is in the air, and with it themes of renewal and rebirth. When I first started coding what would later become the base for the rendering components of the Troglodyte Game Engine, it was first called Phoenix. Phoenix was fitting and is fitting for any type of software development as it is a process full of re-iteration and rebirth, but Phoenix is an all too common name and that was one of the decisions in the eventual renaming of the engine.
So, at this point of the engines development, I am going to visit Scripting With Python. I am going to write a series of entries covering the interface development and host API for the engine over the next few weeks. This should help keep me on track and hopefully may provide some helpful hints to anyone looking to dive into the subject matter. If not, it at least keeps me on the cutting edge of typing ;P.
[color="#f0e68c"]Embedding Python - Squeezing snakes in tight places.[/color]
Python allows for two ways of communicating with C/C++. You can have your python application call c functions, this is referred to as extending python, or you can have your C++ app call python functions and have the execute logic on C++ Objects. That is what Troglodyte is designed to do, and what I will be working on over the next few weeks. The process, as I will explain in more detail, can be quite involved. You basically have to change data types between C++ and Python, and for functionality that is somewhat complicated, this may have to happen multiple times for one call. So there is some over head involved in this process. In the end however, it will allow for the python interpreter to update data in real time and will ultimately eliminate the need to recompile the engine every time we change data for a sprite or in game object. It is also my goal to have a modular approach for the functionality of the in engine editor, having the editor being scriptable and allowing functionality to be added and updated at run time.
So, what types of things should be exposed to python? The short answer, things that are dynamic and need updating. This current pass of scripting interfaces is being somewhat streamlined with just the high end objects being scriptable. At the highest level of in game objects is our Sprite Class. Not only does our sprite class need to be exposed to python, it needs to be expandable through python. Meaning that we should be able to specify functionality that isn't inherently part of the Sprite class but that a specific instance can execute depending upon the desired action called by the script.
[color="#f0e68c"]Now For SSSSomething Completely Different[/color]
The Sprite class in all of it's glory is the highest non-game specific class in the engine. It goes through various levels of inheritance starting with the ABT TObject. The Sprite class makes use of texture, audio, spacial translation, animation, and object serialization features. This makes it an ideal point to concentrate on for beginning the scripting process.
When you setup a call to python in C++ every single piece of data that is sent to and received from python must be a PyObject * . In order to make use of the data in C++ from python it has to be converted into the desired data type.
[color="#f0e68c"]To Be Continued[/color]