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 sophisticated) that are held together in a single API that will be stable after its 1.0 release. 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.

There 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. What happens 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 the software keep it up to date. After that you still have to work on confusing compiler and linker options. IDEs like QT Creator, 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.

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. 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. XML, User Interface, Lua Scripting, 3d Audio, Multithreading, Resource management...

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 Documention

This documentation is automatically extracted from the source code of the Mezzanine. It is intended as a reference to describe the Mezzanine API. We hope that people with moderate or advanced C++ experience will be able to use this to increase their knowledge and get the most out of the Mezzanine. This is not a tutorial and is not likely to helpful to novice C++ developers. For more information please see the following:

An automatically generated list of issues with this documentation - http://mezzanineapi.github.io/DoxygenWarnings.txt
The BlackTopp Studios Inc. website - http://www.blacktoppstudios.com/
The Mezzanine Github page - https://github.com/BlackToppStudios/Mezzanine

If you want to know more about Doxygen please see: http://www.stack.nl/~dimitri/doxygen/

Engine Structure

The engine is laid out in a variety of classes of a few generalized roles.

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 and try to present a concise API. Managers ( Mezzanine::ManagerBase instances ) generally have a rigid place in the structure of the running program. 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 two objects are colliding?". Managers are owned either by the Mezzanine::Entresol or a Mezzanine::World depending on their roles and technical limitations.

The Mezzanine::Threading::FrameScheduler is responsible for running the work each task requires. Most managers mantain one or more of Mezzanine::Threading::iWorkUnit implementations/instances to do work each frame. The FrameScheduler performs some heuristics and manages when and where the workunits will be run. Generally these are created early in the lifetime of a game and destroyed near the end.

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 various parts of the 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. Some of these are small enough to pass around value and some are not.

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 in the simulation visible to the user.

Some classes are 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.

Managers

The canonical source for the list of managers is the ManagerBase::ManagerType enum.

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. Before the switch to the all support the basic callback and priority functionality because of this.

Entresol Managers // Namespaces MT_AudioManager = 1, // Audio MT_AnimationManager, // Graphics MT_CollisionShapeManager, // Physics MT_GraphicsManager, // Graphics MT_EventManager, // Mezzanine MT_InputManager, // Input- MT_LogManager, // Mezzanine MT_MaterialManager, // Graphics MT_MeshManager, // Graphics MT_NetworkManager, // Network MT_ResourceManager, // Resource MT_ScriptingManager, // Scripting MT_UIManager, // UI

World Managers // Namespaces MT_ActorManager = 100, // Mezzanine MT_AreaEffectManager, // Mezzanine MT_CameraManager, // Graphics MT_PagingManager, // Paging MT_PhysicsManager, // Physics MT_SceneManager, // Graphics MT_SoundScapeManager, // Audio MT_TerrainManager, // Mezzanine MT_VehicleManager, // Mezzanine

A list of Managers in the Mezzanine

Mezzanine::ActorManager - Store and allows retrieval of Actors, when an actor is in this it is part of the game simulaiton
Mezzanine::AudioManager - Play, stop and otherwise work with sound and music.
Mezzanine::CameraManager - Add/remove Multiple camera's from the world
Mezzanine::CollisionShapeManager - Store/create/delete shapes that can be used for physics and collision detection
Mezzanine::EventManager - Get messages and events from the operating system (and user, but that will change)
Mezzanine::GraphicsManager - Adjust Resolution, refresh rate, color depth and thing like that.
Mezzanine::MeshManager - Manage Meshes that can be rendered to the the screen.
Mezzanine::NetworkManager - Manages the transmission and retreival of network traffic.
Mezzanine::PhysicsManager - Control settings that have to do with the physics simulation.
Mezzanine::ResourceManager - Loads Files and locate them in an efficient way.
Mezzanine::SceneManager - Control Lighting, skyboxes, particle effects etc...
Mezzanine::TimerManager - Create and delete a variety of timers.
Mezzanine::TerrainManager - Work with terrain components like height maps.
Mezzanine::UIManager - Create and manage buttons, scrollbars and other widgets.