Imperfect technologies

Hello. I’m Michael Kapelko, Opensource Game Studio team programmer.
I want to tell you what we learnt while heading towards OGS Mahjong 1.0, our final release of Mahjong solitaire (but not final in Mahjong series). This article continues the previous one: A long way to Mahjong 0.7
One year ago, May 2011, we released OGS Mahjong 0.7, it was a difficult confinement. This year, September 2012, we released OGS Mahjong 1.0. While heading to 1.0 release we wanted the game be available on all Linux distributions, and also support Mac OS X.
Unfortunately, we failed to do that, because OGS Mahjong uses OGRE and OIS.


OGS Mahjong started to use unstable (at the time) OGRE 1.8 in the summer of 2010 when I was implementing game window recreation without reloading resources. My patch to achieve it has been incorporated the same summer into OGRE 1.8 tree.
I thought it’s not going to take more than one year for OGRE to reach 1.8, by the time we release OGS Mahjong 1.0 we should have been dependent on stable OGRE instead. OGRE 1.8 has been released on May 28, 2012. Although, by that time:
1) we tried OIS 1.3 (latest at the time) which didn’t work for us (details below);
2) I’ve patched another file (for the record: Overlay::setMaterialName) of OGRE which I did not commit, since I knew it’s gonna take another year for the tiny change to be released.


OGRE uses FreeImage as its main image codec. The big problem with it is that it’s unsupported by Gentoo, because FreeImage developers refuse to use system libraries like zlib, png, etc. They instead static link all the dependencies into FreeImage.
EDIT: FreeImage is in media-libs of Gentoo. The rest of the problems still apply.
They only fixed the clashing by hiding used libraries which is still wrong.
Just as the author proposed the 3rd option of kicking FreeImage, we do it. Along with other libraries.


OIS is yet another slow release cycle library. Recently 1.3 release came out which totally ruined Linux input handling for us. The repeat key handling has been rewritten and OGS Mahjong has been simply stopping to accept input after running for 30 seconds.
I’ve contacted the developer with the key handling bug, but he couldn’t reproduce it. We had to stick with 1.2 for Linux.
OIS 1.3 can’t be compiled under MinGW, only the latest (at that moment) SVN revision can.
As for Mac OS X, OIS screwed us here as well, because the guy who tried to help us compile Mahjong on Mac OS X just couldn’t build OIS due to compilation errors.
Since 1.3 has been released, it is shipped in all Linux distributions now which prevents OGS Mahjong to be built from sources for Linux distributions. Unacceptable, too.


On the contrary to OGRE and OIS, CEGUI is a much better library, with excellent support from its team members, especially CrazyEddie who have helped us a lot with OGS Mahjong development. But CEGUI has one major drawback: it’s complicated for designers. All GUI has been done solely by me, programmer. And GUI does change a lot during development. So GUI took more of my time than it should.

As you see, the above libraries have put some heavy weight on us. More than I, the only programmer, can handle. I understood that if we want to make the game instead of constantly solving other developers’ mistakes, we have to drop those libraries. Of course, we can spend our entire lifetimes to fix mistakes made by others, but hopefully there are simply better alternatives (from the dependency and feature perspectives).


I discovered OpenSceneGraph thanks to 2 OSG books recently released:
1) OpenSceneGraph Beginners Guide, 2010.
2) OpenSceneGraph Cookbook, 2012.
I first looked at OSG back when I chose OGRE over Lightfeather in 2010. OSG, being complicated, didn’t attract me at the time, because I simply failed to understand its tutorials. The books helped me see OSG well defined structure, out-of-the box common technique support, no dependency on FreeImage. OSG is also present in Linux distributions.
Out-of-the box support for common techniques is another serious issue I’ve had with OGRE. OGRE claims to support shadow mapping, and it does so, but only with Cg. Yet another dependency! There was simply no tutorial to implement it in GLSL. I’m not a shader guy and I failed to implement it myself in a month, so we had to resort to stencil shadows in OGS Mahjong 1.0.
One of the OSG books featured an example of soft shadow mapping. OSG has built-in support for various shadow mapping techniques. You don’t even have to write down a shader. It’s already written there for you! To get soft shadow mapping instead of stencil shadows, you need to change only 1 line of code.
Also, I’ve asked about GLSL shadow mapping at OGRE community forums without success. So next time you see large post counting at OGRE forums, don’t think 100% of the posts get answers. For difficult topics it’s quite the opposite.
Another major OSG advantage is that its main developer Robert is still actively participating in OSG development and is frequently responding to questions in the mailing list (OSG is 12 years old!). OGRE misses Sinbad badly.
OSG presense in distribution is also caused by not using FreeImage-like crap. OSG uses plain libpng for PNG handling, e.g.. In the end, you’re not going to have 100500 image formats. It’s gonna be only one or two.


The only alternative to CEGUI is libRocket. I’ve tried several tutorials so far, they weren’t as great and shiny as libRocket first looks, but it does use subset of HTML/CSS to define layouts (yes, it lies about being HTML/CSS GUI library). This should help us relieve me from GUI programming. If that happens, we stay with libRocket. Otherwise, we’re back to CEGUI which will hopefully have CEED ready for designers by that time (Kulik, go on!).


One of the first requirements for MJIN2 (our new game engine) was support for Python GUI and logic scripting. But later on I’ve had a thought, why not have MJIN2 library in C++ and game in Python completely, not only scripts and GUI? SWIG helps to achieve that by allowing to generate Python wrapper library around C++ one.

With Python we hope to increase the speed of game development. I have analyzed both game and engine commit logs, and it turned out that game has twice as much commits as engine has. Having game part in Python, thus, should increase development speed due to less code, less development time.

Since we’re going to have Android and iOS supported, Python will not be used on the platforms due to performance restrictions, but we can write final versions of the games in C++ or Java since MJIN2 + SWIG allows us to write a game in pretty much any language (C++ natively, and 20+ other languages with the help of SWIG).

We’re having big changes in how we develop games. We’ll see how it all turns out.
This entry was posted in Team Blog and tagged , . Bookmark the permalink.