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

51–60 of 111 posts

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

#51

Post by Sleaker »

groundzeros2015 wrote: post #34
corysama wrote: post #28

Earlier quoted context omitted.

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.

At what point of optimization does it turn into 'real' high performance programming?

https://en.wikipedia.org/wiki/No_true_Scotsman

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

#52

Post by guywithahat »

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

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

#53

Post by groundzeros2015 »

Sleaker wrote: post #51
groundzeros2015 wrote: post #34

Earlier quoted context omitted.

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.

At what point of optimization does it turn into 'real' high performance programming? https://en.wikipedia.org/wiki/No_true_Scotsman

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.

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

#54

Post by neonsunset »

Rohansi wrote: post #49
tracker1 wrote: post #25

Earlier quoted context omitted.

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

[dead]

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

#55

Post by serf »

Sleaker wrote: post #51
groundzeros2015 wrote: post #34

Earlier quoted context omitted.

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.

At what point of optimization does it turn into 'real' high performance programming? https://en.wikipedia.org/wiki/No_true_Scotsman

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

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

#56

Post by kunos »

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.

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

#57

Post by dexwiz »

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

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

#58

Post by johnnyanmac »

tapoxi wrote: post #17
bobajeff wrote: post #8

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.

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

I haven't dug deep enough into C# to say this with certainty, but I believe later C# versions allows you to do enough manual allocation to "almost" get around the garbage collector. As well as new calls to try and nudge the GC away from hot paths.

You need to be very disciplined to pull this off, though. LINQ is basically off limits, for example. And of course, Godot's C# is likely much older than these modern techniques to begin with.

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

#59

Post by johnnyanmac »

pjmlp wrote: post #18
bobajeff wrote: post #8

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.

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 most (non-AAA) games simply aren't going to worry about performance. But it might carve a solid community for those concerned with optimization.

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

#60

Post by drnick1 »

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.
Post reply on HN