/01
AetherCore
An editor-first Vulkan game engine for 2D and 3D games, with a GPU-driven renderer, hot-reloadable C# gameplay, owner-authoritative multiplayer with full NAT traversal, and an end-to-end asset and publishing pipeline.
Role Designed and built the engine architecture, Vulkan renderer, editor and Launcher, networking stack, managed scripting bridge, asset pipeline, diagnostics, and project tooling.
- Eight projects live in the repository - playable games, a physics sandbox, and a networked multiplayer test bed - so every subsystem is exercised by something being built with it.
- Projects move from imported assets and authored scenes to hot-reloaded gameplay, networked sessions, and packaged standalone builds without leaving the engine workflow.
Case study
AetherCore
An editor-first Vulkan game engine for 2D and 3D games, with a GPU-driven renderer, hot-reloadable C# gameplay, owner-authoritative multiplayer with full NAT traversal, and an end-to-end asset and publishing pipeline.
Role
Designed and built the engine architecture, Vulkan renderer, editor and Launcher, networking stack, managed scripting bridge, asset pipeline, diagnostics, and project tooling.
Problem
I wanted the renderer, authoring tools, scripting layer, networking, and shipping workflow to evolve as one usable engine - not become another technically interesting renderer demo that never supported making a game.
Approach
- Kept engine-facing GPU abstractions separate from the Vulkan backend and moved frame data through immutable render packets rather than reading the ECS from the render thread.
- Made reflection a single source of truth for editable component fields across the inspector, scene serializer, script bindings, and editor-control surface.
- Built the editor, standalone Launcher, managed gameplay SDK, diagnostics, and asset pipeline around the same project model so iteration and shipping use the same foundations.
- Designed the netcode so the owner of an entity simulates it - no round trip on your own input and no correction - and made connectivity degrade through a cheapest-first ladder so a game gets LAN play, NAT traversal, and relay fallback without a player ever forwarding a port.
- Treated the engine's own games as the acceptance test, building each subsystem against a project that needed it rather than against a demo scene.
Outcome
- Eight projects live in the repository - playable games, a physics sandbox, and a networked multiplayer test bed - so every subsystem is exercised by something being built with it.
- Projects move from imported assets and authored scenes to hot-reloaded gameplay, networked sessions, and packaged standalone builds without leaving the engine workflow.
- Tagging a release publishes a self-contained editor that someone can install and build games with, without a compiler, the Vulkan SDK, or the source repository.
- The Launcher and Editor can be driven and inspected programmatically for reproducible scene authoring, screenshots, diagnostics, and end-to-end validation.
