GitHub is filled with these because it’s always easier to make an engine than a game. You play with the fun tech and make the graphics engine. You never make any tough tradeoffs because you don’t have a target to aim at.
When an engine becomes useful is when it has to make a game. All your abstractions tend to get rearranged and hard decisions are made.
It's easier to throw yourself into a programming project as a programmer than learn completely new skills: art, design, music. Instead the fantasy is that either the game engine is so great people will come make games, or the game engine will support something so radically different the programmer art gets ignored (see simulation games like Minecraft or Factorio). I'm convinced that's why there are so many engines with no games.
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.
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. ;)
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.
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.
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
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.
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.
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.
25 comments
[ 2.9 ms ] story [ 46.7 ms ] threadAre 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.
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.
https://unity.com/ leads with demos.
https://kaijuengine.org/ leads with a block of text claiming it renders cubes faster than Unity.
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. ;)
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.
If the author reading: I am curious to see an worked out example where writing the assembly code was necessary.
10/10
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.
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.
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.
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.