For a happy life pick Godot Game Engine
I don’t have much experience with game development in general. By day I’m a backend developer working primarily with Elixir. As a result, I don’t have much knowledge of game development, so when it came time to choose an engine there were suggestions of things such as Unity or Unreal. We didn’t look into anything else outside of those two. Unity and Unreal both have forms of payment, either upfront or later down the road. This wasn’t something we were super worried about because let’s are honest there’s probably a 99% chance the game will never make a dollar, we wanted to do it for the love of it. I had a friend who’s released two separate games into the market in his spare time, which is quite an achievement. I asked him what he uses and what he recommends, without a moment’s hesitation he said “Godot”, I’m like what the fuck is a Godot? Turns out its an open-source game engine and a great one at that.
I won’t be going into much detail about either Unity or Unreal, I don’t know enough about them. The main reason we went with Godot was because of the excellent pre-done projects that you could download from their interface, the very simple scripting language that it uses by default and the documentation/tutorials. The icing on the cake was its ease of use with versioning systems like Git.
Simplicity
When you load up Godot you’re greeted with a great interface that either gets you to open a project, create a new one or download a template. These templates are what drew us in, we could take these, see how they work then change things. This meant its extremely easy to try some feature or learn a new thing in the engine. Having hundreds and hundreds of templates projects to use is amazing and I imagine other engines have the same thing but this was something that drew us in when we started to use it. GDScript at first sounds horrible, a proprietary scripting language, that sounds terrible. It’s not, it’s integrated into the engine from day one, its very python like so it’s very easy to get into and it has great documentation. If you’re inclined you can still go with C# or C++, but they have fewer niceties than that of GDScript.
Git
We love Git, we also love GitLab. Git and GitLab are just about the best thing in the universe in my opinion and as a result, this was a big thing when it came to deciding the engine we should use. It works with Git just like it would for an API you’re working on. This could be the same in other engines but we had some issues. Using Godot meant that we could just use our existing tools such as GitKracken or the command line. Essentially our workflow was the same as it would be at work, do the work, commit it, push it. Picking something that would change the least amount of things we already understand was a big reason we chose Godot. We didn’t have to use another versioning system or something supplied by the engine, which is another way to be tied to a specific engine. We wanted to have the least ties to the engine as possible in case down the road we decided that it wasn’t working out. Having Git the industry-standard behind it, with no ties to the engine makes it ever so slightly easier to move away in the future. This is all possible because Godot creates everything as text, this makes merge conflicts much less painful.
Documentation and Tutorials
When you’re learning something new it helps when there is somewhere that can teach you. Godot has excellent documentation and even has its tutorials as well as the project templates they supply from the community. This makes it extremely easy to get started when with just a quick search you can either find an official tutorial or find a YouTube video on the subject. Other engines have great tutorials and documentation but Godot spoke to us, it did also help that it was open-source with a fantastic reputation.
Node and Scene System
Being someone whos very new to the game development scene I have no idea what I’m doing, so when Godot came with a simple idea on how it all works from a high level we said yes. Godot uses a node and scene structure, everything is a node and a group of nodes is a scene.
This is extremely easy to wrap your head around as when you place a character that is a node and when you place it inside a map it becomes a scene. You can make a scene that is a character, thus this scene has a character node, maybe some properties, a kinematic body. Then you place that scene in another scene, very similar to how Object-Oriented programming works. You have objects which contain methods and data. If like the majority of people you will be very familiar with how OO works and thus you will understand how Godot works. For us simplicity is king and this is about as simple as you can get.
Open-source
We all work in enterprises of various levels by day, places where nothing ever leaves the door. Everything is locked down within an inch of its life, you have to use what they tell you to use. Although we won’t be open-sourcing our code we appreciate having tools that do. When we have the skills and find issues we intend to give back to the project. Having something open-source allows you to make changes and fix things, or put in bug reports knowing that there’s probably going to be a good chance it will get fixed. We aren’t opposed to using closed source system, hence why our code will be closed but being able to see the code of our tools as well as fix them if we can is something that speaks to us.
In summary
We chose Godot primarily on the recommendation from someone we knew, someone who had released two games into the market. He couldn’t speak higher of Godot, especially in comparison to other engines. We looked briefly at other options and some of us had a little experience with other engines but Godot struck a chord with us. It was simple, easy to use, had great documentation, fit in with our workflow, open-source and most of all it seemed like it was an engine we could learn to love, rather than hate.
