Today we want to present another Game highlight of Ogre3D based games. This time: Cyberix3D
We asked the team behind the game if they could share some insights into the Ogre3D usage and how the game was built in general:
What is Cyberix3D
Cyberix3D is an online 3D game maker for people who have never written a line of code. You build a game out of visual blocks, press play, and it runs. The whole editor is in the browser, projects live in your account, and there is a Windows build if you prefer a desktop app. Finished games can be published on the site and played by anyone, or exported to Windows, Android and the web as standalone builds.
Under the blocks, a game is an XML document. The editor writes it, and it is compiled to Lua that drives the engine. The same path runs in the editor, in the player, and in every export.
The rewrite
The project is not new. The original engine was ActionScript 3 on top of Away3D, from the browser plugin era, and people published games with it for years. When that road ended we rewrote the engine and the editor from scratch in C++ and picked Ogre to render it.
The constraint that shaped everything was that none of the existing games could break. They were made by users, most of them a long time ago, and there is nobody to ask to re-save anything. Because a game is stored as XML rather than as code, the content itself was never tied to the renderer. What had to be rebuilt was the meaning behind it: the new engine has to interpret those blocks the way the old one did. The quirks were the long part. Old games depend on old behavior, so every game carries a version and keeps the behavior it was built against.
Ogre
We are on Ogre 14.3.1, with the components that ship with it: Terrain, Overlay, RTShaderSystem, Paging, Bites, the Octree and PCZ scene managers, ParticleFX, and the Assimp and STBI codecs. Physics and collision go through Ogre’s own Bullet component, and the Lua runtime is bound to the engine with sol2, so a block the user dragged ends up calling straight into Ogre. Dear ImGui 1.91.2 handles all 2D. Not only the editor interface, but the 2D layer of the games themselves: buttons, labels, images, HUDs and menus.
A few things exist only in the new version. Shaders and particle systems can be built dynamically from the code blocks, and there are volumetric lights and true water reflections. We built those on the foundation Ogre provides, some of it starting from the samples.
In the browser
The web build is Emscripten. The same C++ codebase compiled to WebAssembly, rendering through the GLES2 RenderSystem on WebGL2. There is no separate web engine and no reduced web version: the editor itself runs in the browser, not just the games.
Two things needed real attention. There is no blocking main loop on the web, so anything that used to wait had to become a frame driven state. And shaders are GLSL ES only, so the desktop dialects do not carry over; Ogre’s OgreUnifiedShader.h is what makes one shader source compile for both.
Why Ogre
Ogre is genuinely multiplatform, and the web is a real target rather than an afterthought, which for us was the whole point: the editor and the games both have to run in a browser. Bullet and Dear ImGui come integrated, which gave us exactly the physics and the 2D we needed and nothing we had to glue together ourselves. It is fast across a wide range of hardware, down to basic phones and low end machines, which matters when your users play on whatever computer they already have. And it is documented, it has a forum where people actually answer, and it is still being actively developed.
That last one is not a small thing. We started out on Urho3D and it was discontinued while we were building on it, so an engine that is still alive counts for as much as any feature on the list.
Thank you to the Ogre team, and to everyone on the forums. A lot of what made this rewrite possible was already sitting in the box, and a lot of the rest we found in old threads.