First Game with my Vulkan Engine
A few months ago I decided to finally learn Vulkan properly.
At the same time I also realized that my older OpenGL engine written in C# had reached a point where I wanted to rethink a lot of architectural decisions from scratch.
So I started over and began writing a new engine in C++ with Vulkan.
This time I intentionally tried to avoid the “build everything first” trap.
Instead of creating a giant general-purpose engine with hundreds of features I may never use, I decided to build the engine alongside an actual game project: a small space simulation inspired by games like X4.
One thing I learned from previous projects is that maintaining your own engine only makes sense if the engine fits the game you actually want to create. So the current goal is not to compete with Unreal or Unity, but to build a focused codebase that solves the problems my game needs.
At the moment the engine already has:
- Vulkan renderer with swapchain recreation
- Dynamic rendering states
- Offscreen rendering/framebuffers
- Instanced rendering
- Raycasting for scene interaction
- Asset loading/management
- Assimp model loading with shared mesh resources
- Simple PBR-style renderer
- Scene serialization
- A behavior/component system
- A small reflection/property system for editor integration
- ImGui + ImGuizmo integration
One thing that became surprisingly important was tooling.
Originally I wanted the project to stay mostly code-focused, but after implementing scene serialization and behavior reflection, creating a small in-game world editor suddenly became very practical.
So instead of building a completely separate editor application, the editor is just another part of the game itself.
Behaviors expose editable properties, and the editor automatically builds UI controls from them.
For example a behavior can expose enums and editable values like this:
properties.push_back({
.name = "Faction",
.type = PropertyType::String,
.hint = PropertyHint::Enum,
.data = (void*)&m_faction,
.metaData = factionMetaData
});
That allows the editor to generate controls dynamically while also making serialization straightforward.
Right now I’m at the point where I can finally spend more time building actual gameplay systems instead of only rendering tech.
The latest addition was a station behavior system for interactable space stations and sector-based world loading.
There’s still a lot missing of course:
- frustum culling
- better streaming
- animation improvements
- more gameplay systems
- proper UI later on
But for the first time the project feels less like “graphics experiments” and more like an actual game slowly coming together.
I’d honestly be interested how other engine/gameplay programmers handle the balance between:
- custom engine tech
- tooling
- and actually shipping gameplay.
Also here are some pictures:
also here is the source code of the engine itself: Andy16823/GFXEngine if you want have a look. Would be nice to get some feedback.