Adding script support to an engine has many benefits such as writing game play code without recompile the engine source code which may takes a long time. It also can draw a much clear boundary between the game code and the engine code. I chose to use Lua(ver. 5.1.4) as it is easy to embed and its size is small. As I am no expert on Lua, I would like to write about what I have learnt on how to bind Lua and C/C++.

Calling C function from Lua
First, you need to create a lua_State*, where all Lua operations are done within it, by lua_open() (or you may use lua_newState() if you need to hook up your memory allocator to Lua.)

lua_State* luaState= lua_open();

Lua and C can exchange data through a virtual stack. Both Lua and C can push and pop data from or to the stack. Say, we have already register a C function for Lua to use with function signature:

function drawText(str, screenPosX, screenPosY);

then in Lua side, when the following Lua script is executed:

textWidth= drawText("Ready Go~", 240, 160);

3 values will be pushed to the Lua Stack:

We can get the values from the stack in C using an absolute index counting from the bottom of the stack (start from 1) or a relative index to the top of the stack (start from -1).

Then we can retrieve the values in stack inside the C function called by Lua with the following code:

(You may also use lua_pcall() instead of lua_call() to get more debug info when error occurs)
The above C codes is equivalent to calling a function in Lua:

initEngineConfig("18th Aug, 2011");

We can also use similar technique to execute an object's method in C. For instance, we can call an object's method in Lua:

gameObjectA:update(timeSlice);

We can do this in C too. In Lua, the colon syntax is just a short form for writing the statement:

gameObjectA.update(gameObjectA, timeSlice);

So, we need to push the 'update' function of 'gameObjectA' onto the Lua stack with 2 arguments:

lua_getglobal(luaState, "gameObjectA"); // for getting the 'update' function of 'gameObjectA'

lua_getfield(luaState, -1, "update");// get the 'update' function of 'gameObjectA'

lua_insert(luaState, -2); // swap the order of "gameObjectA" and "update"

// so that "gameObjectA" becomes an argument

lua_pushnumber(luaState, 1.0f/30.0f); // push the timeSlice argument on the stack.

lua_call(luaState, 2, 0);// execute the functions.

This is basically how Lua interacts with C, but you also need to know how to represent C structure as user data or light user data. You may also need to know LUA_REGISTRY_INDEX for creating a variable in C without worrying conflicts in variable name. After knowing these things you may want to try some binding library to generate the binding. But I hope these little binding methods can help someone who want to bind Lua and C on their own.

Tools are very important in game production, especially when you are working with someone who cannot write code. In my project, I worked with 2 artists, so I need to write some tools to export their models to my engine. There are different choices to export the models, you can parse.obj file format(for static model only), reading .fbx file using FBX SDK, reading COLLADA files... But I choose to extract it directly from the modeling package that the artists use - Writing Maya plugin to extract the model data.

To write Maya plugin for exporting models, we should know how data are stored in Maya first. Basically, Maya stores most of its data (e.g. meshes, transformation...) in a Directed Acyclic Graphic(DAG). In my case, I just need to locate those DAG nodes that store the mesh data. We can traverse the DAG using the iterator MItDag like this:

MStatus status;

MItDag dagIter( MItDag::kDepthFirst, MFn::kInvalid, &status );

MDagPathArray meshPath;// store the DAG nodes that contains mesh

for ( ; !dagIter.isDone(); dagIter.next())

{

MDagPath dagPath;

status = dagIter.getPath( dagPath );

if ( status )

{

MFnDagNode dagNode( dagPath, &status );

// Filter out the DAG nodes that do not contain mesh

if ( dagNode.isIntermediateObject()) continue;

if ( !dagPath.hasFn( MFn::kMesh )) continue;

if ( dagPath.hasFn( MFn::kTransform )) continue;

meshPath.append(dagPath);

}

}

then, we can get the mesh data in the DAG nodes using the MFnMesh like this:

Another reason I choose to write plugin instead of parsing .fbx/COLLADA is because of extracting the animation data. In my project, I just need to export some simple animations which linear interpolates between key frames, and I would like to get the key frames defined by artists in Maya. I have tried using the FBX SDK but when exporting animation data, it bakes all the animation frames as key frames... Using COLLADA get even worse because I cannot find a good exporter for Maya on the Mac platform... So writing Maya plugin can get rid of all these problems and get the data I want. I can also write a script for artists to set the animation clip data:

After exporting the mesh data, I think it would be nice to edit the collision geometry inside Maya, so I have written another plugin to define the collision shapes of the models:

This plugin works similar to the Dynamica Plugin (In fact, I learnt a lot from it.), except mine can just define simple shapes with only spheres, boxes and capsule shapes. And my plugin cannot do physics simulation inside Maya, it is just for defining the collision shapes. Those collision shapes (sphere/box/capsule) are just sub-class of MPxLocatorNode by overriding the draw() methods with some openGL calls to render the corresponding shapes.

In conclusions, extracting mesh data directly from Maya is not that hard. We can get all the data such as vertex normals, UV sets and key frame data from Maya and do not need to worry about the data loss during export through another formats, especially animation data. Also Maya provides a convenient API to get those data and it is easy to learn. After familiar with the Maya API, I can also write another plugin to define the collision shapes. Next time when you need to export mesh data, you may consider to extract them directly from the modeling package rather than parsing a file format.