October 6, 2012 at 16:04Imperfect technology
Hello. I’m Mikhail Kapelko, programmer for the Opensource Game Studio team. I want to tell you what we learned when approaching the release of OGS Mahjong 1.0, our latest release of Mahjong Solitaire (but not the last in the Mahjong series). This article continues the previous one: The long road to Mahjong 0.7
A year ago, in May 2011, we released OGS Mahjong 0.7, it came to us with great difficulty. This year in September 2012 we released OGS Mahjong 1.0. During development 1.0, we wanted to distribute our game on all Linux distributions, as well as Mac OS X. Unfortunately, we did not succeed, because OGS Mahjong uses OGRE and OIS.
OGRE
I started using the unstable (at that time) branch of OGRE 1.8 in the summer of 2010 for OGS Mahjong, when I realized re-creating the game window without reloading resources. My changes to implement this were taken to branch 1.8 that same summer.
I thought then that the stable release of OGRE 1.8 would be no more than in a year, so that by this time OGS Mahjong 1.0 could already depend on a stable version of OGRE. OGRE 1.8 was released on May 28, 2012.
But by this time:
1) we tried OIS 1.3 (the last at that time), it did not suit us (details below).
2) I made changes to another OGRE file (for the story: Overlay :: setMaterialName), but did not pass it to the OGRE developers, because already knew that this small change would hit the release at best in a year.
FreeImage
OGRE uses FreeImage as the main image codec. The main problem with FreeImage is that the library is not supported by the Gentoo distribution because developers resist using the zlib, png, etc system libraries ... Instead, they statically include all these libraries in FreeImage.
EDIT : FreeImage is included with Gentoo, media-libs. All other problems remain valid.
They fixed the problem of symbol visibility by using a special flag, which turned out to be in vain anyway .
Therefore, we are doing exactly as the author suggested in the 3rd option - we throw out FreeImage. In the appendage are some more libraries.
Ois
OIS is another rarely updated library. Recently released release 1.3, which completely ruined the keystroke processing for us. The keypress repetition logic has been changed, which is why OGS Mahjong just stopped accepting keystrokes 30 seconds after launch.
I informed the developer about this problem, but he could not reproduce it. We had to stay on version 1.2 for Linux.
OIS 1.3 is not built under MinGW, only the latest (at that time) version of SVN.
As for Mac OS X, OIS failed us here, because the person who was trying to help us build Mahjong for Mac OS X simply could not build OIS due to compilation errors.
Because version 1.3 was released, it comes now with all Linux distributions, which covers our desire to include OGS Mahjong in all Linux distributions with a copper basin. Unacceptable.
CEGUI The
situation was different with the CEGUI library: excellent support from the team, especially CrazyEddie, who helped a lot with the development of OGS Mahjong. But CEGUI has a very big minus: there are no convenient tools for designers. I did all GUI development alone, and the GUI changes very often during development. As a result, the development of the GUI took longer than it should.
As you can see, the above libraries pretty much limited us. More than I, the only programmer, can stand it. I realized: if we want to make games, and not constantly correct the mistakes made by other developers, we need to abandon these libraries. Of course, we can spend our whole life correcting other people's mistakes, but, fortunately, there are better alternatives (in terms of dependencies and opportunities).
OpenSceneGraph
I discovered OpenSceneGraph thanks to two recently published books:
1) OpenSceneGraph Beginners Guide, 2010.
2) OpenSceneGraph Cookboox, 2012.
The first time I met OpenSceneGraph when I changed Lightfeather to OGRE in 2010. OSG, being a complex library, did not appeal to me then, because I simply could not understand its tutorials. Fortunately, this time the aforementioned books came to the rescue, which showed the excellent OSG structure, support for common techniques right out of the box, and no dependence on FreeImage. OSG is also present in Linux distributions.
Support for common techniques right out of the box is another major issue that has been with OGRE. It is argued that OGRE supports texture mapping (shadow mapping), yes, but only with Cg. Another addiction! There was simply no tutorial on texture shadows on GLSL for OGRE. I hardly understand shaders, I was not able to implement texture shadows for a month, so we had to use stencil in OGS Mahjong 1.0.
One OSG book contained an example with soft shadow mapping. OSG supports several shadow rendering techniques out of the box. There is no need to even write a shader. It is already written for you! To change stencil shadows to soft ones, you need to change just one line of code.
I asked about the implementation of shadows in GLSL on the OGRE forums, but with no result. Therefore, the next time you see the number of posts on the OGRE forums, do not think that all the questions there are answered. For complex things, it's quite the opposite.
Another huge advantage of OSG is that the main developer, Robert, is still actively involved in the development of OSG and often answers questions in mailing lists (OSG is already 12 years old!). OGRE is very dead after leaving Sinbad.
The presence of OSG in Linux distributions is also due to the lack of crap dependency like FreeImage. OSG uses libpng to work with PNG, for example. In the end, you will not use 100,500 different formats, one or two on the strength.
libRocket
The only alternative to CEGUI. At the moment I went through several tutorials, they were not as good and beautiful as it might seem after a first look at libRocket, but this library uses a subset of HTML / CSS to describe the interface (yes, HTML / CSS support is a lie). This fact should free me from having to do a GUI. If this succeeds, we will continue to use libRocket. Otherwise, we will return back to CEGUI, where by that time, I hope, CEED for designers will be implemented (Kulik, continue what you started!).
Python
One of the first requirements for MJIN2 (our new game engine) was Python support for GUI and logic. Later, I suddenly thought, why not make MJIN2 a library in C ++, but a game entirely in Python, not only logic and GUI? This is where SWIG comes in, which can generate a Python wrapper for a C ++ library.
Using Python, we hope to increase the pace of development. I analyzed the history of the commits of the game and the engine. It turned out that there were 2 times more commits in the game than in the engine. Therefore, writing a game in Python should increase development speed due to less code, faster development.
Because we are going to support Android and iOS, we will not use Python on these platforms due to performance limitations, but we will be able to write the final versions of the games in C ++ or Java, because MJIN2 + SWIG will allow you to write the game in almost any language (C ++ native and more than 20 languages using SWIG).
We are changing a lot in the approach to game development. Let's see what it will pour into.
A year ago, in May 2011, we released OGS Mahjong 0.7, it came to us with great difficulty. This year in September 2012 we released OGS Mahjong 1.0. During development 1.0, we wanted to distribute our game on all Linux distributions, as well as Mac OS X. Unfortunately, we did not succeed, because OGS Mahjong uses OGRE and OIS.
OGRE
I started using the unstable (at that time) branch of OGRE 1.8 in the summer of 2010 for OGS Mahjong, when I realized re-creating the game window without reloading resources. My changes to implement this were taken to branch 1.8 that same summer.
I thought then that the stable release of OGRE 1.8 would be no more than in a year, so that by this time OGS Mahjong 1.0 could already depend on a stable version of OGRE. OGRE 1.8 was released on May 28, 2012.
But by this time:
1) we tried OIS 1.3 (the last at that time), it did not suit us (details below).
2) I made changes to another OGRE file (for the story: Overlay :: setMaterialName), but did not pass it to the OGRE developers, because already knew that this small change would hit the release at best in a year.
FreeImage
OGRE uses FreeImage as the main image codec. The main problem with FreeImage is that the library is not supported by the Gentoo distribution because developers resist using the zlib, png, etc system libraries ... Instead, they statically include all these libraries in FreeImage.
EDIT : FreeImage is included with Gentoo, media-libs. All other problems remain valid.
They fixed the problem of symbol visibility by using a special flag, which turned out to be in vain anyway .
Therefore, we are doing exactly as the author suggested in the 3rd option - we throw out FreeImage. In the appendage are some more libraries.
Ois
OIS is another rarely updated library. Recently released release 1.3, which completely ruined the keystroke processing for us. The keypress repetition logic has been changed, which is why OGS Mahjong just stopped accepting keystrokes 30 seconds after launch.
I informed the developer about this problem, but he could not reproduce it. We had to stay on version 1.2 for Linux.
OIS 1.3 is not built under MinGW, only the latest (at that time) version of SVN.
As for Mac OS X, OIS failed us here, because the person who was trying to help us build Mahjong for Mac OS X simply could not build OIS due to compilation errors.
Because version 1.3 was released, it comes now with all Linux distributions, which covers our desire to include OGS Mahjong in all Linux distributions with a copper basin. Unacceptable.
CEGUI The
situation was different with the CEGUI library: excellent support from the team, especially CrazyEddie, who helped a lot with the development of OGS Mahjong. But CEGUI has a very big minus: there are no convenient tools for designers. I did all GUI development alone, and the GUI changes very often during development. As a result, the development of the GUI took longer than it should.
As you can see, the above libraries pretty much limited us. More than I, the only programmer, can stand it. I realized: if we want to make games, and not constantly correct the mistakes made by other developers, we need to abandon these libraries. Of course, we can spend our whole life correcting other people's mistakes, but, fortunately, there are better alternatives (in terms of dependencies and opportunities).
OpenSceneGraph
I discovered OpenSceneGraph thanks to two recently published books:
1) OpenSceneGraph Beginners Guide, 2010.
2) OpenSceneGraph Cookboox, 2012.
The first time I met OpenSceneGraph when I changed Lightfeather to OGRE in 2010. OSG, being a complex library, did not appeal to me then, because I simply could not understand its tutorials. Fortunately, this time the aforementioned books came to the rescue, which showed the excellent OSG structure, support for common techniques right out of the box, and no dependence on FreeImage. OSG is also present in Linux distributions.
Support for common techniques right out of the box is another major issue that has been with OGRE. It is argued that OGRE supports texture mapping (shadow mapping), yes, but only with Cg. Another addiction! There was simply no tutorial on texture shadows on GLSL for OGRE. I hardly understand shaders, I was not able to implement texture shadows for a month, so we had to use stencil in OGS Mahjong 1.0.
One OSG book contained an example with soft shadow mapping. OSG supports several shadow rendering techniques out of the box. There is no need to even write a shader. It is already written for you! To change stencil shadows to soft ones, you need to change just one line of code.
I asked about the implementation of shadows in GLSL on the OGRE forums, but with no result. Therefore, the next time you see the number of posts on the OGRE forums, do not think that all the questions there are answered. For complex things, it's quite the opposite.
Another huge advantage of OSG is that the main developer, Robert, is still actively involved in the development of OSG and often answers questions in mailing lists (OSG is already 12 years old!). OGRE is very dead after leaving Sinbad.
The presence of OSG in Linux distributions is also due to the lack of crap dependency like FreeImage. OSG uses libpng to work with PNG, for example. In the end, you will not use 100,500 different formats, one or two on the strength.
libRocket
The only alternative to CEGUI. At the moment I went through several tutorials, they were not as good and beautiful as it might seem after a first look at libRocket, but this library uses a subset of HTML / CSS to describe the interface (yes, HTML / CSS support is a lie). This fact should free me from having to do a GUI. If this succeeds, we will continue to use libRocket. Otherwise, we will return back to CEGUI, where by that time, I hope, CEED for designers will be implemented (Kulik, continue what you started!).
Python
One of the first requirements for MJIN2 (our new game engine) was Python support for GUI and logic. Later, I suddenly thought, why not make MJIN2 a library in C ++, but a game entirely in Python, not only logic and GUI? This is where SWIG comes in, which can generate a Python wrapper for a C ++ library.
Using Python, we hope to increase the pace of development. I analyzed the history of the commits of the game and the engine. It turned out that there were 2 times more commits in the game than in the engine. Therefore, writing a game in Python should increase development speed due to less code, faster development.
Because we are going to support Android and iOS, we will not use Python on these platforms due to performance limitations, but we will be able to write the final versions of the games in C ++ or Java, because MJIN2 + SWIG will allow you to write the game in almost any language (C ++ native and more than 20 languages using SWIG).
We are changing a lot in the approach to game development. Let's see what it will pour into.