One of the most demanded features in Godot is terrain support, so I want to clear some misunderstandings regarding its future availability on the engine.
If you are interested in this being supported in Godot, read this thread! 🧵
Unlike other features provided built-in, terrain is _very_ high level. More often than not because its not just terrain alone. You want to be able to draw foliage, complex materials, water, manage object instancing, LOD strategies, non heightmap geometry, trigger logic, etc..
Like, sure, you may want it for quick prototyping, but where to draw the line of what is prototype and what is not is not simple. We even ran into these types of issues with CSG. It was for prototyping until more and more users want more complex features to use it in production..
If we implemented this feature built-in, due to its high level nature, most advanced users would want to keep adding more and more features to it in order to satisfy their game needs. Ultimately, they would need to keep a fork of the engine, and this is unfortunate..
So, the solution to this is to implement terrain as an add-on, even an official one. This way we can keep adding more and more features to it without worrying about bloating the engine for the users who don't need it and without forcing users to fork it if they add their own..
So what stopped us from doing this? Why does it not exist yet? well, it's just that this needs to rely on Godot 4 features and them being stable:
* GDExtension
* The new rendering APIs
* Editor APIs
* etc..
These prerequisites are only being met *now* as we reach stable release, so any work on terrain will not make sense happening (at least extensively) until after that.
Of course, we also rely on contributors wanting to work on this feature and/or donating their implementation..
So, after Godot 4.0 is out, what will happen officially is to start work on public proposals to define the extents of this feature with the help of the community. Then, we will see who is interested in working on it, whether it needs financing and how to procure funds if so..
That's pretty much it. Its something that should happen at some time (hopefully soon) but not before 4.0 is out. Thanks for your understanding!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Article attempts to make it clear, but just in case:
Godot is NOT aiming to become an AAA engine.
It aims to be an Indie/AA engine that is be easy to use and has graphics as beautiful as any other commercial engine..
Does this mean it can't be eventually used for AAA? 🧵
No. AAA engines are either custom engines made from the ground up, or commercial engines that are massively changed to fit a incredibly large game and team.
Even most AAA titles made with Unreal (if not all) do very significant modifications to it..
If Godot were to be used to make an AAA title, it would still be massively modified in order to be useful. This is what the developers of Sonic Colors Ultimate did.
This means, a lot of the engine in current form would be useful, a lot would not.
A weak point in the upcoming Godot 4 (where many users have issues with) is physics, where we had to revert to work further on Godot Physics (our own) and drop Bullet. Many suggested Jolt, but this won't cut it either. I think it was never entirely clear why we have to do this..
Reasons are very technical and, ultimately, are because Godot is a _very_ general purpose game engine where users do all sorts of things. As such, it needs extremely precise collisions to not run into corner cases. Bullet and Jolt use approximations that will not always work..
Unity and Unreal use PhysX for this reason, which is a more precise physics engine. The problem is they have reach to @nvidia (PhysX may be open, but development is not) and can get changes made to adapt it to their engines merged. We can't do this..
One notable thing that happened in Godot 4 development cycle is all the backlash we got due to removing the "xxx_degrees" properties (which will come back btw). A lot of users were disconcerted by this, but it was all a big misunderstanding, resulting from an early mistake..🧵
Godot always did all the mathematics in radians, because this is the standard in pretty much all technology. Math functions read and write radians, so exposing properties in degrees would be counter productive.
Of course, for _editing_ rotation values, degrees is always easier..
And this is what gives origin to the problem. The inspector until Godot 3 just takes properties and lets you edit them. This is a problem because the rotation properties are in radians.
Because of this, extra properties trailing "_degrees" were added, but I made a mistake..
Since I see this asked a lot, I will try my best to explain why the upcoming @godotengine foundation can't offer Console ports. There is a lot of detail I can't say because it requires signing NDAs with the console manufacturers, but trying my best in this 🧵.
1) License incompatibility: Even if we now have our own entity and we could theoretically register as console developers, there is a license incompatibility that makes it impossible to publish the source code of console ports into GitHub and integrate it with the rest of Godot.
2) Conflict of interest: Godot Foundation is a not for profit charity with its mission which is to receive donations to develop Godot Engine as FOSS for everyone to use.
Consoles are proprietary by nature, and code can't be made as FOSS, so it would be misuse of donations.
I've recently heard from a couple of developers that some publishers are wary of taking in games made with Godot.
While this odd stance is changing for the better (there were multiple commercially successful games made with Godot the past two years, with known publishers).. 🧵
I think it's fair to understand a bit better what the publisher business model is, so developers can be a bit more wary and understanding.
I will try to give some of my experience with this on this thread (published many games for mobile/desktop/console using Godot in the past):
Traditionally, publishers were the entities with access to the retail market. This is not as much the case now.
Nowadays, publishers act more similar to investors. The "standard" deal (from where negotiating) is they pay for 100% of the game development, they get 50% profit..
This is obviously Godot 4.1 material, but on the rendering side, we are contemplating having the following options towards the future, which makes more sense given the Godot user base:
1) A "compatibility" renderer, similar to a mix between GLES2 and GLES3 in Godot. Features/performance more similar to GLES2 but running on GLES3. This will run in very old phones, and PCs > 2005 (DX10 level). This is currently a work in progress by @john_clayjohn..
2) A "main" renderer, primarily focused on flexibility. This will run over Vulkan,DX12,Metal level hardware and the aim is that you can get very good looking graphics that run on every mainstream hardware from the past 5-8 years..