The overall goal was to address scalability issues that I’ve encountered with my previous engines. It’s pretty easy to get a Vulkan application up and running and throw some voxel stuff at it, but without a solid foundation to build systems on top of, everything sort of becomes a mess of spaghetti code and hacky interop.<\/p>\n\n\n\n
Actually, this problem extends beyond just engine development; it’s pretty much true of any software design. Developers need to try and anticipate the needs of future development while also making sure not to design an architecture that’s too abstract. There are lots of software design patterns and philosophies out there, but ultimately they are broad tools and you still have to figure out the best way to apply them.<\/p>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/voxely.net\/blog\/wp-content\/uploads\/2021\/07\/productivity_graph.png?resize=750%2C563&ssl=1\")
<\/p>\n\n\n\n
I won’t pretend to be an expert in this field by any stretch of the imagination. I’m sure people that have degrees in computer science and years of professional experience can maybe offer better insight here. In fact, this is one of those problems that it feels the more you know, the less you know. More experience leads to more obstacles you try and prepare for, which ultimately leads to over-abstraction and less and less time writing actual functional code. But with the right design, there’s got to be a crossover where the solid foundation produces more functional code at some point, right?<\/p>\n\n\n\n
Introducing the Onion Engine!<\/h2>\n\n\n\n
No, that’s not its actual name. Someone compared my new engine to an onion because of the numerous layers it has, and it stuck because it also makes me want to cry at times.<\/p>\n\n\n\n
Let’s start by defining the things every PC game engine should support:<\/p>\n\n\n\n
- Game window<\/li>
- Input capturing<\/li>
- Networking<\/li>
- Game loop<\/li>
- Render loop<\/li>
- ImGui (of course)<\/li>
- Logging<\/li><\/ul>\n\n\n\n
More or less every system that you build is an extension of one or more of these components. Players incorporate input for moving, terrain incorporates rendering, enemies incorporate the game loop to engage in combat, and so on.<\/p>\n\n\n\n
So the obvious step one is to incorporate these elements. An object-oriented system might then look something like this:<\/p>\n\n\n\n
public class Player : IGameObject\n{\n public override void OnUpdate(double dt)\n {\n }\n\n public override void OnRender(double dt)\n {\n }\n\n \/\/ etc...\n}<\/code><\/pre>\n\n\n\nFor most games and simple engines, this works perfectly fine. If I was trying to get straight to developing a game, this is the method that I would use.<\/p>\n\n\n\n
But this is in C#. In C++, it would look pretty similar, but goal #2 was to have C# and C\/C++ interop. This means we have to write C and use function pointers, which might look like:<\/p>\n\n\n\n
typedef void(*game_object_update_fn_t)(struct game_object_t* object, double dt);\ntypedef void(*game_object_render_fn_t)(struct game_object_t* object, double dt);\nstruct game_object_t\n{\n game_object_update_fn_t fn_update;\n game_object_render_fn_t fn_render;\n};<\/code><\/pre>\n\n\n\nA little more verbose, but that’s C for you. Nothing really unreasonable here for a simple game.<\/p>\n\n\n\n
But what happens when you want to add a new system to the engine?<\/strong> Or maybe you want to attach some data to just these components like the window that we’re drawing to. You can pass parameters into the functions, but then what if someone else comes in and wants to add to those parameters? Do you then pass in a heap-allocated list of structured parameters? What about code reusability like for networking? And perhaps another question we should be asking is who’s driving?<\/em> The engine is going to have to iterate over every game object and check to see if it has a render function during the render loop even if it only updates.<\/p>\n\n\n\n
I can already hear the collective groan about an impending entity-component-system<\/strong> or ECS<\/strong> lecture and how CPUs weren’t built for object-oriented programming, and why you right now need to start focusing on data-oriented designs because “your CPU cache will thank you.”<\/em><\/p>\n\n\n\n
Breaking Entity-Component-System’s Rules<\/h2>\n\n\n\n
But actually, I want to talk about how ECS and violating many of its “rules” & core principles helped address the above questions. I put “rules” in quotes because there aren’t actually rules. ECS is merely a design guideline and is usually described as follows:<\/p>\n\n\n\n
- Entity:<\/em> A simple identifier that groups together components<\/li>
- Component:<\/em> Just some raw data that systems can operate on<\/li>
- System:<\/em> One or more functions that performs some operation on a specific type (or types) of component<\/li><\/ul>\n\n\n\n
This is great for some aspects of game development, like the usual example that gets thrown around being a Position<\/em> or Transformation<\/em> component. An update system could apply velocities to the position, and then the render system could fetch both sprite components and transform components simultaneously to know what to draw and where. It’s quite elegant in that respect.<\/p>\n\n\n\n
Here’s where somebody starts chopping up onions. What if we used the idea of ECS as a way to define our engine’s systems? I talked about the core components <\/strong>(component) that an engine has, and how some objects<\/strong> (entity) combine one or more of these components to build a system<\/strong>. The thing is, “pure” ECS designs make inter-system notoriously annoying by having to deal with message systems. Keeping functionality out of components and writing systems can also be tedious.<\/p>\n\n\n\n
As it turns out, using ECS where it shines but mixing in some object-oriented principles makes for a powerful software design. It can feel a bit recursive at times, which I’ll touch on in a moment, but it addresses the key problems both with an objected-oriented design and plain ECS.<\/p>\n\n\n\n
Changing Terminology<\/h2>\n\n\n\n
This part gets confusing because unlike ECS, the entity-component-system is not clear and changes based on the current perspective. An entity can become a system, and vice-versa. Let’s start by defining some terms though:<\/p>\n\n\n\n
- Engine:<\/em> The host of an ECS world that creates and stores domains and contexts<\/li>
- Context: <\/em>A core system that creates & attaches and operates on engine components<\/li>
- Component:<\/em> A class consisting of some optional data and callbacks that a context calls<\/li>
- Domain:<\/em> A collection of components, but can also become a context and create components or be a single component and act as a singleton<\/li><\/ul>\n\n\n\n
The part that really stands out is the Domain<\/em>, which can actually be all three: an entity, component, and a system. Some might even argue that at that point it just turns into an object-oriented design, and they’d be right! That’s part of what makes it powerful and easy to use in practice. And due to the way the engine operates, it still gives us the benefits of ECS by treating it as a context or component.<\/p>\n\n\n\n
A domain is meant to be thought of as a collection of core systems that can be processed independently by default, or reach into other domains for extended functionality<\/strong>.<\/p>\n\n\n\n
For example, the Chat domain allows the users to chat with other players when in multiplayer and draws the messages to the screen. The rigid body physics domain crunches physics calculations and updates rigid body components. The player domain receives input and renders the players, and uses per-voxel collisions that it can fetch from the terrain domain.<\/p>\n\n\n\n
Admittedly, this is the part that makes me tear up, because it was actually really tough to understand at times. “What fits into where?<\/em>” Is a question I kept asking myself along the way, but every time I took a step back and tried finding a better design, this kept making more and more sense with the 3 feature goals that were outlined in the beginning.<\/p>\n\n\n\n
How it Looks in Code<\/h2>\n\n\n\n
Let’s jump straight into what a domain in C# looks like. For this example I’m using a camera, which has its updating processed in C++ but registry, ImGui rendering, and input handling in C#.<\/p>\n\n\n\n
public unsafe partial class FPSCamera\n{\n\tprivate CameraDataT* native_data = null;\n\n\tpublic FPSCamera(CameraDataT* _native_data)\n\t{\n\t\tnative_data = _native_data;\n\t}\n\n\t\/\/ Data functions\n\tpublic ref vec3 Position => ref native_data->v_position;\n\tpublic ref vec3 Velocity => ref native_data->v_velocity;\n\tpublic ref vec3 Rotation => ref native_data->v_rot;\n}\n\npublic unsafe partial class FPSCameraSystem : DomainSystem\n{\n\tpublic FPSCamera Singleton { get; private set; }\n\tpublic IntPtr NativePointer { get; protected set; }\n\n\tprotected InputComponent InputComponent { get; private set; }\n\n\tpublic FPSCameraSystem(Engine engine) : base(engine, \"FPSCamera\")\n\t{\n\t\tNativePointer = vcore_fps_camera_domain_create(NativeID, engine.NativePointer);\n\t\tSingleton = new FPSCamera(vcore_fps_camera_get_singleton(NativePointer));\n\t}\n\n\t~FPSCameraSystem()\n\t{\n\t\tvcore_fps_camera_domain_destroy(NativePointer);\n\t}\n\n\tpublic override void AddRenderComponents(RenderContext render_context)\n\t{\n\t\tvcore_fps_camera_attach_render_components(NativePointer, render_context.NativePointer);\n\n\t\t\/\/ Imgui component\n\t\t{\n\t\t\tImGuiComponent component = (ImGuiComponent)Engine.ImGuiContext.CreateSystemComponent(this);\n\t\t\tcomponent.Render += ImGui_Render;\n\t\t\tcomponent.Register();\n\t\t\tComponents.Add(\"imgui_component\", component);\n\t\t}\n\n\t\tbase.AddRenderComponents(render_context);\n\t}\n\n\tpublic override void AddStandardComponents()\n\t{\n\t\tvcore_fps_camera_attach_standard_components(NativePointer);\n\n\t\t\/\/ Input component\n\t\t{\n\t\t\tInputComponent = (InputComponent)Engine.InputContext.CreateSystemComponent(this);\n\t\t\tInputComponent.FixedEvents.MouseDown += FixedRenderEvents_MouseDown;\n\t\t\tInputComponent.RenderEvents.MouseMove += RenderInputEvents_MouseMove;\n\t\t\tInputComponent.Register();\n\t\t\tComponents.Add(\"input_component\", InputComponent);\n\t\t}\n\n\t\tbase.AddStandardComponents();\n\t}\n\n\tprivate void RenderInputEvents_MouseMove(object sender, MouseMoveEventArgs e)\n\t{\n\t\t\/\/ Move the camera\n\t}\n\n\tprivate void FixedRenderEvents_MouseDown(object sender, MouseEventArgs e)\n\t{\n\t\tConsole.WriteLine(\"Pressed \" + e.Button.ToString() + \" from camera\");\n\t}\n\n\tprivate void ImGui_Render(object sender, EventArgs e)\n\t{\n\t\tImGui.Begin(\"Camera\");\n\t\tImGui.Text(\"Position:\\t\" + Singleton.Position.ToString());\n\t\tImGui.Text(\"Velocity:\\t\" + Singleton.Velocity.ToString());\n\t\tImGui.Text(\"Rotation:\\t\" + Singleton.Rotation.ToString());\n\t\tImGui.Text(\"-\");\n\t\tif (InputComponent != null)\n\t\t{\n\t\t\tImGui.Text(\"Mouse Pos:\\t\" + InputComponent.RenderInput.GetMouse().X + \", \" + InputComponent.RenderInput.GetMouse().Y);\n\t\t}\n\t\tImGui.End();\n\t}\n}<\/code><\/pre>\n\n\n\n - Context: <\/em>A core system that creates & attaches and operates on engine components<\/li>
- Component:<\/em> Just some raw data that systems can operate on<\/li>
- Entity:<\/em> A simple identifier that groups together components<\/li>