Why Godot game engine is awesome - Part 1

In this post I want to talk about the Godot game engine and why I've chosen to use and support it. Although it's fun to cast shade on the two major proprietary vendors in this space (Unity/Unreal) I'm going to focus on what I like about Godot. WARNING: I try to write in plain English, but this is a technical article. Some or all of what I say here is an opinion, and I'm interested to discuss opposing views. Feel free to reply with why I'm crazy :) 

Abstracting Complexity 

The computer industry is coming to terms with what the end of "Moores Law" means. One clear trend is that CPUs are shifting to having more cores instead of faster individual cores. This is true for personal computers as well as the rapidly growing "cloud computing" industry. One implication of this is that games need to rely less on a single process/thread and should make maximum use of the cores. The problem is, writing good multi-threaded/non-blocking code is notoriously difficult, even for veterans. 

This problem is compounded high-level game engines because they tend to attract many "entry level" developers who sometimes have no background in programming at all. Godot developers smartly use a series of threaded "servers" that are generally invisible to developers. This has been abstracted so well that it essentially tricks users into writing multi-core code without even knowing what the term means.

Similarly, all scripts are classes. Even if beforehand the user doesn't know OOO or what classes are, they should slowly build an intuitive understanding of it. 

Use the right tool for the job

Most game logic is easier to generate and maintain through scripting languages vs something lower level like C++.  Most performance sensitive code is written in a lower level language. What should a game use? Why not both! The built in high-level scripting language (gdscript) is designed such that its very easy to learn (modeled from python syntax), and focuses on making it easy for the developer to get things done quickly in few lines of code. 

This is great for writing and reading the code for rapid prototyping and large projects alike. The impact of these usability trade-offs is slower performance of gdscript vs lower level, statically typed languages. However, the built-in objects you generally manipulate with gdscript are part of the core engine and already optimized so this generally does not matter. A very small example is that the built in dictionary data type is ordered by default(unlike python), which can simplify common tasks in games. 

 Godot is designed to let you seamlessly couple custom, performant code from any language without recompiling the engine via the GDNative feature.  You can bind an API to your fancy new performant library into gdscript so  that you can have your cake, and eat it too.  

Stop problems before they happen

The initial excitement behind many popular practices / patterns in software engineering has been tempered by the reality of trying to use these paradigms in practice. One example of this is the use of multiple inheritance, which is considered harmful by many. A perusal of the mitigation strategies on Wikipedia show that this is an extremely difficult thing to get right, even for veterans. How does Godot sidestep this can of worms? For both scenes and scripts only single inheritance is allowed, period. This allows for some of the benefit inheritance can provide without the terminal complexity of unrestricted freedom.  

Enforced simplicity in scene architecture:

Each object or "Node" in a scene can only have one script attached to it and it is "always on". Newcomers from Unity might consider this a bug, but I consider it a critical feature. Attaching multiple scripts to an object, each of which can be disabled is a recipe for a sloppy, buggy project that is hard to reason about. 

Every scene tree has a single root node, all other nodes have a single parent. Maintaining a clear parent/child hierarchy is import for reasoning about behavior and instancing. 

"Plaintext Formatting" The "scene" files that are generated by the visual editor (2d and 3d) are stored on disk as plain text files. This is the great for portability and flexibility and should considered a Good Thing ®,this article expounds on the topic.

Working for the common good.

Altruism is great, but I also want maximize the utility of my work. All game engines are, by their nature, extremely complex and an ideal habitat for complex bugs. Tracking down these bugs and distinguishing them from errors in my own code takes time and time is money. I would rather give my time/money to a project which is open-source, instead essentially doing free work for a company I do not work for or am already paying.  I've been so happy with Godot I also contribute money monthly to Godot through Patreon.  I highly recommend this for all users who can afford it, as is it how the project has been able to hire its lead developers and PM to work on the project full time. 

Outside of making me feel good, it also gives me voting rights on the development roadmap and well as which official community demos will be created. 

Thats it for part one, but this is just the tip of the iceburg for why I think Godot is awesome. 

-Al Shady