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

81–90 of 111 posts

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

#81

Post by ChadNauseam »

jayd16 wrote: post #47
craftkiller wrote: post #21

Earlier quoted context omitted.

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

I'd disagree. Just like how no one needs to find an engine usable, no one needs to find a game fun. My personal itch.io account is full of games no one finds fun :)

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

#82

Post by drnick1 »

maccard wrote: post #62
drnick1 wrote: post #60

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.

Every game made with Unreal has GC bolted onto it. GC is absolutely viable for shipping games.

I don't think that's quite true. While Unreal has a GC, it's not used for the low-level components, only for the "user-facing" objects.

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

#83

Post by CJefferson »

efskap wrote: post #65
pants2 wrote: 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.

What does a screenshot of a game tell you about the engine or the developer experience? If you can push triangles and run shaders you can render anything.

For a start, it tells you the engine can actually be used to make a full finished game — which with hobby game engines isn’t a guarantee. If you want me to use an engine, I’d like at least one finished game, preferably even released on Steam.

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

#85

Post by liampulles »

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.

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

#86

Post by numlock86 »

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.

You know why LLM text is full of emojis?

drumroll

Because people have been using a lot of emojis before LLMs in text already, and LLMs have been trained on those texts.

This whole "You have emojis in your text, it's LLM!"-trope got boring really fast. Amazing to see (and to think of the implications of) so many people apparently being in emoji-free social bubbles before this, though.

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

#87

Post by nottorp »

tracker1 wrote: post #25
tapoxi wrote: 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…

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

State machines are not in fashion. Exposed event loops are not in fashion. Most frameworks do their damnedest to hide those components.

As for GC freezes, if you're doing a game like project you can always just allocate a few huge arrays at startup and reuse those with no deallocation/allocation in most garbage collected environments.

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

#88

Post by pjmlp »

johnnyanmac wrote: post #59
pjmlp wrote: post #18

Earlier quoted context omitted.

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.

>The times of pure manual memory management game engines, across all layers of what requires to draw a frame are long gone. That's what makes me curious about Rust engines like Bevy. Could is truly pull it off and bring back that kind of thought to game development? It's not "pure manual memory management", but the mindset of Rust requires that kind of thinking. It will definitely be niche for times to come, since mo…

Thing is, FPS don't make fun games, what makes games fun is a great design, delivered in a way that overall performance doesn't hinder the experience.

That is why games like Minecraft, Roblox, Celeste, Balantro make it big. None of them would have happened if the creators followed the advice 100% C coding (or C++ for that matter) was the only way, and yet their design is what made them shine.

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

#89

Post by groundzeros2015 »

johnnyanmac wrote: post #46
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.

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

In order of difficulty: 1. Making an engine with no game 2. Making an engine that ships one game 3. Making an engine that ships multiple games

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

#90

Post by johnnyanmac »

pjmlp wrote: post #88
johnnyanmac wrote: post #59

Earlier quoted context omitted.

>The times of pure manual memory management game engines, across all layers of what requires to draw a frame are long gone. That's what makes me curious about Rust engines like Bevy. Could is truly pull it off and bring back that kind of thought to game development? It's not "pure manual memory management", but the mindset of Rust requires that kind of thinking. It will definitely be niche for times to come, since mo…

Thing is, FPS don't make fun games, what makes games fun is a great design, delivered in a way that overall performance doesn't hinder the experience. That is why games like Minecraft, Roblox, Celeste, Balantro make it big. None of them would have happened if the creators followed the advice 100% C coding (or C++ for that matter) was the only way, and yet their design is what made them shine.

You're not wrong. But consider a different lens:

Celeste isn't a game that would need to worry about performance in 2018. It's 2d sprites with box collisions and relatively minimal particle effects. Your toaster can run Celeste.

But a game like Factorio with heavy simulations and complex interactions and pathing absolutely needs to consider performance to pull off a seemless experience.

Those are the kinds of games I'd hope engines like Bevy could enable farther down the line. Design is still key, but some game types are a larger technical challenge than others.

Post reply on HN