[HN Gopher] Kaiju - General purpose 3D/2D game engine in Go and ...
___________________________________________________________________
Kaiju - General purpose 3D/2D game engine in Go and Vulkan with
built in editor
Author : discomrobertul8
Score : 135 points
Date : 2025-12-09 14:51 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| nsxwolf wrote:
| Vibe coded?
| TheDong wrote:
| Seems to have commits from 2023 and a copyright notice claiming
| "from 2015-present", so at least parts of it likely predate
| vibe coding.
| JokerDan wrote:
| Video from a few years ago that might offer some
| background/context.
|
| https://www.youtube.com/watch?v=hWVKeKpNQto
|
| The channel has a few videos on it, not watched any other than
| this introductory one but some of the titles look interesting.
|
| Also the introduction video above states an initial requirement
| of 'every PR must have a video' but it looks like that got
| dropped a while ago.
| kgwxd wrote:
| Is there something that gives it that impression? Didn't look
| at it too hard, but the readme tells a story of focused passion
| for the language, and programming in general. Vibe documented?
| nsxwolf wrote:
| Readme full of emojis.
| tptacek wrote:
| And grammatical errors. That Readme is obviously not LLM-
| generated. Come on.
| etse wrote:
| What's the challenge with getting it working in macOS? Vulkan?
| MindSpunk wrote:
| They're not using a library like SDL for windowing and input as
| far as I can tell. All the MacOS interfaces are in Objective-C
| or Swift, which I would wager (I've never used Go fwiw) aren't
| as easy to bind to from Go code.
|
| MoltenVK has some extra interfaces you need to integrate with
| too, it's not a completely hands off setup.
| bobajeff wrote:
| 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.
| unclad5968 wrote:
| In my experience, when using Unity, I became acutely aware of
| creating garbage and how to avoid it. I used to see a lot of
| object pooling which is basically a makeshift arena allocator.
| chekibreki wrote:
| Can you explain? AFAIK Godot uses C++ under the hood which does
| not have garbage collection. Other languages such as C# and
| GDScript use bindings.
| giancarlostoro wrote:
| Most people using Godot will be using GDScript or C# to make
| their games.
|
| Funnily enough whilst trying to Google gdscript and godot, I
| found this post I wrote in 2018 (subcomments mention gdscript
| and gc).
|
| https://news.ycombinator.com/item?id=16673751
| jayd16 wrote:
| Issue isn't about game devs it's about non-game devs backseat
| programming.
|
| If you spend a week in these engines you're well aware of the
| garbage collector.
| tapoxi wrote:
| GDScript in Godot doesn't use GC, it uses reference counting
| and doesn't "stop the world".
|
| Other languages that bind into the engine do this too, (C++,
| SwiftGodot, Rust-Godot)
|
| C# obviously does, Miguel de Icaza actually started SwiftGodot
| because he (ironically) ended up hating GC pauses after
| promoting C# for so long
| pjmlp wrote:
| Reference counting is a GC algorithm from CS point of view,
| as looking into any worthwhile reference will show.
| furyofantares wrote:
| It's not what people mean when they say GC though,
| especially in reference to games, where you care about your
| peak frame time more than about your average frame time.
| tracker1 wrote:
| You should watch some of the more recent Gamers Nexus
| videos... the average frame pacing counts for a lot, and
| they're making a concerted effort to show this, as it
| does represent the level of "jank" in games very well.
| furyofantares wrote:
| Got a link? I can't work out which ones you're referring
| to.
| starkparker wrote:
| most recently https://www.youtube.com/watch?v=qDnXe6N8h_c
| on why FPS is flawed specifically for GPU benchmarking
|
| most specifically, an ongoing attempt to understand and
| debunk frame generation (DLSS, etc.) as a performance
| gain due to introducing latency despite high FPS:
| https://www.youtube.com/watch?v=Nh1FHR9fkJk,
| https://www.youtube.com/watch?v=GDvfIbRIb3U
|
| More broadly than frame pacing,
| https://www.youtube.com/watch?v=Fj-wZ_KGcsg is a recent
| example of one of _many_ interviews going back years on
| why both frame times and frame rates are all flawed for
| explaining why some games feel smoother/lag more than
| others (there are GN videos dating back to 2016 on the
| subject)
| munificent wrote:
| Reference counting can also have very bursty performance.
| Consider what happens when you decrement the last
| reference to an object which is the sole remaining
| reference to an entire large tree of other objects. This
| will trigger a whole cascade of subsequent decrements and
| deallocations, which can be arbitrarily large.
|
| Of course, you might say, "Well, sure, but your reference
| counting implementation doesn't need to eagerly
| deallocate on dereference." That's true! You can write a
| ref counter that defers some of those deallocations or
| amortizes them across multiple operations.
|
| And when you do that, now you really do have a garbage
| collector.
|
| See: https://web.eecs.umich.edu/~weimerw/2008-415/reading
| /bacon-g...
| pjmlp wrote:
| People should learn their subjects properly, not street
| knowledge.
| tracker1 wrote:
| Go does surprisingly well at keeping GC freezes to a minimal
| in a way that you're unlikely to notice... C# has gotten a
| lot better since the core split as well. That said, there's a
| lot that comes down to how a developer creates a game.
|
| I was added late to a project working on a training
| simulation engine, similar to games, where each avatar in the
| game was a separate thread... man, the GC pauses on the
| server would sometimes freeze for literally 10-15s, and it
| was not good at all. I refactored it to use an event-loop
| model and only 2 other threads, which ran much better
| overall. Even though it wasn't strictly a game itself, the
| techniques still matter. Funny how running through a list of
| a few hundred things is significantly better than a few
| hundred threads each with their own timers, etc.
| Rohansi wrote:
| > _C# has gotten a lot better since the core split as
| well._
|
| It has improved but the majority of games using C# are
| using Unity which does not use .NET (Core). It uses Mono or
| IL2CPP specifically with the Boehm GC so it performs
| significantly worse than .NET and even standalone Mono
| (SGen GC).
| pjmlp wrote:
| Unreal devs have Unreal C++ dialect with GC, Blueprints and
| soon Verve to worry about.
|
| The times of pure manual memory management game engines, across
| all layers of what requires to draw a frame are long gone.
|
| Naturally someone is going to point out some game engine using
| compiled C dynamic libraries for scripting, those are the
| exception.
| groundzeros2015 wrote:
| 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.
| craftkiller wrote:
| > it's always easier to make an engine than a game.
|
| It could just be different interests. The kind of person who
| makes a game engine is a technical optimization-focused tech-
| focused person, sort of like a mechanic. In order to make a
| game, you have to deal with softer concepts like "is this fun"
| which is more like a designer/artist. Game studios need to
| bring these people together, but in the FOSS world the
| mechanics are happy to spend their time building an engine that
| runs beautifully without concerning themselves with the art
| side of things.
| CooCooCaCha wrote:
| Yes and no. It's true that some people really only care about
| a slice of the process, but if you've been around the gamedev
| scene long enough you'll also see people working on very
| technically ambitious projects while they're fooling
| themselves thinking they're making a game.
|
| I just need a few more years working on my 4D non-euclidian
| voxel MMO engine before I can make my game!
| groundzeros2015 wrote:
| In the real industry the very technical people are focused on
| very concrete problems like level 3 is causing too much
| overdraw on Xbox. What can we do without breaking X,Y, and Z.
| 6SixTy wrote:
| Why assume that a game has to be made? Making a handful of
| tech demos doesn't come with that baggage and deflects
| criticism of making an empty shell of an engine with nothing
| to speak of.
| jayd16 wrote:
| In so far as comparing levels of complexity, you're correct.
| But that's not the salient part of the the parent comment.
|
| A tool with a vaguely defined goals and no stakeholders is
| easier to make than a tool that must meet certain goals as
| defined by stakeholders.
| corysama wrote:
| Having spent a couple decades making engines that did ship
| games, now I spend a fair bit of free time helping noobs make
| engines even though statistically nearly none of them end up
| shipping games.
|
| Making a game engine is a fun and highly-engaging means to
| learning high-performance programming. Yes, it would be better
| if you also were able to invest enough to ship a game. But,
| don't let the infeasibility of that goal stop you from learning
| and having fun.
| groundzeros2015 wrote:
| I think it's very hard to learn high performance programming
| for real without facing real performance problems.
|
| I agree there is fun and learning to be had, but just note
| they are very different activities.
| Sleaker wrote:
| At what point of optimization does it turn into 'real' high
| performance programming?
|
| https://en.wikipedia.org/wiki/No_true_Scotsman
| groundzeros2015 wrote:
| When the goals are defined. What happens here is you make
| your cool particle System which is 10x faster than Ue5
| but ignore that it uses all the ram or whatever.
| serf wrote:
| >At what point of optimization does it turn into 'real'
| high performance programming?
|
| somewhat past optimizing the frame count of an entirely
| empty scene.
|
| on that matter : is it a game engine if there isn't a
| game?
|
| I totally agree with other comments though -- if there is
| no pressure to meet specific metrics or accomplish
| certain things with the product then there is no real
| pressure to improve past a window or framebuffer drawn to
| video, just declare it's a game engine that makes a
| million FPS and throw it on the portfolio.
|
| game engine work gets tough (and rewarding) with 1) goals
| and 2) constraints -- without those two it's more or less
| just spherical-cow style work that is too ambiguous or
| vague for real application.
| starkparker wrote:
| It's true. Code-hosting sites generally do host more coding
| projects than artwork, asset, and design projects.
|
| I usually look for games on websites like Itch.io. You might
| want to try that if you're having trouble finding websites that
| have games on them.
| johnnyanmac wrote:
| Its a nice portfolio project. A toy renderer (at least, when
| the job market wasn't so dearth) leading to a thesis or an
| engine programmer position at some AAA studio is a very
| worthwhile tradeoff.
|
| The skillset and ontent is also just different. You don't see
| games on github (publicly) because they are being made for
| sale. Very few engine projects are serious commercial projects.
| I think I'd be safe to say that a commercial engine is harder
| than making a commercial game. Especially since Unity and
| Unreal have mindshare and are free to start and learn with.
| samdoesnothing wrote:
| Making a game with Godot or Unity is much easier than making an
| engine.
| dexwiz wrote:
| It's easier to throw yourself into a programming project as a
| programmer than learn completely new skills: art, design,
| music. Instead the fantasy is that either the game engine is so
| great people will come make games, or the game engine will
| support something so radically different the programmer art
| gets ignored (see simulation games like Minecraft or Factorio).
| I'm convinced that's why there are so many engines with no
| games.
| pants2 wrote:
| 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.
| p2detar wrote:
| It says on the home page it's under development. I wouldn't
| expect any games made with yet.
|
| > The engine is not released and is under heavy development.
| MindSpunk wrote:
| 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.
| james2doyle wrote:
| Still not "9 times faster", and still seems disingenuous, but
| here is one comparison that is at least given with some more
| context: https://x.com/ShieldCrush/status/1943516032674537958
| ahZOTERESET wrote:
| Ppth(//news.ycombinator.com/-+).us
| johnnyanmac wrote:
| I see it as overhead for the base engine. Though yes, even
| unity has some post processing built in that would affect
| performance.
|
| But, I will always correct the cardinal sin of "using FPS to
| measure performance". Especially for an empty scene, this is
| pretty much snake oil. 200 fps is 5 milliseconds 1800 fps is a
| little pver half a millisecond. Giving back 4.5 milliseconds
| doesn't means much if any sense of real work will add it back.
| 999900000999 wrote:
| 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.
| nullbyte808 wrote:
| The binary compilation time advantage alone makes this a
| promising editor. All the other editors take ages even for simple
| builds.
| AmbroseBierce wrote:
| "You can assume or you can test"...he has the LinkedIn engagement
| bait babble down to a tee, that much is true.
| iamcreasy wrote:
| > 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.
| jdc0589 wrote:
| > How to build a Faraday cage for your bedroom
|
| 10/10
| artur44 wrote:
| 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.
| chrisjj wrote:
| Can it create sound?
| charcircuit wrote:
| 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.
| guywithahat wrote:
| 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
| kunos wrote:
| 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.
___________________________________________________________________
(page generated 2025-12-09 23:00 UTC)