Live data from Hacker News

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

github.com

41–50 of 111 posts

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

#41

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

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

#42

Earlier quoted context omitted.

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.

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)

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

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

People should learn their subjects properly, not street knowledge.

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

#44
post #13

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.

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.

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

#45

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…

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.

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

#46

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.

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.

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

#47

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

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

#48

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

Ppth(//news.ycombinator.com/-+).us

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

#49
post #17

Earlier quoted context omitted.

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

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…

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

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

#50

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.

Making a game with Godot or Unity is much easier than making an engine.
Post reply on HN