How do you compare engines?

This is a READ-ONLY snapshot of the Godot Community Forums when TwistedTwigleg was the owner, which is hosted for archival reasons only. The current Godot Community Forums can be found here.

Some links may point to external websites, including the current Godot Community Forums. These websites are not associated with TwistedTwigleg.

Tomcat

cybereality …and their engine is honestly a lot more advanced than Godot.

Here's an interesting question: how do you compare engines? It seems that the Reds have switched to Unreal, apparently their engine didn't suit them much. On Godot no big games, but maybe that's because it has not yet taken gamedev monsters.

Megalomaniak

Tomcat apparently their engine didn't suit them much. On Godot no big games,

It's not that their own custom built engine didn't suite them, it's that each generation of the red engine got more and more complex and that results in technical debt(more code to maintain, more code that can break, more code to constantly fix). They likely reached their limit on how much technical debt they could handle and realized they needed to move to an engine the core of which is maintained by someone else so they can avoid that technical debt. But CDPR also still wants to maintain the ability to make changes and adjust the engine to their own needs so that pretty much limits their choice to either Unreal or an open source engine like godot or O3DE. So Unreal it is then since CDPR is a long time nvidia partner and nvidia strongly supports Unreal.

cybereality

Tomcat how do you compare engines?

Well people get caught up with the render API or graphics, but this is actually a small part of it. Writing an OpenGL/Vulkan PBR renderer could take a few months, it's the rest of the engine that is important.

As an example, Unity and Unreal have SpeedTree integration by default, as well as robust terrain systems. You can create an entire forest landscape of AAA quality in a few hours.

Though Godot might be able to render it, you'd have to either buy SpeedTree and use the API to integrate it, or write an open source version yourself. And I'm sure the engines have optimized for rendering large items, something you would have to do as well.

Not like it's not possible with Godot. It's a matter of what comes by default, and how much time/money/effort you'd have to spend to get comparable results.

cybereality

If you have enough money, you can get the source for any engine. Even Unity does contracts for source access. They never say how much, but in the past I've heard figures of $500,000 or as much as $1M.

Which sounds like a lot, but for a company the size of CDPR, it's not that much money. But Unreal is technically a lot better for AAA, so I doubt they would choose Unity for their large titles.

Tomcat

I didn't expect it to deserve a separate branch… honestly…

I'd like to mention an engine that is rarely and rarely talked about, but which is vastly superior to Ureal in terms of features.

cybereality as well as robust terrain systems. You can create an entire forest landscape of AAA quality in a few hours.

.. And I'm sure the engines have optimized for rendering large items, something you would have to do as well.

UNIGINE has all this. It's strange that you don't hear much about it, although big games are coming out on it:

It has a free, limited version.

Sim SDK

The flagship edition, designed for simulation and training (of both humans and AI). Includes full support for planet-scale scenarios, immersive display setups, high-level IG system, and other enterprise features.

When I was choosing an engine for my project it was at the top of the list. What's the advantage of Godot over this monster (from my point of view)?

UNIGINE requires a good programming experience. Without a good knowledge of C++ there's absolutely no point in going into it. Godot is perfect for learning. Whatever the outcome, Godot is already in a niche market where it has no competitors.
UNIGINE is focused on working with 3ds Max and Maya. Godot has good integration with Blender.
Godot is evolving in a good direction and you can expect large spaces to be within its reach.
Separately, I want to note the system of assets in general and Destruction in particular.

For now I'm going to sit tight on Godot, but if in the distant wonderful future it becomes cramped — I will consider options.

Pixophir

Let's not forget, one doesn't need an engine to write a game, and a lot of games are written in a stand alone manner. There may be a bias in game engine forums because there are people who use game engines, but if you look at for instance gamedev.net there are a lot of people who brew their own frameworks, tailored to their needs, or none at all. Abstraction may be a nice thing, but it shouldn't be a purpose in itself, if that makes some sense.

Depending on the game of course, it might in the end be even more productive without an engine, because it takes a long time to get behind how a complex engine works, and how to make the most of it, how to bend the abstraction to one's will or adjust the will so that it fits into the abstraction, only to realise eventually that the corset said abstraction forces upon one needs too much adjustment, or isn't fit for the job.

In this case, rendering 10s of thousands of objects with instancing, using textures to modify individual instances, maybe in a dynamic manner, isn't a big deal on a lower level (C/C++/OpenGL4.5/Vulkan), but I doubt Godot has the right tools for this. I may be wrong, though, haven't tried in the engine.

cybereality

So Godot supports instancing. At least for static objects, and with the same material. I got up to 100,000 spinning cubes with the same texture, and I still had like 900 FPS. I tried with 1 million and it crashed my computer. But in the hundreds of thousands of objects is possible, even on mid-range hardware at 60 FPS, with the right optimizations. For example, if they are not animating, if they all have the same texture, though you can I think modify some properties (maybe a texture atlas with UV offset would work). And general rotation and position stuff. Having them be unique and animating is a huge issue, not just for Godot.

As I said, even AAA games have a lot of problems with this. Cyberpunk 2077 now has about 100 character on screen, but it didn't when it released. The city was much more sparse in the 25 - 50 character range, and it caused slow down. So this is difficult even for AAA devs with their own engine. I think anything is possible, with any engine or no engine. It just depends on how hard or time consuming it is, how much you have to use add-ons or modify the code, etc. I haven't looked into this aspect deep enough in Godot to say one way or the other.

