Imperfect 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 of 2011, we released OGS Mahjong 0.7, it was given to us with great difficulty. This year in September 2012, we released OGS Mahjong 1.0. During the development of 1.0, we wanted to spread 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) OGRE 1.8 branch in the summer of 2010 for OGS Mahjong, when I implemented the re-creation of the game window without reloading resources. My changes to implement this were taken into branch 1.8 the same summer.
I thought then that a stable release of OGRE 1.8 would be no more than a year later, so that by this time OGS Mahjong 1.0 might 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 one at the time), it did not fit us (details below).
2) I made changes to another OGRE file (for history: Overlay :: setMaterialName), but did not transfer it to the OGRE developers, since I already knew that this small change would fall into 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 the developers resist using the system libraries zlib, png, etc ... Instead, they statically include all these libraries in FreeImage.
EDIT : FreeImage is included in Gentoo, media-libs. All other problems remain.
They fixed the problem of visibility of characters by using a special flag, which still turned out to be in vain .
Therefore, we do exactly as suggested by the author in the 3rd version - throwing FreeImage. In the appendage a few more libraries.
Ois
OIS is another rarely updated library. The 1.3 release was recently released, which completely spoiled the keystroke processing for us. The key repeat logic was changed, which is why OGS Mahjong simply 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 let us down here, because the person who was trying to help us with assembling Mahjong under Mac OS X was simply unable to build the OIS due to compilation errors.
Since version 1.3 has been released, it comes with all Linux distributions now, which covers our desire to include OGS Mahjong in all Linux distributions with a copper basin. Unacceptable.
CEGUI
The situation with the CEGUI library was completely different: excellent support from the team, especially CrazyEddie, who greatly helped with the development of OGS Mahjong. But CEGUI has a very big minus: there are no convenient tools for designers. I did all the GUI development alone, and the GUI changes very often during development. As a result, GUI development took more time than it should.
As you can see, the above libraries have limited us quite a bit. More than me, the only programmer I can handle. I realized that if we want to make games, rather than constantly correcting 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 with two recently published books:
1) OpenSceneGraph Beginners Guide, 2010.
2) OpenSceneGraph Cookboox, 2012.
I first met OpenSceneGraph when I changed Lightfeather to OGRE in 2010. OSG, being a complex library, did not attract me then, because I simply could not understand its self-help books. Fortunately, this time came to the aid of the above books, which showed the excellent structure of OSG, the support of the advanced techniques right out of the box, the lack of dependence on FreeImage. OSG is also present in Linux distributions.
Supporting advanced technicians right out of the box is another serious problem that has been with OGRE. It is argued that OGRE supports 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 of the books OSG contained an example with soft shadows (soft shadow mapping). OSG supports several shadow rendering techniques out of the box. 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. So 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 great 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 very much withered after the departure of Sinbad.
The presence of OSG in Linux distributions is due, among other things, to the lack of crap-like dependency like FreeImage. OSG uses libpng to work with PNGs, for example. In the end, you will not use 100,500 different formats, one or two at most.
libRocket
The only alternative is CEGUI. At the moment I have passed several tutorials, they were not as good and beautiful as it may seem after taking 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 come back to CEGUI, where by that time, I hope, CEED will be implemented for designers (Kulik, keep it up!).
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 ++ and play the game completely in Python, not just logic and GUI? This is where SWIG comes to the rescue, 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 commit and game 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 speed up development due to less code, faster development.
Since 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 games in C ++ or Java, because MJIN2 + SWIG will allow you to write a game in almost any language (C ++ is 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 out.
A year ago, in May of 2011, we released OGS Mahjong 0.7, it was given to us with great difficulty. This year in September 2012, we released OGS Mahjong 1.0. During the development of 1.0, we wanted to spread 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) OGRE 1.8 branch in the summer of 2010 for OGS Mahjong, when I implemented the re-creation of the game window without reloading resources. My changes to implement this were taken into branch 1.8 the same summer.
I thought then that a stable release of OGRE 1.8 would be no more than a year later, so that by this time OGS Mahjong 1.0 might 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 one at the time), it did not fit us (details below).
2) I made changes to another OGRE file (for history: Overlay :: setMaterialName), but did not transfer it to the OGRE developers, since I already knew that this small change would fall into 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 the developers resist using the system libraries zlib, png, etc ... Instead, they statically include all these libraries in FreeImage.
EDIT : FreeImage is included in Gentoo, media-libs. All other problems remain.
They fixed the problem of visibility of characters by using a special flag, which still turned out to be in vain .
Therefore, we do exactly as suggested by the author in the 3rd version - throwing FreeImage. In the appendage a few more libraries.
Ois
OIS is another rarely updated library. The 1.3 release was recently released, which completely spoiled the keystroke processing for us. The key repeat logic was changed, which is why OGS Mahjong simply 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 let us down here, because the person who was trying to help us with assembling Mahjong under Mac OS X was simply unable to build the OIS due to compilation errors.
Since version 1.3 has been released, it comes with all Linux distributions now, which covers our desire to include OGS Mahjong in all Linux distributions with a copper basin. Unacceptable.
CEGUI
The situation with the CEGUI library was completely different: excellent support from the team, especially CrazyEddie, who greatly helped with the development of OGS Mahjong. But CEGUI has a very big minus: there are no convenient tools for designers. I did all the GUI development alone, and the GUI changes very often during development. As a result, GUI development took more time than it should.
As you can see, the above libraries have limited us quite a bit. More than me, the only programmer I can handle. I realized that if we want to make games, rather than constantly correcting 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 with two recently published books:
1) OpenSceneGraph Beginners Guide, 2010.
2) OpenSceneGraph Cookboox, 2012.
I first met OpenSceneGraph when I changed Lightfeather to OGRE in 2010. OSG, being a complex library, did not attract me then, because I simply could not understand its self-help books. Fortunately, this time came to the aid of the above books, which showed the excellent structure of OSG, the support of the advanced techniques right out of the box, the lack of dependence on FreeImage. OSG is also present in Linux distributions.
Supporting advanced technicians right out of the box is another serious problem that has been with OGRE. It is argued that OGRE supports 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 of the books OSG contained an example with soft shadows (soft shadow mapping). OSG supports several shadow rendering techniques out of the box. 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. So 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 great 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 very much withered after the departure of Sinbad.
The presence of OSG in Linux distributions is due, among other things, to the lack of crap-like dependency like FreeImage. OSG uses libpng to work with PNGs, for example. In the end, you will not use 100,500 different formats, one or two at most.
libRocket
The only alternative is CEGUI. At the moment I have passed several tutorials, they were not as good and beautiful as it may seem after taking 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 come back to CEGUI, where by that time, I hope, CEED will be implemented for designers (Kulik, keep it up!).
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 ++ and play the game completely in Python, not just logic and GUI? This is where SWIG comes to the rescue, 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 commit and game 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 speed up development due to less code, faster development.
Since 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 games in C ++ or Java, because MJIN2 + SWIG will allow you to write a game in almost any language (C ++ is 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 out.
Source: https://habr.com/ru/post/153837/
All Articles