Selecting a scripting engine – Part 3.

Some more RnD on scripting languages. This is the 3rd part of the series, the first 2 parts [1] and [2]. I generally do all the RnD on this when I take time away from working on the current game or I am generally bored or stuck on a bug somewhere. This time I focused on Python again and also tried something with Squirrel. Both are very different languages and each one has different challenges to overcome. I also took a dig at something I haven’t touch before and that is C#, yes, as a scripting language.

Python is general is very good as an extension language. You could bind all your code with python and then use only python to code your entire game. Python is clearly designed as heavy duty application development language and embedding it is not what is recommended. While you could very well do so, I found it to be rater clunky and non-intuitive, that’s not to say it can’t be done. So I focused primarily on “extending” and not “embedding” while working with python. There is no real advantage or disadvantage to either method, but I rather want to carry the O2 engine in the direction of “extending” too keep the engine accessible to people who have no, or limited knowledge of C++.

This time I focused on Boost.Python more than SWIG. I haven’t benchmarked anything as yet, but I guess any overhead via bindings would mean a small (, or minuscule) decrease in speed. That doesn’t really bother me since most of the heavy duty calculation stuff will be done in the C++ libraries anyways. However what bothers me is the maintenance and scalability of the binding code. Any binding code is difficult and uninteresting work. It is something that I know programmers will hate to do and it is something that will have to be done time and again as and when the engine scales. Another thing is time. It takes ridiculously large amount of time to write large portions of binding code. That is where I think Boost.Python edges out slightly over SWIG, hello to the Py++ bindings code generator!

Apparently the code generator parses C++ code to GCC-XML and then uses the XML to generate the bindings. It seems too good to be true, but that is what it does. To be fair I have only tried a very small program with it and I have no clue about larger programs. I might try something larger with Py++ this weekend, again, maybe. However, larger projects like PythonOgre already successfully use it so I don’t think it will be too much of a problem with the O2Engine. Check out the next in the series for that.

Squirrel is a lightweight language, much lighter than Python and supports all modern programming features. “Squirrel is a high level imperative/OO programming language, designed to be a powerful scripting tool that fits in the size, memory bandwidth, and real-time requirements of applications like games.” I experimented a lot with squirrel for the past couple of weeks. The language is cool, there are no two opinions to that. It is all what they say it is and more. It tastes like an embeddable language but I am sure it will do an equally good job at extension. In someways it is a lot better than python. For one it is designed to be embeddable while python is not. It has a much smaller memory footprint and, even though I have no numbers to prove, it must be faster than, or at least equal in speed to python.

The big negative part of this language is it’s bindings. Seeing the binding code will make you cringe! It is hopelessly complicated, almost impossible to understand at times. Binding even a small piece of code with about 5 classes took me over and hour, and those classes were not even extensive. I hate to think what will happen while integrating a heavily templatized game engine! For some reason the bindings have to be integrated into classes themselves and even if you did bypass that, it is not clean at all. A lot of glue code needs to be put in, too much I think. While there are binding systems like SQPlus and jkBind, bindings in Squirrel are non trivial. jkBind is particularly interesting and easier than SQPlus, but even then it misses out on functionality that is critical to extending any language. Scaling any such binding system on a large live project having multiple developers will be a nightmare.

If the binding systems were improved, Squirrel would have been my choice hands down. Having said that, I am currently not discounting any language outright. Choosing a scripting language can be tricky and my choice could very have a significant consequence in the future.

C#: (& Mono)
Ah! So I finally got around to having a go at this language. I have only tried a couple of things thus far but I am already impressed. First, C# is by no means a scripting language. OK to be clear I have never used C# before, just had some fleeting glimpses at it, but never worked on any project involving C#. It is a full fledge high level language and is very very powerful, but I bet you already knew that. Extending C++ code using the Microsoft compiler is easy, maybe not as trivial as Py++. One thing I can say for certain is C# is faster than Python. I am not so sure about Squirrel but I bet it must be a little bit faster to that as well. I won’t go into too many details just as yet because I still want to do some more testing and extending before I make some claims. So more on C# later.

In my next part of this series I will try and post some timing values. Timing values will allow for better comparisons of languages and binding systems. I will also try and post some binding code. That will just give a better overview of the task and effort required to have a binding for a language.

The GUI of choice for cross-platfrom development – wxPython.

I just finished off a small project in wxPython and I must say I am pretty impressed with the library. A couple of weeks back I had to do a small assignment (, not relating to the game or the engine I am currently working on) which required a fairly amount of GUI. The specification of the project demanded that the software be able to run on Linux, Win32 and Solaris. Solaris support however, was later dropped due to time constraints. It was a pretty small project (, considering of course I am working on the engine and the game for well over 2 years now). About a sum total of 5 days of work in the end. I was a bit hesitant to take on the work initially but changed my mind once it was decided that Python and wxPython was OK.

I’ve been meaning to take wxPython for a ride for a while now and this seemed like the perfect opportunity. If you have read my Selecting a scripting language articles (1 & 2) you will know I have a secondary interest in working on Python. I am looking to integrate Python into the engine. This just gave me an opportunity to have a look at the wxPython code and bindings in detail. That actually is a totally different topic in itself and I will go in to further details in the third part of the series (whenever I get around to writing it, probably soon). Coming back to wxPython, it’s been about 2 years since I worked on wxPython and I liked it then and I like it now.

Today wxPython is probably the best python GUI according to me. I haven’t worked with PyQt but I had tried messing around with PyGTK. PyGTK to be fair is kinda OK, but is less supported than wxPython. Also the fact that wxPython is far more extensive in widget and framework support than PyGTK, makes the former a more attractive choice. PyQt was just out of the contention for me because of 2 things, a) It has a very shady license, I think it is not LGPL compatible. You can’t trust it enough to use it in commercial product without breaking some license somewhere, too controversial! AND b) Qt is just such a horrible framework! I know people are going to disagree with me on this one, but Qt’s moc compiler thing just makes me cringe. I have worked on a large project involving Qt and C++, and those moc_* files can be a nightmare at compile times. Besides Qt uses archaic and redundant C++ practices to maintain compiler compatibility. So I generally tend to “run away” from Qt and Qt projects.

Continue reading