Unity DOTS vs Handbuilt: Sample Project

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

> ... it greatly decreases your time-to-market to do things in a straightforward way ... I'd actually like to link the YouTube channel of a person who is writing their own game engine and game at the same time: link You can see how using Godot, Unity or Unreal (or most other engines) would have been much faster in regards to time to market. Similar differences show up when you try to build the same project, once while using an engine and another without it, the performance can be much better if you write your own optimized code (supposing that you can do so in the first place), however the development still takes much longer, for example: ▶ this video Now, whether that matters to you or not is a different matter entirely: some care about learning a lot more about the lower level stuff, others just want to develop games and care more about the art/story/etc., while others care about selling them ASAP.

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.

> In many cases, this software doesn't even do anything that is functionally different from 10 or 20 years ago, but it still consumes many more resources I would argue that in most cases the choice is not between fast, optimized and slow, unoptimized software. The choice is between having a functioning program (using a universal, "reasonably" efficient stack) and not having one at all (because the amount of resources it takes to develop a customized, low-level implementation is prohibitively high). A good example: ▶ this video A custom 3D engine performs immensely better than a comparable Unity project, but it took the author 3 to 4 times the effort.

Here is an analysis of unity's performance ▶ this video My take on your comment is that the problem of electron is that it uses HTML.

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,