Kaiju – General purpose 3D/2D game engine in Go and Vulkan with built in editor

Seems like a cool project.

I don't understand why they're calling out the FPS of an empty scene as a useful number compared to Unity though. Ignoring that this engine will have a fraction of the features of Unity (the likely reason for the FPS number in the first place), it's just a useless benchmark because it's an empty scene. `while (true) {}` will get you the same thing.

I'd wish they'd highlight how the engine helps you make a game rather than arbitrary performance numbers on microbenchmarks that don't generalize to a real game project. You can absolutely be faster than Unity, but "9 times faster than Unity out of the box" is not a number people should take seriously without the context of where the number comes from.

I wish them well though. I'm always interested to see more work in implementing engines in GC languages. I'm personally quite interested to see what can be done in modern GC languages like Go or (modern) C# which provide lots of tools to limit GC pressure. Being able to write C-like code where needed in an otherwise managed runtime is a really powerful tool that can provide a best-of-both-worlds environment.

GitHub is filled with these because it’s always easier to make an engine than a game. You play with the fun tech and make the graphics engine. You never make any tough tradeoffs because you don’t have a target to aim at.

When an engine becomes useful is when it has to make a game. All your abstractions tend to get rearranged and hard decisions are made.

After 10 minutes of digging I managed to find one single screenshot of an actual game built with it. Isn't that the first thing a developer wants to see?

https://unity.com/ leads with demos.

https://kaijuengine.org/ leads with a block of text claiming it renders cubes faster than Unity.

I watched a video presentation and cringed a bit to be honest. I've done a bit of 3D with Go some time ago ( https://www.youtube.com/watch?v=cjn3twYB7xQ ) and quickly realized it's not a viable tool because of the huge FFI overhead... weird to see all this claims about performance in an engine that will leave so much on the table every single time it makes a call into Vulkan... as soon a decent scene will be added it'll crawl to a stop.

I wish Go didn't have this performance bottleneck because I really like the language and it would be a great middle ground for indie like games that don't want to follow the big engines route but sadly any kind of request of a faster path to call cgo was ignored by the Go team as games is not really something they are interested in.

Still best of luck to the guy but eventually he'll hit a wall and all the claims about performance will look funny.

The “9x faster than Unity” line also jumped out at me. Empty-scene benchmarks are basically a measurement of how thin your abstraction layer is, not how the engine behaves under actual game workloads.

What is interesting, though, is that engines like this often reveal how much overhead comes from tooling, scene graph complexity, editor integrations, GC pressure, etc. Sometimes a very lean engine feels “faster” simply because it avoids all the layers that a mature engine needs to support large teams.

I’d love to see a demo that stresses real systems — entity updates, materials, batching, physics, etc. That would say far more about the architecture than raw FPS of drawing nothing.

The binary compilation time advantage alone makes this a promising editor. All the other editors take ages even for simple builds.

I've been put off a lot of other engines and frameworks because I really miss programming in Go, so this is super cool.

Historically Go was viewed as not the best choice for game Dev because it's GC process was known to cause periodic blips of load, but I wonder now how smooth it is now. I believe one can also plug in arena managed memory and alternatives of that I'll.

About garbage collection:

Are there a lot of Unity/Godot devs unaware that their engines are using GC? I would assume they'd have accepted the cost of GC already.

Unreal devs I can understand having an issue with it though.

A GC language is a non-starter for a game engine, I thought this was "game development 101" level knowledge. There is a reason every major game engine actually used to make games is written in C++, with some scripting language on top of that for game logic if necessary.

Why would you want segmented stacks, cgo FFI overhead, goroutines, & asynchronous preemption for a game engine? Odin is better suited than Go is for this type of software. Almost any programming language would have been a better choice here. This is rage bait I'm sure.

Maybe TinyGo can save their ass here?

> the simplicity and "just works" of writing Assembly code was a great boost to my happiness.

If the author reading: I am curious to see an worked out example where writing the assembly code was necessary.

The star history of this project is really funny.

h.frameRateLimit = time.NewTicker(time.Second / time.Duration(fps))

On Windows this only has a resolution of ~0.5ms (down from ~15.6ms when this frame limiting code was written). It also is not synchronized to when frames need to be submitted which means that depending on when the timer is created it can result in the game having stutter.

"You can assume or you can test"...he has the LinkedIn engagement bait babble down to a tee, that much is true.

People love making game engines, but to actually make a full game out of that is an entirely different challenge.

What’s the challenge with getting it working in macOS? Vulkan?

Kaiju means giant monster in Japanese, by the way.

Can it create sound?

I love the idea of using Go for games, but go-routines and channels aren't really low-enough latency to be used in games. In particular, ebiten, one of the largest go game engines doesn't use a single go-routine under the hood for (presumably) this very reason. Attempting to use channels and such in my own project (https://thomashansen.xyz/blog/ebiten-and-go.html) left me with about 70% cpu utilization I couldn't pass

> How to build a Faraday cage for your bedroom

10/10

Vibe coded?

9x faster than Unity ?

With such an outrageous and unfounded statement, I'm just going to assume the project isn't worth taking seriously.

Make a real game first, and then we'll talk.