Godot Engine – A decade in retrospective and future
As a side project to get me back into lower-level programming, I&#x27;ve had the pleasure of working on a personal fork of Godot.<p>The engine&#x27;s simply fantastic from a programmer&#x27;s perspective. The code is readable, the architecture is quite intuitive, and with the exception of a few engine components, you don&#x27;t run into much in the way of incomprehensible spaghetti code.<p>Adding features is more or less trivial, as has been merging upstream modules from more modern branches into the project.<p>I see a bright future for the engine, especially after the 3.1 update, and I anticipate that it&#x27;ll start seeing significant commercial adoption in the second half of this decade (it needs a few more years of refinement and PR).<p>The release of the Vulkan renderer will be a massive boost to public interest, and developers will increasingly consider it for their next projects.<p>That said, I do have a few concerns about its development. I&#x27;ll preface these critiques with the fact that I&#x27;m working from 3.1 stable, and have only merged from 3.2 as needed.<p>There&#x27;s a wide-spread conception among the Godot community that Godot&#x27;s performance (especially in 3D) is abysmal. This has been blamed on a number of factors, such as the memory model (largely heap-based), and the rendering engine (it uses quite a bit more cpu time than it needs to).<p>It is exactly the second-issue that has lead many community members to see the Vulkan renderer as Godot&#x27;s salvation. I can&#x27;t speak to that, but as is, many of the criticisms Godot faces are legitimate.<p>But among the projects I&#x27;ve seen where performance has been an issue, it&#x27;s largely been the product of a developer&#x27;s failure to understand how the engine is processing their content, and by extension their failure to architect their game around that.<p>This is an issue many inexperienced developers run into on just about any engine. Godot also lacks editor tooling that would allow anyone but a programmer to easily mitigate these issues in a scene, even if they knew where the performance issues were. This, compounded with the fact that Godot has largely focused on accessibility first and foremost has resulted in a lot of inexperienced community members without much understanding of the engine&#x27;s internals to discourage people from even trying to adopt the engine for 3D projects until 4.0.<p>I hope that 4.0&#x27;s release will be enough to minimize what I believe to be largely a PR issue, but I also fear that the inevitable bugginess that comes along with an entirely new rendering architecture may just exacerbate them, or that it will simply fail to live up to the expectations of many people who expect a more modern renderer to somehow fix their poorly considered code.<p>I&#x27;m concerned that this will slow the engine&#x27;s development with respect to its tooling, as there are few people really testing the bounds of it&#x27;s capabilities and workflows.