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.
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. ;)
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.
TBH the weird C# version Unity uses has been an issue multiple times =)
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?"
Hard to interpret w/out more detailed comparison but stack-ranking their featurefulness, is it Unreal, Unity, Godot?
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.
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 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.
I just need a few more years working on my 4D non-euclidian voxel MMO engine before I can make my game!
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.
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 agree there is fun and learning to be had, but just note they are very different activities.
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.
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.
https://unity.com/ leads with demos.
https://kaijuengine.org/ leads with a block of text claiming it renders cubes faster than Unity.
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.
> The engine is not released and is under heavy development.
Development includes testing. A game engine's test is games. Lack of games speaks volumes.
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.
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.
> 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?
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
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.
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 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.
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.
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.
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.
If you spend a week in these engines you're well aware of the garbage collector.
Funnily enough whilst trying to Google gdscript and godot, I found this post I wrote in 2018 (subcomments mention gdscript and gc).
Maybe TinyGo can save their ass here?
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.
If the author reading: I am curious to see an worked out example where writing the assembly code was necessary.
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.
MoltenVK has some extra interfaces you need to integrate with too, it's not a completely hands off setup.
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.
10/10
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.
