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.
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. ;)
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.
> 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 =)
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.
Speaking of bugs, I remember the last time I thought maybe I'd try making a simple game in Unity I gave up when I couldn't stop clipping through walls.
The collision was clearly working, just some n% of the time you'd end up on the wrong side of the clean flat rectangle you were walking into.
That's not a bug just an inherent problem with using very thin colliders with a discrete collision detection system.
It's not a Unity problem and Unity allows you to configure continuous collision detection to prevent tunneling https://docs.unity3d.com/6000.3/Documentation/Manual/Continu...
Game development is full of domain knowledge like this because games need to make compromises ensure completing simulation updates at no lower than 30Hz.
That's fair. I just remember being very frustrated that felt like a basic feature I was implementing per the tutorial broke immediately in such a fundamental way in such a simple situation, and not being able to find any sort of explanation or solution at the time. Possibly it was fully my fault and the info was readily available!
I think its really just the trappings of game development being full of tribal knowledge.
The tutorial probably should have instructed you create box colliders for walls (giving a greater area for the physics engine to catch collisions) rather than a simple plane/quad which would lead to the exact issues you had, or at least explained why a box works better than a plane.
I guess you have to balance the necessary information with overload in your tutorial or at least have an aside or additional reading that really helps understand many of these internalized understandings.
For performance/practicality, it's Unity > Godot > Unreal. Building something in Unreal that simply runs with ultra low frame latency is possible, but the way the ecosystem is structured you will be permanently burdened by things like temporal anti-aliasing way before you find your bearings. Unreal and Unity are at odds on MSAA support (Unity has it, Unreal doesn't). MSAA can be king if you have an art team with game dev knowledge from 10+ years ago. Unreal is basically TAA or bust.
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.
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 are happy to spend their time building an engine that runs beautifully without concerning themselves with the art side of things.
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!
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 :)
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.
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.
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.
>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.
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.
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.
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.
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.
OP is trying to make it seem like some sort of failing, where people aren't cut out for game dev or something so they just make game engines instead. But I can guarantee that anyone who can create a game engine can also create a game. They just choose to do something they enjoy more.
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?
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.
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.
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.
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.
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.
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.
Pretty much everything in unreal aside from the rendering code and platform interaction layers is written in uobject and actor land - which is garbage collected.
The rendering code also isn’t “just” not garbage collected - it eschews all the normal c++ and is written in a totally different way. It might as well be in a different langauge honestly
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?
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
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.
> 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).
> 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.
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.
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.
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)
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.
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.
>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.
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.
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.
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.
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.
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.
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
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.
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.
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?
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.
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.
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. ;)
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.
> 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 =)
"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?"
This would be a much better comment if it weren't for the snark and fake quotes.
> "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?
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.
Speaking of bugs, I remember the last time I thought maybe I'd try making a simple game in Unity I gave up when I couldn't stop clipping through walls.
The collision was clearly working, just some n% of the time you'd end up on the wrong side of the clean flat rectangle you were walking into.
I lost interest pretty soon after that.
That's not a bug just an inherent problem with using very thin colliders with a discrete collision detection system. It's not a Unity problem and Unity allows you to configure continuous collision detection to prevent tunneling https://docs.unity3d.com/6000.3/Documentation/Manual/Continu...
Game development is full of domain knowledge like this because games need to make compromises ensure completing simulation updates at no lower than 30Hz.
That's fair. I just remember being very frustrated that felt like a basic feature I was implementing per the tutorial broke immediately in such a fundamental way in such a simple situation, and not being able to find any sort of explanation or solution at the time. Possibly it was fully my fault and the info was readily available!
I think its really just the trappings of game development being full of tribal knowledge.
The tutorial probably should have instructed you create box colliders for walls (giving a greater area for the physics engine to catch collisions) rather than a simple plane/quad which would lead to the exact issues you had, or at least explained why a box works better than a plane.
I guess you have to balance the necessary information with overload in your tutorial or at least have an aside or additional reading that really helps understand many of these internalized understandings.
I'd say Unreal > Unity > Godot for feature space.
For performance/practicality, it's Unity > Godot > Unreal. Building something in Unreal that simply runs with ultra low frame latency is possible, but the way the ecosystem is structured you will be permanently burdened by things like temporal anti-aliasing way before you find your bearings. Unreal and Unity are at odds on MSAA support (Unity has it, Unreal doesn't). MSAA can be king if you have an art team with game dev knowledge from 10+ years ago. Unreal is basically TAA or bust.
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.
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
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 are happy to spend their time building an engine that runs beautifully without concerning themselves with the art side of things.
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!
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 :)
GitHub is full of engines, itch.io is full of games. :)
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.
>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.
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.
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.
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.
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.
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.
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
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.
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.
Making a game with Godot or Unity is much easier than making an engine.
I think they are referring to the game engine developers in both cases.
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.
Have you never heard of dogfooding?
Yeah, and?
OP is trying to make it seem like some sort of failing, where people aren't cut out for game dev or something so they just make game engines instead. But I can guarantee that anyone who can create a game engine can also create a game. They just choose to do something they enjoy more.
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.
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.
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.
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.
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.
You only need to call into C once per frame. Is the FFI overhead really that bad?
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.
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.
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.
What’s your definition of tip of the tippy top AAAA games? Because an awful lot of them are using unreal too!
Pretty much everything in unreal aside from the rendering code and platform interaction layers is written in uobject and actor land - which is garbage collected.
The rendering code also isn’t “just” not garbage collected - it eschews all the normal c++ and is written in a totally different way. It might as well be in a different langauge honestly
Why not respond to the author's justification for it, displayed right on the linked page?
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?
https://docs.unity3d.com/6000.4/Documentation/Manual/perform...
Minecraft.
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
You're moving the goalposts.
The binary compilation time advantage alone makes this a promising editor. All the other editors take ages even for simple builds.
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
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.
> 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]
> 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.
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...
People should learn their subjects properly, not street knowledge.
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)
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.
Godot's C# is fairly recent, C#12/.NET 8.
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.
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.
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.
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.
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.
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.
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.
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
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?
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.
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
> 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.
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.
"You can assume or you can test"...he has the LinkedIn engagement bait babble down to a tee, that much is true.
What’s the challenge with getting it working in macOS? Vulkan?
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.
Kaiju means giant monster in Japanese, by the way.
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.
Can it create sound?
The star history of this project is really funny.
> How to build a Faraday cage for your bedroom
10/10
People love making game engines, but to actually make a full game out of that is an entirely different challenge.
Vibe coded?
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.
Seems to have commits from 2023 and a copyright notice claiming "from 2015-present", so at least parts of it likely predate vibe coding.
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.
I don’t remember seeing technical documentation packed full of emojis until LLMs.
Guess you haven't been around much on GitHub before LLMs.
And grammatical errors. That Readme is obviously not LLM-generated. Come on.