Why we choose Godot Engine
Now is the best moment to create a game. The first reason is that you are alive, after death you just can't make games anymore. The second reason is that the access to developing tools has never been so democratic.
The Good Old Days
I still remember back in 2004 on my first semester at Computer Science Graduation course. A grown-up boy, excited to learn how to develop and start creating the crappy games that loomed in my head. I don't want to sound old or nostalgic (despite being both), but back then there was no Twitter, Facebook and whatever else younglings use nowadays to 'share information'.
The best we had here in Brazil was some underground internet forums that half a dozen of anonymous hobbyists exchanged little game experiments and knowledge. I didn't even know what I had to google to start learning game development. Although GameMaker is 17 years old and RPG Maker is 24 years (!), I had never heard of them or knew someone that used them.
The first class I had in college was Basic Programming and we were taught the C language. The moment I learned the basic syntax, the excited / foolish young me decided to make a Zelda: Link to the Past kinda clone / inspired game. Yeah, every novice game developer wannabe is stupid.
The final exam of this class was to create a Pac-Man clone using Allegro, but NO! Pac-man is too dumb / small for the greedy game developer inside me, I want to make a Zelda kinda of game! Later I discovered that Pac-Man itself was an herculean task for someone who had just learned how to make a for loop (but this can be a topic for another article).
Ignorance was bliss in my case, nothing could stop me from downloading some Zelda SNES ripped sprites and make Link able to move and collide with a rough TileMap that I’ve created from scratch (this already made me feel like a programming god). Needless to say, my Pac-Man never saw daylight, developing a 'Zelda' was much more fun.
Game Engines…Game Engines Everywhere
Back to present days, there are zillions of books, articles, devlogs, social networks spreading knowledge and engines. Everything for free or kinda free. Listing my top of mind quickly in a categorized way:
- Unity / Unreal / CryEngine / Lumberyard
- Scirra’s Construct / Stencyl / GameMaker / RPG Maker
- Love2D / HaxeFlixel / Cocos2D / Phaser
- I could go on for years…I'm not even joking…
With that we have the Paradox of Choice. There are soo many of them, which one to choose?
The Underdog: Godot Engine
Matheus and I have lots of experience with many engines and programming languages that we've been trying through all those years, but we must comment about the Unity Engine, which I dare to say is the most popular nowadays between small studios and indies. We used it to develop Dungeonland during the existence of our beloved Critical Studio back in 2013 and it was really good back then, comparing with the rest of the options.
We still think it's a great engine, especially in the 3D field. But after Critical Studio ended I've wanted to play with a simpler tool. Unity was already bloated, was slow to load and building 2D games was very hacky.
I discovered HaxeFlixel (more like a framework instead of a engine) and it was great for small games, prototyping on it is very efficient and I had truly native performant code on each platform with a single code-base, and was fast to distribute a quick game for my friends using the Flash export.
But I felt that something was still missing, maybe a hybrid between the two? I wanted something simple as HaxeFlixel but wanted to have more control, some kind of WYSIWYG editor or IDE like Unity was.
And then, a new underdog appeared in town, the Godot Engine. It's development started back in 2007 as a proprietary engine and got open-sourced in the 2014. That's 10 years in the making showing how mature it is.
When we discovered it we felt that it had the potential to be everything I was searching and Rock Milk needed. We build Reakt as a laboratory to define a production workflow for our studio and put Godot to the test. We ended up loving it SO MUCH because every weak spot that we’ve found in other engines were better addressed on it.
Disclaimer
I have no intention of generating some kind of Flame War with other programming languages, frameworks or engines, so:
- We’re not saying that Godot is better / more powerful than other engines; (even so because this is a matter of perspective and necessity)
- We're not saying that other engines are bad;
- We’re not saying that there isn’t a solution for the flaws raised;
- We’re not saying that Godot's solutions are flawless;
The main point here is to clarify why we like it and why it's better for our business and programming style. I apologize in advance if maybe I offend you somehow, really. (but don't get offended, it's not worth it)
With that out of the way…
Open-Source and Community
Godot is free as in freedom and open-source forever. In practical terms:
- There's no indie taxes or anual / quarter calendar revenue cap;
- You're not forced to use their splash-screen, use their additional services or host your project files in their cloud;
In 2015 it joined the Software Freedom Conservancy, showing how serious Godot is about it.
It's dev community is really really active, and beyond their commits to the repo, there are always news articles and progress reports. It's Discord is always full of people willing to help or showing wip's of their games.
Cross-Platform Editor and Deploy
There is an editor version for every OS flavor: Windows, Mac and Linux. There’s even an experimental version for Raspberry Pi by cam12win fresh out of the oven!
Everything else is as expected:
- Deploying on desktop: Windows, Mac, Linux
- Deploying on mobile: Android, iOS, Windows Phone (experimental) and Blackberry OS (no joke)
- Deploying on Web via Emscripten (WebGL 2.0 and WebAssembly in the works)
There are several plans for console builds, but Shin-Nil got the 2D Platformer Demo runing on his XBox One:
And Deponia Playstation 4 version was made using Godot as well.
Lightweight
A Godot build takes 30MB out of your HD, with (almost) all-included. If you want to bake mobile builds, you'll have to download an additional ~200mb of build templates and that's it.
I'm not bringing that up because it's fast to download or will spare 3 to 30GB that other engines would take, but to show the team's concern with performance since it's conception. Godot opens up in a blink of an eye, my notebook is 4 years old and I've never waited longer than 5 seconds for something to open or load. The maximum time I waited was about 1 minute between pushing a button and have a new debug build running on my Android phone.
And most important: it reflects how performant your game will be. It blew my mind when I discovered that the Godot's Engine is a Godot Game itself.
Version Control Friendly
Have you ever had a conflict in the repository of any scene/prefab/whatever using Unreal or Unity? So you know as I do how painfull it is, especially in bigger teams.
Every object is stored as text in a very friendly and human readable format, if you ever need to merge some conflict. It’s easy to separate your objects in multiple scenes (more on that later) so each team member can focus on their own.
Animation System
Godot has the most powerfull but yet simple animation system that I've seen with all the tools that I've played with. You can animate ANY PROPERTY of a object, even function calls. Besides that, it contains a tool to create cut-out animations.
Better than trying to explain in words how it works, I present you GDQuest and Heartbeast, two awesome guys that dedicate their time creating game creation instructional videos, most of them for free. Each one of them made a video about Godot's animation system:
Real 2D vs Fake 2D
Part of Rock Milk's philosophy is to launch often. To accomplish this, we are creating small and simple games, trying to get a hit through unexplored and innovative mechanics. As we are only two family guys with a daily spare hour to work on our games, we opted to focus on 2D games for obvious reasons.
Godot has a dedicated 2D engine and not a fake 2D, flattening the Z axis on a 3D space. What that means in practice while using Godot?:
- Pixels as Coordinates and Units, including the Physics Engine;
- More performance and API simplification as the engine does not need to deal logically / matematically with a third dimension;
- Typical workarounds used in other engines are not necessary (e.g.: setting a unit as 1 pixel, pixel-perfect rendering, z-ordering and camera zoom hacks and etc.)
In other words, we have fine control over size, position, velocity and collision with each one of the game's entities, including HUD that are usually a total PITA to setup. (But we love the new Unity's GUI, just saying)
GDScript and API
GDScript is the default programming language that was hand-made for Godot, making it intrinsically connected with the engine features.
It's so easy to make lot's of behaviors with little coding because of it's huge API. Every object I thought I would have to create from scratch, Godot had something already done for me, with every manipulation and customization I needed included.
Besides that, I believe GDScript is the main reason to keep new users away from Godot. From all complaints that I've seen around, I highlight:
Do I have to learn a new language that can only be used in Godot?
Yes, but it won’t take you two days. It’s a very simple language, like a Python’s brother.
Worst case scenario, you will have another programming language in your pocket and learning new languages will help you think differently (in a better way) with other ones.
I hate scripting language
Yeah, there's no accounting for taste and there's not much I can tell you about it. But if you want to, you can write all your code in a C++ module and expose it to GDScript in a very easy way.
Or maybe you want to keep Waiting for Godot 3.0 (there it is Godot Community…the joke you wanted) as it will have C# support and GDNative, that will allow to code using Python, Go, D, Rust and even Nim (or any programming language that you want to create bindings).
What about it's performance? Scripting language for Games? Eww
For 95% of the games that you can imagine, I believe it will be more than enough. If you're still skeptical, as I already mentioned you can create C++ modules and get C++ performance.
If there is a single part of your algorithm that needs extreme performance, you can create just that bit in C++ and the rest of the game with GDScript.
You can read more about in Shin-Nil's performance benchmark.
I can't use GDScript in my Code Editor / IDE
Godot has a code editor integrated, and besides being a scripted language it makes a beautiful job with intelisense (a.k.a. code completion) and powerful debugging, including Live Editing, as Juan Linietsky (a.k.a. Reduzio), the lead Godot dev, shows here:
For now, it's only possible to have full integration with an external code editor via Visual Studio Code using Godot Tools, made by Geequlim, but there is syntax support for Sublime Text, Atom and GEdit.
My sugestion: Try GDScript out before criticizing it. If you're not fluent and very productive in one week, I'll give you a candy.
Still not convinced? Check Juan's reasonings about GDScript creation, it may change your mind:
Node and Scene System
Node is a basic object for your game that you can edit it's properties. It can be a 2D Sprite, a 3D Model, some GUI element or just play sound. Godot comes with LOTS of them ready to be used and extended, so you can create your own node types. Scene is a group of nodes organized hierarchically, like in a tree.
This is our favorite feature hands down and the best way to explain it is through this:
Everything in Godot is a scene. Each one can contain other scenes and nodes. You can easily extract some sub-trees and create a scene of it's own, increasing scene reusability, as fracteed used cleverly on those pipes:
For your better understanding, I'm going to compare this with Unity:
- In Unity a GameObject behavior is composed by adding multiple components. Every component is a script, so a object can have multiple scripts; (duh)
- In Godot, each node can have only one script, but it comes with it's basic functionality already implemented. You define a GameObject through a scene, composed of multiple nodes and other scenes. That means that you have nested prefabs by default. See an example of a Player GameObject, from Godot's official docs:
If you want to read more about it you should read 'From Unity to Godot > The Scene System' documentation page.
Minor setbacks, but a solution is on its way
During Reakt development, we found some minor bugs and quirks using Godot version 2.1.3:
- I have a Macbook Pro Retina 13''. Depending on the Godot tool that I was using, some GUI panels were so tight and some buttons were above others GUI elements, but nothing that would make them impossible to use
- When leaving the Animation Tool it sets the edited node default state to the last used state on the tool, we had to reset the node to it's original configuration several times. As a late solution, we've created a default state animation that had to be selected before closing the tool
Besides that, our only real bottleneck was integrating third-party mobile libraries, mostly business ones like Analytics, Ads plus Mediations Networks and Crash Report. Creating native modules in Godot 2 is very cumbersome: you have to download the engine source, create and include native modules in a specific folder, compile the engine and then compile the module debug and release versions. This will generate a new mobile template that you can use in your game and hope that everything works fine, if not, you have to debug your module through console with a USB cable attached to your mobile phone. Phew…
After everything is setup and you get used to it, is pretty quick to regenerate everything. On our first game we only used Godot-Firebase, created by Frog-Square (thanks for the help Ramesh!).
We wanted to implement other mediation networks as well (Firebase only has AdMob) but the cost-benefit ratio would be not worthy right now, because as I already mentioned Reakt was just a lab project and GDNative is already working in Godot Engine 3. We'll be able to use them without needing to go though all compiling process I've previously explained, with a bug-fix bonus from all other problems we had.
So, Godot 3.0 is almost there…
…but that's not an excuse for not playing with it right now! You have to experiment with it to understand everything I've just said.
Really, check this video with all features already working on v3.0:
You can download an alpha version if you want to. Also, check the engine's roadmap, it's pure game development bliss. ❤
Besides that , Godot has a Patreon and it just reached it’s first milestone, allowing Juan to work full-time developing the engine.
I really hope that I've convinced you to join this awesome community and help to speed up Godot Engine growth. Did I managed to convince you? Then, start learning!:
- Godot Oficial Docs
- GDQuest's 30 Tutorials in 30 Days and Make Professional 2D Games with Godot Course (which raised €32,512 on Kickstarter)
- Kids Can Code and Angega Studios YouTube Channels
Rock Milk aims to be one of the reference studios when thinking about Godot Engine, just like P1X (creators of Tanks of Freedom) and Okam (where Godot was born and creators of The Interactive Adventures of Dog Mendonça & Pizzaboy®). We really hope to find you through our journey, feel free to come talk to us if you have any doubts!
Diego Machado, stronger part and jack-of-all-trades @Rock Milk
