[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 : 204 points
Date : 2025-12-09 14:51 UTC (1 days 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.
| numlock86 wrote:
| 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.
| 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).
| nottorp wrote:
| > 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.
| johnnyanmac wrote:
| 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.
| tapoxi wrote:
| Godot's C# is fairly recent, C#12/.NET 8.
| johnnyanmac wrote:
| That's good to know. So it probably has the capability if
| you really wanted to dig in.
|
| But that effort on an active engine would quite a long
| time to comb through. Really comes down to if a highly
| invested contributor wants to push it through and gets
| the go ahead.
| Rohansi wrote:
| Yes, as long as you're not using Godot 3.x. Some still
| use 3.x (Mono) because 4.x (.NET) does not support web
| exports.
| 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.
| johnnyanmac wrote:
| >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.
| pjmlp wrote:
| 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.
| johnnyanmac wrote:
| 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.
| 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.
| orangeboats wrote:
| >Why assume that a game has to be made?
|
| Well... the project calls itself a game engine. It's really
| not out of the world to make the assumption.
| 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.
| ChadNauseam wrote:
| 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 :)
| fwip wrote:
| GitHub is full of engines, itch.io is full of games. :)
| 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.
| groundzeros2015 wrote:
| 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
| samdoesnothing wrote:
| Making a game with Godot or Unity is much easier than making an
| engine.
| filleduchaos wrote:
| I think they are referring to the game _engine_ developers in
| both cases.
| samdoesnothing wrote:
| Why would game engine developers want to make a game
| though? Plenty of devs prefer building the underlying
| frameworks and tools over the products those tools create.
| 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.
| chrisjj wrote:
| Every major established engine is under development yet has
| many games to show.
|
| Development includes testing. A game engine's test is games.
| Lack of games speaks volumes.
| efskap wrote:
| 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.
| filleduchaos wrote:
| A screenshot (better yet, a GIF) gives you at least a basic
| idea of what the engine's renderer can do.
|
| You can push triangles and run shaders in pretty much every
| UI framework on earth and yet for some strange inexplicable
| reason people tend to want to see what the framework can
| actually do.
| CJefferson wrote:
| 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.
| 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.
| eek2121 wrote:
| Agreed. Unity has a ton of features that even Godot lacks.
| (Unreal also has a ton of features they all lack).
|
| I know a lot of different languages and frameworks, from C/C++
| up, so I say this: The language is never the issue. Language is
| just syntax. ease of use is everything.
|
| I've been wanting to make a game for a long time. I toyed with
| OpenGL/DirectX at multiple points since the 90s, even going so
| far as to creating a really cool tech demo/engine that scales
| with CPU core count. However, those days are in the past. I
| really want to focus on not writing a ton of graphics and sound
| code. I really want to focus on the game logic and the game
| itself.
|
| The above is one of the reasons I'm finding it hard to get into
| Godot, even though I *really* like the project (and wish I
| could fund it, alas, I'm unemployed, permanently). Unity just
| happens to be robust enough that I might be able to scrap
| together a prototype. It has built in things like a terrain
| editor, tons of educational material, an asset store to get
| some placeholder assets, etc.
|
| I saw a comment mentioning how Warcraft 2 was so awesome
| because it had a great editor. I saw that and also Starcraft
| had an amazing editor. Neverwinter Nights also had an amazing
| editor. We need something like that with a good license to
| build games. Every engine that even somewhat approaches that
| area blows up in complexity, has a super restrictive license,
| or doesn't allow you to build your own executables.
|
| RPGMaker actually is pretty decent for 2D games, however the
| fixed resolution and constant dramatic shifts between versions,
| previous licensing issues (I haven't looked at their current
| license), and more make it a no go for a serious commercial
| game...and it doesn't do 3D.
|
| Sorry for the rant. Don't even get me started on how much more
| complicated the transitions from DX8-DX12 or OpenGL 1.x/2.x ->
| Anything else have been. ;)
| crq-yml wrote:
| There's a cruel truth to electing to use any dependency for a
| game, in that all of it may or may not be a placeholder for
| the final design. If the code that's there aligns with the
| design you have, maybe you speed along to shipping something,
| but all the large productions end up doing things custom
| somewhere, somehow, whether that's in the binary or through
| scripts.
|
| But none of the code is necessary to do game design either,
| because that just reflects the symbolic complexity you're
| trying to put into it. You can run a simpler scene, with less
| graphics, and it will still be a game. That's why we have
| "10-line BASIC" game jams and they produce interesting and
| playable results. The aspect of making it commercial quality
| is more tied to getting the necessary kinds and quantities of
| feedback to find the audience and meet them at their
| expectations, and sometimes that means using a big-boy engine
| to get a pile of oft-requested features, but I've also seen
| it be completely unimportant. It just depends a lot on what
| you're making.
| chrisweekly wrote:
| > _" Unity has a ton of features that even Godot lacks.
| (Unreal also has a ton of features they all lack)."_
|
| Hard to interpret w/out more detailed comparison but stack-
| ranking their featurefulness, is it Unreal, Unity, Godot?
| ChadNauseam wrote:
| Unity can't really be said to have less or more features
| than Unreal IMO. Each has features lacked by the other, and
| neither lacks anything really major. But if I had to pick
| one for being the most featureful, I'd pick Unreal. Unreal
| has a built-in visual programming language* and some very
| advanced rendering tech you might have heard about. Unity
| has tons of features for 2D games lacking in Unreal and
| supports WebGL as a build target.
|
| (Though imo unity is the better engine. Unreal has so many
| bugs and so much jank that to make a real game with it you
| basically need a large enough team that you can have a
| dedicated unreal-bug-fixer employee.)
|
| *Technically Unity has a visual scripting language too but
| IIUC it's tacked on and I've never heard of anyone actually
| using it.
| theshrike79 wrote:
| > I know a lot of different languages and frameworks, from
| C/C++ up, so I say this: The language is never the issue.
| Language is just syntax. ease of use is everything.
|
| TBH the weird C# version Unity uses has been an issue
| multiple times =)
| doctorpangloss wrote:
| "I'm authoring a new Golang based firmware for a
| retrocomputer I literally pulled out of the trash that nobody
| will use"
|
| HN: "Ah you're sweet"
|
| "I'm authoring a new Golang based game engine that doesn't
| have the featureset of things with $100 million to $3 billion
| of product development"
|
| HN: "Hello, human resources?"
| 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.
| drnick1 wrote:
| 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.
| maccard wrote:
| Every game made with Unreal has GC bolted onto it. GC is
| absolutely viable for shipping games.
| drnick1 wrote:
| 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.
| jerf wrote:
| Which can rapidly exceed in size and count the "non-user-
| facing" objects.
|
| This objection really needs to die. GC does not instantly
| mean you can't program games. At most it locks you out of
| the tip-of-the-tippy-top AAAA games, but if you were trying
| for that you weren't going to use "someone's GitHub
| project" anyhow. And most of them probably have meaningful
| GC in them anyhow.
| wredcoll wrote:
| Minecraft.
| jedbrooke wrote:
| to be fair minecraft Java edition isn't exactly known for
| having great performance. It will run on a potato, but still
| runs like a potato even on fast hardware.
|
| This is also not mentioning that the by far more popular
| version of the game (by player count) "Minecraft Bedrock
| edition" is written in C++ precisely for performance reasons
| on low end mobile hardware
| cxr wrote:
| You're moving the goalposts.
| mvdtnz wrote:
| The author calls this out and tries to brush it off with FPS
| figures,
|
| > The current version of the base engine renders extremely
| fast, faster than most would think a garbage collected language
| could go. In my testing a release mode build of a game in Unity
| with nothing but a black background and a cube runs at about
| 1,600 FPS.
|
| But straight-up FPS is generally not the main concern with GC
| in a game engine, it's GC pausing which can make an otherwise
| smooth game feel almost unplayable. I don't know anything about
| Go so maybe this is less of a concern in that language?
| efskap wrote:
| Why not respond to the author's justification for it, displayed
| right on the linked page?
| system2 wrote:
| Kaiju means giant monster in Japanese, by the way.
| jadsfwasdfsd wrote:
| Why would you want segmented stacks, cgo FFI overhead,
| goroutines, & asynchronous preemption for a game engine? Odin is
| better suited than Go is for this type of software. Almost any
| programming language would have been a better choice here. This
| is rage bait I'm sure.
|
| Maybe TinyGo can save their ass here?
| slingexe wrote:
| People love making game engines, but to actually make a full game
| out of that is an entirely different challenge.
| Aeolun wrote:
| The star history of this project is really funny.
| liampulles wrote:
| 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.
___________________________________________________________________
(page generated 2025-12-10 15:01 UTC)