Last weekend I finally decided to look into a long standing issue. Integrating a scripting system into the engine. There is no denying scripting systems add immense flexibility to a game engine and I intend to provide one to the O2 Engine as well. A little bit of history into scripting system for the O2 Engine; we had decided to integrate a script system for the Doofus game very early on, in the design spec itself, but dropped it later when it was found that a lot more was needed than was initially planned. A simple scripting system is very easy to integrate into the engine, but such an effort would have offered limited functionality. Though it was initially planned to have a very basic system for the engine, it was quickly realized during implementation that such an endeavor would be a folly. The O2 engine is an Object-Oriented monster and to have a superficial scripting system would not provide any substancial value addition to any future game creation process using the engine.

The main aim of any scripting engine should be to allow rapid development and in some cases rapid prototyping of game and game design ideas. This is where the problem lies. Any game created with the engine needs not only to interface with the engine code but also interface with the engine design. Game engines often have modules that interact with one another in specific and predetermined ways. This is where an engine is different from a framework or a library. An engine offers a higher degree of design abstraction than even a framework would. Not only are most of the design decisions already made, some of the implementation decisions are also made for you. This not to say that an engine can’t be flexible, in fact it has to be. You will never be able to create a game with it if that were the case. Engines allow for explicit flexibility, meaning flexibility has to be designed into an engine. Parts that need flexibility need to be designed to provide such and parts that don’t have to be abstracted away or totally hidden. A scripting system must be able to expose not only flexible elements of the engine but also expose the design of the modules and the interaction between them. Ideally it should extend the engine.

The one engine that does this with amazing effect is the Unreal engine. It has its own scripting language called Unrealscript. There is little doubt that the Unreal engine is probably the best game authoring system out there and this is partly due to the fact that it has an amazing scripting language. Tim Sweeny has a nice article on how the scripting language was designed, and he addresses some of the issues I have pointed out here. It is a must read if you plan to make a scripting language one day. It is probably beyond me currently to create and maintain a dedicated scripting language like Unrealscript for the O2 engine (maybe in the future), but that is probably the best solution to the problem. My best bet is probably picking up an existing scripting language and integrating it with the engine. There are quite a few of them to choose from, each having their merits and demerits. The ones that I am interested in are Python, Lua, AngleScript, Squirrel, GameMonkey. I plan to evaluate each one before deciding on the language to be integrated.

Last weekend I tried to integrate (my favorite scripting language) Python. Unlike the other languages, Python was never designed to be an embeddable language. It is more of a heavy weight application development language and probably will have the largest memory footprint among the others. I have also heard that it is slower than Lua and Squirrel. (I have no data to actually prove that yet, this is just hear say I got from Googling around.) It is however extremely popular and very powerful language. To be honest, I have a long history with Python and it was almost 5 years ago when I first picked it up, I have been Python fan ever since. Anyways, integrating Python using SWIG was easy. I have thus far only tried as small example, but everything went smoothly. O2 Engine however is totally another ball game. The engine has heavily templatized classes, which I am sure are going to be a pain to integrate. I also tried Boost.Python and it seemed even simpler, but needed a little more glue code.

This weekend (or whenever I get time) I will continue the integration exercise with Python. Then maybe move on to Lua and others. More information about that in Part 2.