Kaiju Engine: a Go and Vulkan 2D/3D game engine with a built-in editor

The gap Kaiju Engine is aimed at: Go and Vulkan instead of C++

Most 2D and 3D engines hand you C++, C# or a visual scripting layer. Kaiju Engine takes a different position: the README describes it as "a traditionally designed and coded, 2D/3D game engine written in Go (Golang) backed by Vulkan", with the stated goal of using "a modern, easy, systems level programming language" and a focus on simplicity. That is the pitch. If your team already writes Go services and you have avoided engines because the language boundary costs you more than the rendering does, this is the project aimed at you. The audience is narrower than a general engine audience: you need Go tooling, C build tools, platform libraries and a Vulkan setup on the machine before the build command does anything useful. The README links a build-from-source document for prerequisites rather than listing them inline, which tells you the setup is real work. The feature list covers 2D and 3D, particles, skeletal and sprite animation, audio through Soloud, a custom retained-mode UI with optional HTML/CSS markup, live GLSL shader updates, and editor plugins written in Go. Cross-platform covers Windows, Linux and Mac for development, with Android as a deployment target and more platforms described as coming.

How the engine is put together: Go on top of Vulkan, Soloud and Bullet3

The repository layout makes the dependency story visible. The engine source lives under src/, and src/libs is a git submodule pointing at KaijuEngine/kaiju_prebuilts, which holds pre-built library files. Those libraries are Soloud for audio and Bullet3 for physics; the README states that if you clone without the submodule you must build Soloud and Bullet3 yourself, and links separate sections of docs/engine/build_from_source.md for each. So the data flow at build time is: Go code in src/ compiles against prebuilt C libraries plus Vulkan, and the result is a single binary placed in bin/. Rendering is Vulkan, and the README says a "completely custom built math library backs the 3D rendering", which means no third-party math dependency to reconcile. The editor is not a separate application bolted on. The README states that "the editor itself is a game running in the engine", which is the strongest architectural claim on the page: the tooling exercises the same rendering, UI and input paths your game will. Editor plugins are Go, so they compile into that same world rather than being interpreted at runtime. Live shader updates on GLSL changes and the retained-mode UI with optional HTML/CSS markup are the two features that most directly shape day-to-day iteration.

Cloning and building Kaiju Engine from source

The README gives two clone paths. The recommended one brings down the prebuilt libraries as a submodule, so you skip building Soloud and Bullet3. Run it from a shell with git available:

git clone --recurse-submodules https://github.com/KaijuEngine/kaiju.git

After that, the README assumes Go, C build tools, platform libraries and Vulkan are already installed. If they are, the build is two commands. The mkdir is needed because the output path is ../bin/ relative to src, and the tag list selects a debug build with the editor and file-drop support compiled in:

mkdir bin/
cd src
go build -tags="debug,editor,filedrop" -o ../bin/ ./

What you should end up with is a binary in bin/. The README also notes you can open the repository in VSCode or another IDE and start debugging from there instead. If you clone without --recurse-submodules, the same build command will not be enough: the README directs you to the Soloud and Bullet3 build sections of docs/engine/build_from_source.md first. On Windows, the README warns that a missing libstdc++-6.dll error at run time may require installing mingw, and points to an open issue about shipping those libraries in the prebuilts.

The editor is the weak point, and the README says so

This is the limitation that decides adoption. The README carries a work-in-progress banner and states plainly: "Though the engine is production ready, the editor is not". It then points readers at a separate Ad-Hoc editor readme at src/editor/README.md. Those two sentences sit in tension with each other in a useful way. The rendering, physics, audio and animation layers are presented as usable; the tool you would open every morning is described as unfinished. For a solo developer who is happy to drive scenes from Go code and treat the editor as a convenience, that split may be acceptable. For a team that expects a stable scene editor with predictable behaviour across releases, it is not, and the project does not claim otherwise. The release channel reinforces the point: the three most recent releases listed are all nightly builds, dated 2026-09-13, 2026-09-08 and 2026-09-07. There is no stable tagged release in that list, so pinning to a version means pinning to a nightly. The last push to the repository was on 2026-09-13. The README also makes performance claims, including a comparison against a Unity build of a black background and a cube, but those numbers come from the maintainer's own testing and the README itself links out to screenshots rather than a reproducible benchmark, so treat them as a claim rather than a measurement you can rely on.

Where Kaiju Engine is the wrong tool

Go is the scripting and gameplay language here, full stop. The README describes editor plugins as Go and the engine as written in Go; it does not describe a C#, Lua, JavaScript or visual-scripting path for gameplay code. If your team writes C# and has no appetite for Go, the language boundary you were trying to avoid is now the thing you are adopting. If you need a console target, the README lists Windows, Linux, Mac and Android only, with more platforms described as coming. If you need a mature asset pipeline, the README does not document one; it documents features and an editor readme. And if your project depends on a stable editor, the work-in-progress banner is the answer. A reasonable read is that Kaiju Engine suits programmers who want to write game code in Go and are willing to build tooling around an editor in flux. It does not suit teams that buy an engine for the editor and treat the code layer as a scripting afterthought, which is how a large share of commercial projects actually work.

Compared with Godot: same open source posture, different bet

Godot is the obvious alternative for anyone reading this page, and the difference is not the feature checklist. Godot's gameplay language is GDScript with C# and C++ options; Kaiju Engine's is Go, and the README frames that choice as the reason the project exists, quoting the maintainer's affection for C and the decision to port a C engine to Go. Godot's editor is a mature, central part of the product; Kaiju's editor is explicitly not finished, and the engine is the part described as production ready. That inverts the usual priority. If you pick Kaiju Engine you are betting that a Go codebase with Vulkan underneath, a custom math library and prebuilt Soloud and Bullet3 gives you faster iteration than learning GDScript, and the README's claim of "unmatched edit-build-launch speed" is the maintainer's argument for that bet, not a verified result. If you pick Godot you are betting on a finished editor and accepting a language you may not otherwise use. Neither is obviously right; they are bets on different parts of the stack. The same reasoning applies against Unity, which the README itself uses as its performance comparison point and which is closed source with a different licensing model entirely.

Licence and upgrade cost

The repository's licence is reported as NOASSERTION, which means the automated classifier could not place it in a known category. The repository does contain a LICENSE file and a licenses/ directory at the top level, so the terms exist, but anyone evaluating Kaiju Engine for commercial work should read those files directly rather than rely on a label. The licenses/ directory alongside a src/libs submodule of prebuilt binaries is worth attention on its own: Soloud and Bullet3 are separate projects with their own terms, and the prebuilts are distributed from a different repository. Nothing here is legal advice, and the practical step is to have someone read LICENSE, licenses/ and the submodule's terms before shipping. On upgrade cost, the nightly release cadence is the whole story: three releases in the six days before the last push, all labelled nightly, with no stable version in the list. If you build from master, you are tracking a moving target. If you build from a nightly tag, you get a fixed point but no compatibility promise, and the README does not document a deprecation or migration policy. Budget for reading diffs between nightlies rather than assuming an upgrade path.

Editorial conclusion

Adopt Kaiju Engine if you are comfortable in Go, want Vulkan rendering without writing C++, and can treat the editor as a moving target: the README states the engine is production ready while the editor is not, and releases are published as nightlies. Do not adopt it if you need a stable, versioned editor or a non-Go scripting path, because neither is described. Before committing, clone with --recurse-submodules, build with the debug, editor and filedrop tags, and check the editor README for the current state of the tool you will actually spend your days in.

Frequently asked questions

Official sources

1. Issues
2. KaijuEngine/kaiju on GitHub
3. Project website
4. README
5. Releases