Pixophir

I think one can animate instances. The necessary transformations would have to be done in the vertex stage, but I haven't done it by myself.

Putting so much load on a single shader stage will certainly cause a huge performance hit. One would have to explore the limits. But with today's hardware ...

Megalomaniak

This was clearly going a little too off topic, so split into it's own topic it was.

Pixophir

K :-)

How do I compare engines ? Well, do they run on Linux, are the sources accessible, are they worth spending my time :-)

And still I ask myself, do I really need an engine ?

Megalomaniak

Pixophir And still I ask myself, do I really need an engine ?

You can't develop a game without an engine. I think you mean 'do you need a IDE/editor"? Not every engine is a general purpose one. The idTech engine was pretty much just for doom and quake. There are other total conversion mod games that make use of the engine but they all remain very, uhh, quake-like for a reason. But there's still a clear engine in there or there wouldn't even be a game.

Pixophir

Sure one can develop a game without an engine like Godot or the other big ones. It may even be easier to do so, for a given case, and more flexible and performant anyway.

I am not talking about platformers or shooters or doing what everybody else can do, if it comes to simulation most engines I know are out of the question, or need such heavy internal programming that again an own framework may be quicker and easier.

Actually, the few games I like do not rely on an engine (Factorio, Orbiter, the X series, ...), or use in-house engines or frameworks. KSP was the only one among those that used Unity, and I have the feeling that curbs its development by a lot.

If only I was a real(tm) developer :-)

Tomcat

Pixophir Sure one can develop a game without an engine like Godot or the other big ones. It may even be easier to do so, for a given case, and more flexible and performant anyway.

I'm watching the development of a game on the author's own engine. The developer is of course a monster because he works alone. But the spectacle is sad. In a new version of the game are constantly appearing new bugs, fixing old bugs, leads to another bug. So a normal engine, at least, is very desirable.

cybereality

Well technically there is still some sort of "engine".

Even if it is not general purpose, there is an architecture that has to link various components (graphics, physics, sound, game logic, etc.) and this could be called an engine.

Granted, it can be simple, it may just be a huge C++ main() function with a ton of code in it, but it's some sort of architecture.

Pixophir

Oh semantics. But a linker is not a game engine.

It remains a fact that one does not need an engine like Godot to write a game, as actual games show. Though some may use in-house engines, others just use light weight libraries to achieve their goal, in which case I would not use the term 'engine'. There are shades of gray, in between, if you write a resource manager, or a scene graph, would you name that 'engine' ?

A game engine can make one's life easier, specifically for games like platformers, shooters, riddles, things that can be built from standard building blocks. If the planned game lends itself to the engine one can save a lot of time and concentrate on game logic and content creation. Most games do or can be made so. Most.

Megalomaniak

Pixophir others just use light weight libraries to achieve their goal

Semantics, sure. But the point is that bringing all these libraries together and writing logic on top of them results in a runtime that would be semantically classified as an 'engine'. As for rolling your own vs using an off the shelf one comes down to the needs and circumstances of a studio...

A small indie entity consisting of 2 programmers 1 with audio engineering expertise and another with computer graphics experience might find it easy enough to build their own and maintain it too so long as it doesn't grown too big and accrue unmanageable amount of technical debt. But as I brought an example of the Red engine earlier even big studios can end up in a situation where at some point the calculus says that it's better to pick a pre-made engine to use to avoid that technical dept or at least an overwhelming amount of it.

This is where I'd argue that Godot is actually a really good option, even in earlier versions godot had a fairly modular architecture but with godot 4 and the GDExtension API I think it becomes even better for this. You can still bring in your own custom solutions or other middleware and even the renderer architecture is pluginized where you can write your own renderer rather than use the default built-in one if your needs demand it but you don't have to build from scratch everything else, be it the IO/HID handling API's or the physics systems or what have you.

What is 'easier' is entirely subjective.

DJM

i dont really care what engine im using, if it gets the job done for what im aiming at im allright with it.
as they say , its not what u use, its how u use it. i simply chose godot because it was open source and was sick of unitys' politics and being bloated with features i didnt want nor needed.
there is no skill in creating a high quality terrain level with megascans and speedtree in unreal imo. ive seen dozens of those, they all look the same to me.
and the unity asset store makes it very tempting to just 'asset flip' and call it a day.

Lethn

It's all down to marketing and sometimes a bit of white lying mixed in with that, Unreal is getting such a boost because of how much big investor money is going into it which means they have better access to advertising as well as cough various government interests supporting them cough. So naturally that's what a lot of people are going to gravitate towards by default because they think big money = best software. This isn't necessarily true though as those of us in the know about software understand and depending on the situation open source software works fine in most use cases.

Depending on the situation I'm kind of glad that all the industry focus is Unreal, I wouldn't want special interests getting their greasy hands on Godot and potentially ruining a good piece of software that could be left alone. I very much like software to be stable and not interfered with, I like Blender for that reason as well because it means even if there's a pretty significant update I can choose whether or not to update to it and carry on working on my projects uninterrupted.

For the record, I'm also somebody who finally made the switch to Godot because of Unity's politics and nonsense, I was planning on it generally but I realised I was potentially putting myself at risk security wise even keeping that software installed on my PC. For what it's worth, I'm a dev that's looking to push Godot to the absolute limit.