Alternatives

To Godot, or not to Godot, that is the question.

Jump to the list if you’re looking for alternative, replacement, or complementary game engines, frameworks, and tools to Godot.

As someone who has been using Godot for years, I strongly recommend exploring alternative tools, whether you are currently using it or considering it for the future. Regardless of the reasons that might prompt you to switch to another game engine, such as feeling constrained by the engine’s capabilities or perceiving it as a bottomless pit or lacking direction, the following alternatives presented aim to fulfill that void.

Godot Logo Skull Proposal

Source: Godot Subreddit

My hope is that these alternatives will inspire you with possibilities beyond what Godot could ever offer. These options may also facilitate a smoother transition, covering various aspects of game development. It’s important to note that this list is opinionated and not exhaustive; it’s biased towards addressing what Godot users may find lacking in the engine in contrast to other solutions.

List

💡 To ensure a well-informed decision, refer to General Recommendation section, as it’s advisable to familiarize yourself with common misconceptions when choosing between game engines and frameworks, as well as considerations regarding 2D and 3D development.

Game Engines

  • GameMaker (GML, GML Visual) - A game engine primarily used for 2D games. Godot is de facto a direct competitor to GameMaker when it comes to 2D development. Both Godot and GameMaker have their in-house languages, GDScript and Game Maker Language (GML) respectively. Unlike GDScript, GML is more low-level, making it more suitable for professional game developers. While both are high-level languages, GML inherits constructs from C-like languages, unlike GDScript. GML exposes advanced data structures not available in GDScript, such as a grid or priority queue. For additional performance gains, the YoYo Compiler (YYC) can be used to produce machine code instead of interpreted code. Completely free for non-commercial use. There are also plans to add JavaScript support and open source various engine components.

  • Defold (Lua) — A game engine primarily used for 2D games, originally advertised as the ultimate game engine for web and mobile. The community highly appreciates its robustness and stability, unlike Godot, which often experiences frequent breaks and numerous regressions between versions. Although Defold is more minimalistic compared to Godot, Defold doesn’t attempt to reinvent the wheel. Originally owned by King Limited, it was later released to the public as a source-available project under Defold Foundation. Defold provides official integrations for mobile monetization services, unlike Godot, which offers this unofficially via Ramatak Inc by Godot’s co-founder on the side, creating a conflict of interest, see Companies vs FOSS.

  • Stride (C#) — A game engine with a focus on realistic rendering and VR applications. It’s important to note that comparing Godot to Unity is a common misconception. In reality, when looking for a close alternative to Unity, Stride stands out as a strong contender. Stride offers a comparative guide for developers with previous Unity experience, highlighting its familiarity. In contrast, Godot has removed all mentions of Unity from their latest documentation. Unlike the C# version of Godot, Stride can be used as a library, powering projects such as vvvv, a live-programming environment. Stride is a member of the .NET Foundation.

  • Open 3D Engine (C++, Lua, Python) — A versatile development engine for game, simulation, and multimedia creators. Unlike Godot, O3DE has built-in terrain support and PhysX integration, features that Godot’s leadership refused to accept for years despite community requests. The initial version of the engine is an updated version of Amazon Lumberyard. Ironically, even Godot’s lead developer himself unwillingly recommends using O3DE if you want something made by industry engineers! O3DE is a member of the Linux Foundation.

  • Flax Engine (C++, C#) — A game engine with seamless C# and C++ scripting and hot reloading, with a focus on performance. Provides Visual Scripting, the analogous feature which Godot unfortunately discontinued and removed from Godot 4.0. Flax offers a comparative guide for developers with previous Godot experience. Flax Engine is particularly appealing to those who have experience developing Godot modules and GDExtensions with C++, as it offers robust C++ capabilities. Interestingly, the author of Flax Engine has previously criticized Godot for its subpar performance, albeit indirectly and somewhat ironically.

  • Wicked Engine (Lua, C++) - A game engine that prioritizes modern graphics development. Can be used as a C++ framework for your graphics projects, a standalone 3D editor, Lua scripting or just for learning.

  • GDevelop - A game engine which is primarily designed for non-programmers and game developers of all skill levels, using event-based visual programming similar to engines like Construct, Stencyl, and Tynker. GDevelop is frequently mentioned by Godot users as an alternative to text-based programming, see also Simplicity. It was created by a software engineer at Google.

Frameworks, Environments, and Languages

  • BeefLang — a game-oriented programming language and IDE, without 2D/3D editor. The intended audience is the performance-minded developer who values simplicity, code readability, fast development iteration, and good debuggability. The syntax is largely C#-like, with D semantics. The IDE launch speed is unprecedented and comparable to launching a Notepad! Beef’s creator is a co-founder of PopCap games. Windows builds are prioritized over other operating systems.

  • Lobster — a game-oriented programming language that offers a comprehensive set of functionality out of the box. It features a Python-style indentation-based syntax with a touch of C-style flavoring, provides a high-level interface to OpenGL functionality, along with support for ImGui and more. Lobster’s creator is an ex-Google employee, who has started his own game development company to work on an unannounced voxel game using Lobster.

  • Panda3D (Python, C++) — a framework for 3D rendering and game development. Panda3D is not written in Python, it’s written in C++, Python is only used for scripting, so it can be extended in a similar way to Godot. Many Godot developers have previously expressed a desire to write games in Python because of its vast ecosystem and language capabilities, as opposed to GDScript. At the same time, Panda3D and Godot share a common approach to error handling: they almost never crash on error, and much code is dedicated to the problem of tracking and isolating errors. However, unlike Godot, Panda3D is not a beginner’s tool or a toy. Panda3D has been developed by Disney.

  • raylib (C) - A simple and easy-to-use C library to enjoy videogames programming. It focuses on simplicity and, due to its nature as a C library, allows the community to integrate and utilize many language bindings. Highly customizable, this library is primarily aimed at those who wish to delve into low-level game programming. With officially supported libraries such as raygui, it allows for the creation of straightforward immediate-mode GUIs (see Graphical User Interfaces for general information about the types of GUI programming systems).

  • LINQPad — an interactive playground designed for those who want to learn C# in an engaging and hands-on way. Especially useful if you want to learn C# game engines or frameworks.

  • ShaderED — a powerful shader IDE that surpasses Godot’s shader editor in terms of capabilities and debugging functionality.

You can also explore the Top Engines used on itch.io. However, bear in mind that the statistics primarily reflect the usage of game engines and frameworks for game jams, not necessarily commercial games. For even more complete list, see Wikipedia’s List of game engines.

General Recommendations

Despite the abundance of various alternatives, including the ones mentioned earlier, many individuals have expressed a lingering attraction towards Godot, even after encountering its limitations and bugs. The primary reason why such individuals may struggle in finding a suitable alternative can be attributed to several factors, with the following being the most significant:

  • The Internet is flooded with an overwhelming number of so-called recommendations for Godot. It is heavily promoted and advertised by overzealous followers and the Godot leadership themselves, even in contexts unrelated to game development, often creating false expectations for new users.
  • Some game engines, frameworks, and tools present a potentially steep learning curve that may seem too daunting. While you may believe that you don’t require a professional game engine, you still desire to have a cake and eat it too, or have the best of both worlds, which is very difficult to attain, if not impossible.
  • You might hold a certain level of hostility towards commercial game engines due to various reasons, such as economic constraints, a strong anti-corporate sentiment, or a perception that such corporate software feels cumbersome or bloated.
  • If you are deeply attached to Godot, especially if it is the only game engine you have ever used, you may be seeking an alternative that offers a 99% comparable experience to Godot. However, such an alternative does not exist, because every software is unique.

Some of the aforementioned factors originate from limiting beliefs (see Glossary). I encourage you to contemplate and eventually challenge those beliefs. One approach to overcome them is to embrace the growth mindset. Take a moment to ponder how you came across Godot and how much time you dedicated to researching and comparing various tools before arriving at your decision. It is possible that you may not have thoroughly explored other alternatives and simply jumped on the Godot bandwagon without much consideration. There is no intention to criticize your choice, but rather to underscore how susceptible we, as humans, are to being influenced into making decisions that may not align with our personal goals.

If you look beyond these recommendations, you will inevitably find a suitable replacement. When I mention “replacement,” it doesn’t necessarily mean finding a single product. Instead, try to find a set of tools that excel at specific tasks. In fact, “Godot” was initially just a set of assorted tools according to its pre-open-source history. Nowadays, Godot is marketed as an all-in-one solution, but none of its built-in tools can compare to dedicated solutions. In fact, Godot falls short in this aspect to such an extent that unofficial community frameworks or extensions like Goost and Godex were created in an attempt to address this gap.

However, regardless of the number of features added to Godot, this gap remains unfulfilled somehow. This can be attributed to several factors, including inherent design limitations arising from Godot’s object-oriented tree/node structure as opposed to adopting a more modern approach like ECS (which Godot will never officially embrace), Godot’s limited ability for deeper out-of-the-box Customization and “The One True Way” approach. If you happen to be a Unity user, one of the reasons why you might feel compelled to switch from Unity to Godot is due to the “grass is greener” effect. This is also why I recommend users who have already invested years in Unity against prematurely switching to Godot.

Programming Languages

If you aspire to be an indie game developer, it is advisable to learn C# or, at the very least, get familiar with it. Avoid delving into low-level languages such as C++ or Rust unless you’re working on performance-demanding games. The reason is that you might end up investing a lot of time contributing to game engines that utilize those languages or creating tools for them, which could lead you to gradually abandon the development of your own game. While engine development can be fascinating, especially when working on tools that grant a feeling of completion and satisfaction, it shouldn’t overshadow the primary goal of making games. However, if you are interested in specializing in certain aspects like domain-specific languages (DSL), which are common for those who enjoy modding and enabling user-generated content, that can also be a rewarding pursuit within the game development field.

For those who still think that Godot’s scripting language is unique and wasn’t inspired by anything, I hasten to enlighten you. Godot didn’t have GDScript right from the start. It used Squirrel and Lua years ago, also evident from the tolua++ tool maintained by Ariel Manzur, a co-founder of Godot, when Codenix, a company founded by Juan and Ariel, was still afloat. Lua has been employed in numerous tools and frameworks, making it a valuable language to learn.

For performance-minded and low-level enthusiasts, the Lua ecosystem includes LuaJIT FFI module (Foreign Function Interface), which allows you to bind external functions without unnecessary engine bindings or recompilation. You simply need to add declarations for the functions defined in a library, and voilà! Godot didn’t pursue this approach due to the de-facto Priorities, which are not focused on achieving absolute performance. With LuaJIT’s FFI, you can even define bindings for native OS functionality, such as MessageBox(), by providing the library name and declarations from the Windows API. It’s truly magical!

Engines versus Frameworks

Game engines and frameworks differ primarily in two significant ways that directly impact user-developers: the availability of an editor/IDE and the ability to access lower-level features. In the case of Godot, they attempt to offer a complete package that often appeal to students, at the extreme cost of limited access to lower-level features and the ability to extensively customize existing features for specific use cases.

For more details, you can refer to the Overview of Godot Engine and the de-facto principles inferred from Godot’s project management. However, there are no publicly declared principles accepted as official by the lead developer of Godot or any other trusted Godot member. As a result, Godot’s development vision remains unclear, as it is not documented in Godot’s official documentation. This lack of clarity may lead to potential bloat in the future. This is where frameworks come into play: if you care about size, frameworks often allow you to pick only the features that interest you, and instead of fighting against engine constraints, you have the freedom to realize your vision in any way imaginable.

Using frameworks, of course, usually comes with the drawback of a steeper learning curve. However, if you aspire to become a professional game developer, it is advisable to avoid confining yourself to all-in-one game engines, especially when some of them merely pretend to offer open-minded and innovative technology. Godot is no exception, as it suffers from the Not Invented Here syndrome, often reinventing the wheel instead of leveraging existing solutions. As you become more familiar with Godot, your chances of fitting in as a professional software engineer diminish, as many useful advanced features are hidden from users. Even if you choose to continue using Godot, I encourage you to step out of your comfort zone and explore alternatives, including frameworks, even if you don’t plan to use frameworks in your game development endeavors on a regular basis. Godot can be likened to a gold rush, except there is no gold to be found. Just look at the name, at least: Godot!

Having said that, if you happen to be an engine development enthusiast, you already possess enough skills to create your own perfect tool by combining existing open-source components. You may even fork Godot if you wish, like the authors of Goblin Engine did, but I don’t recommend forking Godot either, as you will inevitably inherit all the hidden limitations, bugs, and additional maintenance cost. See Blind Squirrel Entertainment’s experience developing Sega’s Sonic Colors Ultimate using a custom fork or a subset of Godot Engine codebase, which is riddled with bugs, again, see Priorities. Regardless, I kindly advise against becoming the person who says, “I could work on Godot for the rest of my life!” 😁

If none of the above options appeal to you, perhaps this may present a need for innovation. However, it is important to always strive for reusing existing solutions and avoid reinventing the wheel unless it serves the purpose of gaining a deeper understanding of the underlying technology. Whatever you decide to do, as a general rule, avoid presenting a toy project as an universal solution for all purposes and all people. 😊

2D vs 3D

As you may know, Godot is often touted to have so-called “dedicated 2D” engine. But game engines are not limited to exclusive 2D or 3D. It’s a misconception. Even if an engine is seen as 2D, they still all operate in 3D space under the hood, because that’s how most modern computer graphics work. While game engines may provide some 2D tooling, it doesn’t make them inherently or exclusively 2D. Engines may simply offer higher-level abstractions for working with 2D objects, such as canvases, layers, tiling, etc. Using 3D engines is as valid as using so-called “2D” engines for developing 2D games. For 2D, everything is orthographically projected onto the screen anyways. Therefore, you should not restrict your engine of choice merely because it has a “2D” label.

If you want to create a 2.5D game with pseudo-depth and parallax effects, implementing it using 3D techniques can be relatively easy with enough experience. Moving 2D layers along the Z-axis can achieve the desired effect. In contrast, in the case of Godot’s supposed focus on 2D and its separation of 2D and 3D functionality, you may encounter some peculiar design compromises. For example, the lead developer of Godot introduced an experimental feature that allows for “pseudo 3D support in 2D engine,” as he describes it. However, the complexity arises from the need to set up and update duplicate objects and properties between layers, which is actually a major drawback that undermines the alleged usefulness of such a feature. These limitations could have been avoided by solely relying on 3D techniques from the beginning.

Graphical User Interfaces

If you don’t want to limit yourself professionally, it is not advisable to rely on Godot for everything. You may even notice how Godot fans recommend using Godot as a general-purpose GUI “framework” to build pure GUI applications, be it desktop or mobile, which is certainly an overkill.

You can find more suitable frameworks for this, such as Qt. In other cases, if you would like to explore GUI development in the context of game development specifically, you can read this comparative essay by the author of BGFX, which serves as a decent waypoint.

This is more about using the right tools for the job. It is unreliable to utilize game-specific tools for developing desktop applications that don’t require any kind of 3D acceleration, just as using minimalist web frameworks would not be suitable for creating software like AutoCAD, for instance. Failing to use appropriate tools is an unsustainable approach. So, it is not solely about size, but performance and maintenance considerations. Moreover, Qt will always have more GUI features than Godot ever will, given the same size.