More than Two years in the making, and much progress has been made and much more progress will come. We having working 3d graphics and physics on Windows and Linux. The engine also currently has 3d sound support, multiple levels of physics detail, a fast xml parser, detailed reporting on collisions, partial serialization and deserialization of the game state, support for some kinds of pixel shaders, heaps of documentation, and much more.
There are a few thing that are still in development: complete serialization support, paged loading of physics and graphics data, fixing Mac OS X support, Lua scripting… It could go on long enough to write a Todo Page about it.
In addition to our progress almost every day progress almost every day, now we have a decent name.
What is “Mezzanine“?
“a mezzanine or entresol is an intermediate floor between main floors of a building, and therefore typically not counted among the overall floors”
Nicholas Baker wrote a whole novel about his time between real tasks. In finance and real estate it is a funding source or property that is between secured gauranteed money and property, and stuff that looks like debt. It is a snazzy restaurant in Virginia that is between the between the ocean and the farms while it is wedged between bigger buildings. It is the tar that holds blacktop together.
Our game engine is like all these things, it is between so many things. It is pulling in the best of breed functionality from many libraries that provide needed game functionality, unifying them in a easier to use package. We know lines of code aren’t the best metric of size, but they will do for this simple comparison. Ogre3d the astounding 3d graphics engine we use is 4.5 million lines of codes that have nothing to do with sound or physics. Bullet physics is 500,000 lines of code that have little to do with graphics, sound or loading files. SDL is used for operating system integration and user input while adding another 149,000 lines of code (including its very sophisticated build system). PugiXML, cAudio, Ogg, Vorbis, Lua and OpenAL are smaller, but together bring in another 132,000 lines of codes which each do their specific thing but aren’t unified in any way. The Mezzanine engine is just 100,000 lines, and primarily integrates these into a simple seamless library. We are a mezzanine in gaming software.
We fill the cracks that are needed to go from software developers to game developers. The engine fits between the game and the platform providing a single API for high performance gaming on each platform the engine supports.
Why be a Mezzanine?
A bridge like our Mezzanine is important because it connects the unconnected.
No one else has created a maintainable integration of all the features needed for high quality way. Just to select this group of libraries, that almost universally work on every gaming platform, we had to become experts. All of the tools we integrate work on almost almost all of these: Windows, Linux, MacOS X, Wii, Xbox, PS3, iPad, Android, a web browser, and really obscure platforms you may not have heard of like Open Pandora. Where our tools and software aren’t clearly supported we have workable plan for integration or replacements, preventing us and other users of the Mezzanine engine from being limited by someone else’s decisions.
Many others have created great tools that integrate a few of these or other libraries in similar projects, it would be silly to think no one else came along first. Those that did a good job hide their work’s source code and charge large fees; some literally charge millions of dollars to use their work on one game. Some aimed to just integrate a few of the feature that we wanted, and frequently didn’t plan for further building or expansion onto other platforms. Then there are the rare few that seemed to get the pie and share it, but mostly these projects failed to have long term sustainability. These groups mostly failed to think about updating code they had integrated and destroyed important logical separations, so they could release code a day sooner. In the end it costs them the effort reduplicating all their work every release of a tool they use, so they remain without important updates and security fixes. I refuse to mudsling and deride others without being able to say it to their faces, but we haven’t made these same mistakes.
A Plan to Build Mezzanine.
Certainly we have made msitakes, the goal is to get the big things right because changing them is harder or even impossible in the future. Spelling mistakes are simple to correct, but the architecture is what everything else is built on. Development methodologies that rely on rapid refactoring are great for many projects, but when entire other projects are relying on the foundation laid now, you can’t mess up the big stuff. Fortunately, we can plan now.
There things that are simple to plan for if you know they are coming, like new releases of software you use. Keeping logical boundaries and using them cleverly and careful helps here. This means that others can simply swap in a new versions of a library and immediately benefit from it. So if one platform provides hardware acceleration, needs debugging symbols, or you just want to customize something specific a piece can be swapped out to support this. These logical barriers also ensure there is never a need for the games that use the Mezzanine to call directly upon any of the internal libraries it uses. This way the engine functionality can be implemented in the best way for the platform and build tools.
Internally there is structure of managers, which are objects that manage specific functionality. Having seen other designs we know what kinds of pitfalls even simple design decision can have. So we have carefully chosen what to make managers for based on what a game could need. The managers are where we integrate much of different functionality and through these we present a unified API for game developers.
We have more plans for future integration and change. We have plans for all the features that one would want for high performance physics enabled 3d gaming. It is still a work in progress and that is our greatest disadvantage. So we are hard at work rounding off our features to get our engine to a production ready state, though any extra hands would be welcome.