BeastWorks CAGE (Component Assembled Game Engine)

CAGE started development around 2004. It was intended to be a successor to a prior game, graphics, and special-effects engine I’d written. It’s been revamped, refactored, and renamed many times since then.

In addition to my experience with graphics and game development, I’d built plenty of applications and tools with WIN32 and MFC.  I’d created many custom controls for visualizing and editing property trees, splines, color gradients, and other things.  Over time it was moved to wxWidgets for cross platform support.

I’d read books and articles on design patterns and component-based architecture, which was a hot topic for game development at the time, looking to create a new, modular particle system. After transitioning to a component system, the particle engine evolved into a featured-filled game engine and editor.

Components are not the foundation of the engine. They wrap functionality of underlying libraries to build relationships and expose properties for reflection, serialization, scripting, communication, and editing.

Except for bindings on iOS, everything is written in C++ and divided into a modular set of libraries for graphics, sound, math, intersections, states, navigation, memory management, asset management, logging, serialization, reflection, XML, and much more.

CAGE uses the following third-party libraries: Free Image, Free Type, FBX SDK, Open AL, OpenGL, DirectX, Lua, and LuaBind. Bullet Physics replaced Newton Game Dynamics when source was needed for building on other platforms. wxWidgets replaced MFC in 2009-2010 so that the tools could be built on Mac.

Even though I have some experience with C#, people keep asking me why I don’t use it. The answer is portability.

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
•