Kohi: a Vulkan game engine written in C, and a video series explaining every decision

An engine that is a teaching artifact first

Kohi is a game engine made as part of the Kohi Game Engine series on YouTube and Twitch, where the engine is built from the ground up using C and Vulkan. The primary language is C, the licence is Apache-2.0, and the website is kohiengine.com with API documentation under /docs/.

The name is a small joke with a real explanation. Kohi is a simplification of the Japanese word for coffee, pronounced koh-hee, which the author explains by way of how much he likes the stuff.

The most important sentence in the README is the warning. The engine is not, and will not be for quite a while, production-ready. It is a learning tool and as such is not yet optimised for use in production-quality products, and that will eventually change but for now it is not production-ready.

The goal that follows explains the design. The goal is to provide a resource the author wishes he had when learning game development, a complete guide on building a game engine from scratch, including not only design decisions but why those decisions were made. The README is unusually candid that this is a way of building an engine, not the only way and sometimes not even the correct way, and that there is a lot of trial and error, sometimes doing things the wrong way to show why it is wrong before fixing it.

That framing is what makes the repository worth reading. A reference engine shows you the answer; this one shows the reasoning, including the wrong turns.

How the code is divided

The top level listing is the architecture, and it uses the plugin pattern heavily.

There is `kohi.core/`, `kohi.runtime/`, `kohi.core.tests/` and `kohi.runtime.tests/`, so the engine is split into a core library and a runtime layer with a test project for each. `kohi.plugin.renderer.vulkan/` is the renderer, `kohi.plugin.audio.openal/` is the audio plugin, `kohi.plugin.ui.kui/` is the UI, and `kohi.plugin.utils/` holds the utility plugins.

`kohi.tools/` is where the offline tooling lives, and it is where the Assimp dependency comes from. The README notes that Kohi's tools, the importers, now require Assimp while the runtime does not, and that in future the tools will likely be split into a separate repository to avoid that dependency in the main repo.

Two testbed applications are checked in, `testbed.kapp/` and `testbed.klib/`, and the naming suggests they are the two sandbox applications the engine is exercised through.

The build system is a Makefile with a matching set of shell scripts for each platform, `build-debug.sh`, `build-release.sh`, `build-app-lib.sh` and `clean.sh` alongside the `.bat` equivalents for Windows. The Makefile detects the platform from `uname -s` and errors out on anything that is not Linux, macOS or Windows.

The directory listing also shows the working files of the project rather than just the code. There is a `TODO.md`, a `CHANGELOG`, a `Doxyfile` and `doxygen-style.css` for the documentation generator, a `.clang-format` and a `.clangd` for editor and formatting configuration, and a file called `kohi retrospective notes.md` that has no obvious parallel in most codebases.

The build targets and what the Makefile tells you

The comments at the top of the Makefile are unusually informative, because they read as instructions rather than as reference documentation.

There is `make setup` to set up the build environment, which needs to be done once unless a repository update calls for it. There is `make build-debug` and `make build-release` to build the engine, its test libraries, its plugins and the testbed project, and `make all-debug` and `make all-release` to build everything, which the comments say you usually do not need since build-debug is typically enough after the first build. `make clean` cleans everything, and the comment says that should especially be done when switching between debug and release.

Then there are the partial targets, and their descriptions are the useful part. `kohi-debug` builds just utils, Core and Runtime. `kohi-tests-debug` builds the core and runtime tests with core and runtime if needed. `kohi-plugins-debug` rebuilds all plugins plus Kohi core and runtime if needed, with tests skipped. `testbed-debug` builds the testbed plus Kohi and plugins if needed, again with tests skipped.

So the incremental loop is legible from the Makefile alone. You can rebuild just the runtime while iterating on a plugin, or just the tests while working on a subsystem, and the plugin and testbed targets deliberately skip the test suites so a quick edit does not cost you a full test run.

The Makefile also has targets for scaffolding, with `scaffold` plus `scaffold-win32`, `scaffold-linux` and `scaffold-macos` variants, and a `copy-top-level` family with the same platform split, which is the pattern of a project that has to lay down the same generated files differently on each platform. The `.PHONY` declarations list `utils-debug`, `core-debug`, `core-tests-debug`, `runtime-debug` and the rest, so the individual subsystems have their own build entry points.

What each platform needs installed

The prerequisites section is long, and the reason is stated: while the highest effort is made to reduce dependencies, each platform has things that must be installed for this to work.

On Windows the list is Make, obtained with `winget install exwinports.make` or from GNUWin32, with a parenthetical note that the last update there was in 2006 but if it ain't broke why fix it. Then Visual Studio Build Tools, Git, the Vulkan SDK from Khronos, and Assimp, where the README apologises that the Assimp link takes you to an itch.io page but that it is legitimate. After the Assimp installer you have to reboot, add the install directory to PATH, and create a system-level environment variable named ASSIMP with that same path, with a note that work will be done in the future to remove the requirement.

Linux needs LLVM, git, make and the X11 development packages, listed per distribution. Debian and Ubuntu use `sudo apt install llvm git make libx11-dev libxkbcommon-x11-dev libx11-xcb-dev`, Arch uses pacman for llvm and git, and Fedora has the longest list including clang, the X11 and XCB development packages, systemd-devel, openal-soft-devel, vulkan-headers, libshaderc-devel and vulkan-validation-layers. Assimp comes from the package manager on each of the three.

macOS needs the XCode command line tools via `xcode-select --install`, git, make and Assimp from Homebrew, plus the Vulkan SDK with the global install option selected so a copy of the files lands in `/usr/local/lib`. There is a specific note about newer macOS environments not searching `/usr/local/lib` automatically, with symlink workarounds for vulkan and shaderc, and a caveat to only do it where needed.

The audio plugin needs OpenAL, with per-platform instructions including the M1 Homebrew prefix and a note that the build-all.sh script accounts for that install layout.

Two limitations are called out in bold. Wayland is not natively supported yet, and the project does not work under WSL and will not in the foreseeable future.

A live series rather than a release cadence

The project has no GitHub releases, and the README explains the shape of the work instead.

The series starts off as more of a tutorial to get up and running, with the explanations becoming higher level as things progress to keep the pacing up, and the project eventually transitioned to live-streaming, simulcast on Twitch and YouTube, with most coding done on stream and the less interesting work done offline.

The stated ultimate goal is having a game engine capable of making games, and once the project is far enough along, making a game will be done as a series on the same channels.

So the deliverable is a body of teaching material and a codebase that grows alongside it, rather than a packaged engine with a version history. The repository layout supports that reading, with the retrospective notes file and the TODO sitting next to the source.

The last push was on 2026-10-15 and the repository is not archived, so the work is continuous. The engine has been a 3D engine from the start, with most of it built from scratch, and the platform support covers Windows, Linux and macOS officially, with Android and iOS runtime support mentioned as something that may be added down the road.

For someone deciding whether to use it, the practical test is whether you want to learn from it. A commercial game on this engine today is not a supported proposition, and the author says so plainly rather than burying it.

Editorial conclusion

Kohi fits a developer who wants to see a Vulkan engine assembled from nothing, with the reasoning behind each design choice, and who is prepared to follow a series rather than read a reference manual. It does not fit a team shipping a commercial game, since the README says outright that the engine is not production-ready and not yet optimised for production use. Before building, install the Vulkan SDK and the OpenAL and Assimp dependencies for your platform, and note that Wayland is not natively supported yet and that the project does not run under WSL.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. travisvroman/kohi on GitHub