Kobengine

What is Kobengine? #

Kobengine is a custom 3D game engine written from scratch in modern C++ (C++20). It is the successor of my earlier Kobengine2D, but this time built in 3D on top of my own Vulkan renderer, Pompeii, which the engine consumes as a library.

The goal of Kobengine is to slowly grow into a usable, general-purpose 3D engine: a scene and component model, systems that drive rendering and lighting, asset management, input, events, and a layer system that applications can hook into. To prove that it works (and to make working in it pleasant), I am also building an editor on top of it: Kobeditor.

Active Development #

Kobengine is in active development and evolving together with Pompeii and Kobeditor. Look around here, or at the code on GitHub to see what it has become so far!

Engine Features #

Architecture #

Kobengine sits in the middle of a three-layer stack, with each layer building on the one below it:

• Pompeii | the Vulkan renderer, built as a standalone library.
• Kobengine | the engine: scenes, components, systems, assets, input, events.
• Kobeditor | the editor, built as an application on top of Kobengine.

The engine itself compiles as a static library. An application provides a CreateApplication() factory, and the engine owns main() and the run loop:

#include "KobengineEntryPoint.h"

class MyApp final : public kobengine::Application
{
public:
	explicit MyApp(const pompeii::WindowSettings& settings)
		: Application(settings)
	{
		// push your own layers, set up your scene, ...
	}
};

kobengine::Application* kobengine::CreateApplication()
{
	return new MyApp(/* window settings */);
}

The Frame Loop #

Every frame runs through a fixed, predictable order: the timer updates, the window polls events and input commands are dispatched, the systems get their BeginFrame, the active scene and systems update, all layers run their Begin/Update/End hooks (this is where the RenderLayer records and submits the frame), and finally the systems get their EndFrame. A frame limiter keeps the loop at a target frame rate.

Scenes, Scene Objects & Components #

A Scene owns SceneObjects, and every scene object owns a Transform plus any number of components. Creation and destruction are deferred: new objects sit in a pending list until the next update, and destroyed objects are flagged and swept afterwards, so containers stay stable while iterating.

kobengine::SceneObject& sun = scene.AddEmpty("Sun");
sun.AddComponent<kobengine::LightComponent>(/* direction, color, intensity */);

if (auto* light = sun.TryGetComponent<kobengine::LightComponent>())
	light->lightData.color = { 1.f, 0.9f, 0.7f };

Input as Commands #

Input uses the command pattern: you register callables against keys or mouse buttons with a trigger state, and the input manager dispatches them every frame.

kobengine::InputManager::RegisterCommand(
	kobengine::KeyCode::W,
	kobengine::TriggerState::Hold,
	[&]() { camera.Translate(camera.GetForward() * speed); });

Events #

Communication happens through a type-safe multicast Event<Args...> template, similar to C# events. Listeners can be lambdas, free functions, or member functions. The engine's logger uses this: Debug::OnMessageLogged fires for every log call, which is how Kobeditor's console panel receives its messages without the engine knowing the editor exists.

kobengine::Debug::OnMessageLogged.AddListener(this, &ConsolePanel::OnLog);
kobengine::Debug::LogWarning("This shows up in the editor console!");

The Future #

Kobengine is a work in progress, and there is a clear roadmap of what comes next: real frustum culling in the render system, scene serialization (saving and loading scenes), a cleaner boundary between engine and renderer, and gradually moving demo/editor specific behavior out of the engine core. Much of this goes hand in hand with Kobeditor, which is where these features become visible and usable.

Third-Party Libraries #

Besides Pompeii, the engine layer keeps its dependencies small: