Kore 3: a low level cross-platform game toolkit built around kmake

A layer between the operating system and your engine

Kore is described as a low level toolkit for cross-platform game engine development and similar endeavors, and the README compares it to SDL while immediately adding the caveat that it is bigger in scope. The difference, as stated, is that Kore also takes care of cross-platform GPU programming with multiple portable APIs to choose from, and ships its own shader language called Kongruent. So the positioning is a foundation layer under a game engine rather than an engine itself: windowing, input, timing and the graphics device abstraction, plus a build system and a shader toolchain, all in C. The audience is engine developers and people building the kind of software that games and tools are built on, not someone looking for a ready-made game. The repository is organised like a systems library, with backends/ for the platform and API implementations, sources/ for the shared code, includes/ for the public headers, shaders/ for the shader side, tools/ for the supporting binaries, tests/ and a miniclib/ for a minimal standard library. The presence of a .clang-format file and an msbuild.rsp response file tells you it is built with clang tooling and MSVC.

kmake generates the IDE project, not the binary

The build entry point is unusual enough to be worth describing carefully. Kore projects are built using kmake, a meta-build-tool that resides in a git-submodule inside the Kore checkout, which is why the repository has a .gitmodules file. In your own project directory you invoke the make script that lives inside the Kore submodule, at the path path/to/Kore/make, and that creates a project file for your IDE inside a subdirectory called build. So kmake is a generator rather than a compiler driver: it writes the project files your IDE needs, and the actual compilation happens through whatever build system that generated file describes. By default kmake creates a project for the system you are currently using, and you can also name a different target, with windows, linux, android, windowsapp, osx, ios and freebsd listed as the accepted values. The root of the repository also holds make and make.bat, the Windows counterpart of the same entry point.

One graphics abstraction over Direct3D, OpenGL, Vulkan and Metal

The graphics API is a second choice made at project generation time, with the -g flag selecting between direct3d11, direct3d12, opengl, vulkan and metal. This is the part that distinguishes Kore from a plain platform abstraction library: the same engine code can be compiled against a different graphics API by regenerating the project, which is the practical answer to the classic problem of a Windows-first engine that needs a Metal backend years later. The repository layout supports the same idea at the source level, since backends/ is where the per-API implementations live and are expected to be uneven in maturity, which is exactly why Kore-Samples exists. That samples repository is described as a growing list of graphics samples checked on each revision across the supported APIs, so it functions as a continuous compatibility test rather than a set of tutorials.

Kore 3 brings a new graphics API and a new shader language

The README is direct that this is Kore 3, the latest version and still slightly experimental, and that it uses a new graphics API, described as essentially an expanded version of WebGPU, along with a new shader language that it calls very custom. The shader language is Kongruent, and it lives in its own repository rather than inside Kore, so the two pieces evolve separately. The word to hold onto is expanded: this is not a WebGPU compatibility layer that behaves exactly like the browser specification, which is a reasonable route to a more capable abstraction but a different target from what the web platform promises. For a team evaluating Kore 3, the samples repository is the fastest way to see how much of the promised surface actually works on each API, since every revision is checked against them.

Two older branches are still the ones most projects should use

The versioning story is unusual and worth internalising before you start. Alongside the current main branch, the README points at a v2 branch for a more stable experience, and a v1 branch for Kore's original C++ API. That gives three distinct worlds: a C++ era, a stable C era, and an experimental C era with a new graphics API. Choosing Kore today means deciding which of the three you actually want, and the project's own advice is that if you want stability you should be on v2. The root of the repository also carries an updates.md file, which is the natural place to look for the notes on what changed, and a licenses.txt file alongside the source tree, since the toolkit incorporates third party code whose licences need to travel with it. The project itself does not name a licence identifier in the fields it publishes, so read licenses.txt and the individual files before you ship anything. There are no GitHub releases, so there is no tagged version list to consult, and the last push was on 2026-10-18.

Console support exists, but the code is not public

One capability is deliberately closed off. The README states that console support is implemented via separate plugins because the code cannot be provided publicly, and that interested developers should contact Robert for details. That is a distribution constraint rather than a technical gap, and it has a direct effect on adoption: if your target includes a console, the graphics and platform abstractions may still save you work while the platform layer itself arrives as a private arrangement, which is a different relationship than open source usually implies. The other top level scripts in the repository, get_dlc, get_dlc.bat and the two variants named get_dlc_dangerously, are download helpers for additional content, and their presence alongside a make script and kfile.js, a JavaScript build description file, shows how much of the tooling is script driven rather than a conventional makefile.

Where Kore is the wrong tool

The cases where this is the wrong choice are mostly about fit rather than quality. If you are writing a game rather than an engine, Kore is a layer you would have to build on top of, and you would be paying for a graphics abstraction you may only half use. If your project is not written in C, the shared code and the build tooling are less useful, and the original C++ API lives on a separate branch that is not the actively developed line. If you need a stable, documented, versioned API with a published release trail, the absence of GitHub releases plus three parallel branches is friction you would have to absorb. The alternative worth naming is SDL with a separate rendering library, which is a smaller abstraction you can adopt piece by piece rather than a whole toolkit, at the cost of writing the GPU backend selection yourself. Kore trades that modularity for a single, coherent, pre-integrated stack, which is the right trade for a studio shipping its own engine and the wrong one for a small team that only needs windowing and input.

Editorial conclusion

Adopt Kore 3 if you are writing an engine or engine-adjacent tool and want one abstraction layer over Direct3D, OpenGL, Vulkan and Metal without writing each backend yourself. Do not adopt it if you need a stable production API today, because the project itself calls this version slightly experimental and points you to the v2 branch for a steadier experience, or if your project is not already C based. Verify first which graphics backends your target platforms need, and note that console support is not public code, since those plugins are distributed separately to interested developers.

Frequently asked questions

Official sources

1. Issues
2. Kode/Kore on GitHub
3. README