The Mezzanine Engine isn't really an engine. It is glue holding other code and libraries together. It is a series of other open source libraries (sometimes less user friendly, and almost always more sophistciated) that are held together in a single, hopefully, unchanging API. Others have attempted to do things like this before. Usually simple mistakes are made along the way that have huge negative impacts later in the design. A common mistake code is to copy and paste from open source projects with no plans for maintainability. This means that those projects get all the features and bugs from when they copied, without updates, new features and bugfixes since they started integrating the code. We too have copy and pasted, however we are keeping it up to date, and have a plan for upgrading each component we have brought in.
This is no simple way to guarantee access to the most up to date libraries, this means there will meaningful work on integration. Many linux distributions try to keep the most up to date shared libraries around, but what about when they don't ship what you need, ship something broken or an older library. What about Windows and Mac OS X which make no attempt to keep these kinds of software up to date. What if you do manage to get and stay up to date, then you still have to work on a confusing compiler and linker options, Code::Blocks or Visual Studio aren't going to set that up for you. The Mezzanine Engine project depends on a dozen or more libaries, so would your project if it had high performance 3d graphics, easy to use 3d physics integrated with the graphics and 3d positional audio ready to run on Windows, Linux and Mac OS X. We are figuring it out once, getting it right ( if we aren't, tell us and we will fix it ), so it doesn't need to be done again and again, for each game made.
This is still in heavy development and is not in usable condition for all systems. Currently the synchronization of 3d graphics and physics works great. But, some of the more advanced features of both physics and graphics to do not yet work. There are a number of other features that are in varied states of development.
If we do our jobs right this will save time and effort making, updating and porting games between a variety of platforms. If you link only against this library, not a single line of your standard compliant C++ code should need to change between platforms. At this early stage we are proving the concept with "Catch!" our first sample game. It Currently runs on Linux, Windows and Mac OS X with an Identical codebase. When we are done with "Catch!" We want it to have one codebase (with no messy #IFDEFs in game code for compatibility), and downloadable in the Iphone app store, in the Android Marketplace, on the PS3, Wii, downloadable on Steam, and in a variety of linux repositories.
This is the Doxygen API documentation for the Mezzanine Engine. This is a document for programmers to use as reference. With just a few clicks this should allow a technically oriented person find
If you want to know more about doxygen please see: http://www.stack.nl/~dimitri/doxygen/ To get the latest news on development or more information that isn't technical checkout: http://www.blacktoppstudios.com
Here we will detail the engine structure and different classes and datatypes, but some of these need an update.
The engine is laid out in a variety of classes. Some classes are focal points for functionality and internally unify a number of components to do what they do, these managers sometimes conceal a large amount of complexity. Managers generally have a very rigid in the structure of the engine and these are generally managed by the world and are rarely manaully created. This is where are the logic that says how something is done exists, for example "how does something get drawn on the screen?" or "how do you detect if to objects are colliding?". In general there is only one of each manager and it inherits from the Mezzanine::Singleton class.
Other classes are more similar to data, things like the Mezzanine::Vector3 and the Mezzanine::Quaternion. You can create these things whenever you like and generally have good support for integrating into a variety of system. In these classes there is a good deal of math and conversion routines. These are commonly passed around by more sophisticated classes for a variety of reasons.
There are some classes that are somewhere between data and singular large-scale aggregration of functionality in managers. The functionality is carefully controlled and most commonly created, deleted and otherwised managed through managers. Many of these classes like the Mezzanine::Light or Mezzanine::ActorRigid are present inside the game simulation as well as having a presence as
some utility classes Other class that really are just convient places to put functions, things like the Mezzanine::ActorRigidDeSerializer and the Mezzanine::StringTool are good examples of these logical grouping of functions. Finally, there are few
A manager is simply a logical grouping of functionality. A number of them exist covering all the major functionality that a game using the the Mezzanine engine would need in most situations.
All Managers inherit from ManagerBase. They all support the basic callback and priority functionality because of this.
A thorough description needs to go here