Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

31–40 of 111 posts

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

#31

Post by artur44 »

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.

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

#32

Post by furyofantares »

tracker1 wrote: post #26
furyofantares wrote: post #20

Earlier quoted context omitted.

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.

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.

Got a link? I can't work out which ones you're referring to.

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

#33

Post by groundzeros2015 »

craftkiller wrote: post #21
groundzeros2015 wrote: post #9

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.

> 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…

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.

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

#34

Post by groundzeros2015 »

corysama wrote: post #28
groundzeros2015 wrote: post #9

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.

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…

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.

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

#35

Post by james2doyle »

MindSpunk wrote: post #15

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 h…

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

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

#37

Post by tptacek »

nsxwolf wrote: post #30
kgwxd wrote: post #7

Earlier quoted context omitted.

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?

Readme full of emojis.

And grammatical errors. That Readme is obviously not LLM-generated. Come on.

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

#38

Post by munificent »

furyofantares wrote: post #20
pjmlp wrote: post #19

Earlier quoted context omitted.

Reference counting is a GC algorithm from CS point of view, as looking into any worthwhile reference will show.

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.

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...

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

#39

Post by 6SixTy »

craftkiller wrote: post #21
groundzeros2015 wrote: post #9

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.

> 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…

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.

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

#40

Post by charcircuit »

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.

Post reply on HN