Nick Caston
1 HN recommender · recommended in 5 months, 2020–2021
27:56 · 687K views · Dec 18, 2019
Nick Caston compares Unity's sample ECS/DOTS project (AngryBots) with his own from-scratch C++ and OpenGL clone. He benchmarks performance and discusses the effort involved in each approach.
HN uses it as concrete data in game engine debates, showing a custom engine far outperforming Unity at several times the effort.
8 comments from Hacker News
A great demonstration of how unity is bloated: this video Unity is targeting students and gamedev wannabees. You don't make a game with a framework. Programming is not simple. Same debate of framework vs libraries. I'm even against Godot, which you cannot even use as a rendering library. You end up being too dependent on those platforms and all their assets and plugins. Of course if you intend to make a game that's not too ambitious, if it revolves around the graphics, unity might be ok, but it's just a sophisticated RPG maker 3D. I strongly advise against learning unity or godot. A huge problem is that unity/unreal made it difficult for classic engines/renderers to keep thriving, and it's hard to find a good engine nowadays. There are some, of course, but their community is non-existent, which makes things much harder in open source.
If one doesn't understand how a game works, a framework is not going to help. This person will probably shoot himself in the foot. Here is a good video about benchmarking unity this video
I never managed to like unity or godot because they remove freedom from the developer. Your code becomes a second class citizen. Apparently level design people and artists like it, which makes sense, of course, since indie gamedevs and small teams who are full of ideas and content, want to work as quickly as possible. But as a developer, I just loathe those tools. They sort of make sense for non-developers who want to make a prototype game and "tweak" things by writing as little code as possible while getting bleeding edge graphics. In reality it just enables unambitious projects so that "anybody can make games". It's like comparing LEGO to mechanical engineering. Of course, if you're pedantic, a LEGO car fits the definition of a car. You can sell a lego car, and then you realize how twisted the indie video game market is right now. But if you want to make a game, those WYSIWYG things are horrible. They're viable, but if you have some issue or limitation with the tool, you're really stuck. If there's a performance problem, it becomes more difficult. If you want to release on console, there are additional steps and work to do. You cannot "use what you want", because it's a huge generic blob of things that you cannot really understand how it's made. I watched a video about the internals of godot and was not convinced at all. Of course it's open source but it's a giant mess. Unity is not even open source. I will always show this video each time those WYSIWYG tools are talked abo
I tried to learn it a little but I did not manage to understand how it works, I don't really like the whole WYSIWYG thing, it forces the developer to surrender control, and you waste a big amount of time teaching yourself how it works internally, time that could be spent being productive with a simple renderer. It also seems to support c++ as "gdnative", although it requires another compiler to link against godot's binaries. It seems awkward because you still need to use the godot editor, and there is still a lot of interfacing to write. It seems like a good alternative to unity, but in the end, all I want is an engine, not a "framework" or some awkward scene editor with some kind of Node hierarchy/interface. I could say the same thing about UE4. I hear everywhere that's it's the place to go, that "everybody uses it and it's the norm in the industry if you want to make a game from scratch", but the reality is that those frameworks are too big and too feature rich. It sounds like they want to attract young developers to lock them into those awkward frameworks, because they advertise it as being full-featured engines, but small developers might not really need to focus on bleeding edge rendering, so it doesn't make sense. I know there are engines like Ogre3D, but I would rather spend time learning an actual universal graphics API that works on all hardware, which has more value on a resume, and I can just use what I need. All other things like audio, animation, inputs, physics,
Let's not guess and simply checkout a fair comparison, like this gentleman did: this video From his perspective as an experienced developer, it took 3.4x more effort to implement a very basic project versus using a fully featured engine. And that's ignoring the editor part, not to forget. I'd call a factor of 3.4 quite significant. In more general terms, it's the difference between actually finishing a game in a 3½ months vs a full year. In other words, you could finish 3 projects in the time it takes you to fully handcraft one, with the added advantage of OOTB multi-platform support. So reality seems to disagree with your "not really saving you that much much time" assumption. It's the small conveniences that add up quickly: exporters/importers for assets, in-game editors, readily available prefabs/blueprints for all kinds of components, stuff like that. Of course it's not rocket surgery to use SDL and a handcrafted engine for a quick little project. Yet, I've witnessed far more game projects die (especially by beginners) that went the handcrafted all-the-way route versus people using game engines.