Godot First-impressions as Game Development Students

Hi!

My name is Henrique Alves, and I’m a Computer Engineering student at Universidade Estadual de Campinas (UNICAMP, Brazil). I am also part of Gamux, a student research group focused in Game Development (http://www.gamux.com.br/); we are also responsible for organizing workshops, Game Jams, and other game-related projects in our university with professors and students from areas ranging from Computer Science to Visual Arts and Medialogy/Media Studies. So yeah, that’s us!

We’ve recently reunited some of the Gamux students to explore Godot, a very interesting open-source game engine that launched its first stable version (v1.0) in January (2015). Being a new Engine, it holds a small but growing community; our intention with this project is then to create incentives to “boost” the growing rate of such community, at the same time allowing people to practice and study new ways of developing games with the tools Godot provides. In this document I hope to present the general first impression we got from Godot in one of the Game Jams we organized earlier this year - Matheus Jun Ota and myself making the game “Ambrigram”, Thiago Amendola in the game “Illuminatis Everywhere”, and Professor Santanchè in some engine experiments.

DISCLAIMER: This will not turn out to be some kind of “Engine Propaganda”; as newbie developers, we did our best to analyze Godot within a neutral perspective, and as this first-impression should show, even though we liked Godot, it wasn’t without some real problems we had to cope with.

But… why Godot?
 

At first, our intention was to start a project with some of the senior students of Gamux - something in which we could put our experience to use. After some group brainstorms, Godot was suggested as a project tool. Philosophically speaking, its MIT license is perfect for us to use* (it’s great to see FOSS incentives in the game development industry, and Godot source-code can also be studied and modified without any fuss), and as we could see from the community, some of the Godot’s biggest problem was its lack of documentation and need for more public game examples - design templates for game mechanics that everyone could understand and use. Even as beginner developers, these are problems we can try to attend to, while contributing to a Game Engine we are betting can make a big difference in the near future. Other engine features made us more certain of our choice, but they’re soon to be discussed in the next part of the article.

* there is a great Gamasutra article about Open-Source game engines I highly recommend, that matches some of the Gamux development perspective:
http://gamasutra.com/blogs/LarsDoucet/20150217/236674/Game_Maker_Security_and_Freedom.php

And what about the experience?

We had our first contact with Godot as supervisors of Gamux’s Meeting Jam 2015, a Game Jam organized every March for Unicamp freshmen interested in game development (a friendly way of preparing them for the Global Game Jam 2016). At the same time we helped the freshman teams, we organized ourselves to explore Godot during the 24 hours of . In the end, we had two *somewhat* finished games (“Ambrigram” and “Illuminatis Everywhere”), and some game tests made by Professor Santanchè.

The Engine’s features can be found in the official website (http://www.godotengine.org/wp/features/), but the most interesting one we found was its modullar approach in designing game-scenes: scenes can be reutilized, or incorporated in other bigger scenes seamlessly. At first, it seemed a bit counter-intuitive, as we are a lot more used to a class-based relationship between game objects, but after some (a lot) of tests we began to understand how we could build our games with Godot’s “node” system.

Even then, and that was our first big problem with Godot, it took us a great amount of time to understand how to simulate what we know about Obejct-Oriented Programming in Godot’s context (as would be done in Unity or Unreal). It’s far from an intuitive design when you try to do a direct conversion, and that’s an approach we believe many people will be eager to try when handling Godot after some Unity experience. There are a LOT of nodes to use, and most of it can only be understood with first-hand experience - a first-hand experience which will usually end up with a landslide of bugs to fix.

Sure, there are (at the point of writing) some beginner tutorials in Godot’s GIT Wiki (https://github.com/okamstudio/godot/wiki), but we did not find any of them particularly helpful to understand how to easily design an OO-like behavior between scenes/nodes. It sure looked like it was our mistake in bringing that mindset to Godot, but OO project organization works so well in other engines, we did find it lacking in terms of providing guidelines to create projects in Godot with a similarly intuitive organization using the Scene system.

Design problem aside, after this first presentation, we started exploring Godot’s built-in scripting language GDScript. GDScript follows some Python syntax (although it’s NOT Python), and since we were already familiar with Python, after reading some tips in Godot Wiki we were ready to go. We couldn’t explore how powerful GDScript can become with someone with real prowess, but we could not help seeing it’s potential; it’s very easy to learn, very fast script writing and it looks like it can finish the job as a stand-alone language (you can rewrite your code with C++ in Godot to make it “more efficient”, but GDScript does looks like a faster, cheaper and easier way to code). An already quoted issue was Godot’s lack of documentation, and GDScript also suffers from that. Even so, we almost could work fine with it.

Almost.

Our second biggest problem with Godot wasn’t it’s lack of documentation (and that WAS a problem), but GDScript debugging. A lot of crashes and bugs were coming from unknown GDScript problems, and the built-in debugging tools of the engine didn’t help us a lot. It sure looked cool, though - there are some efficiency profiles for you to test your game’s FPS and memory usage in real time, and a lot of other informations about the game objects and nodes in the “Performance” tab. But the “Debugger” tab felt somewhat useless when we had to fix the problems by hard-testing our scripts, or when the game crashed and no information about the crash could be seen anywhere. The game window would simply disappear, and you would be back staring at Godot.

It felt like a robust debugging system at first, but after these experiences, we had to spent a lot of time just playing around with GDScript to see if the bug or crash would be solved. Then again, the bugs were caused by mistakes we made coding in GDScript, but mistakes made in C# on Unity are usually discovered much, much faster than what we experienced on Godot.

So there we are. After this rough beginning, we could actually code in GDScript and make some tests.

There were some other Godot-quirks during the jam, like the fact that the Audio importing for me and my game-dev partner didn’t work as expected - for an unknown reason, the audio we imported was playing in the game slightly faster than the original audio (but fortunately for us, we liked it that way, so we turned it into a feature by making the audio play even faster on later levels!). There was also some instability during the stand-alone execution (the stand-alone crashed - even if we had tested it before and it was working just fine, so we had to play the game using the engine project). But they were unfortunate events; the two biggest problems, though, were the new design method for the nodes/scenes system, and the GDScript difficult debugging.

It’s still noteworthy that we are newbie developers, and as such, most of this analysis comes from the fact that we are still learning how to develop games, and we are just experiencing a new tool. But since Godot is not just a new tool for us, but plain NEW to the whole community, and is just starting to grow as a real, public workable engine, these rookie mistakes are worth being described, so we can start making new tutorials or think about improvements on Godot’s interface, making it more accessible for indies and students like us. That is the group’s intention on adopting Godot as the engine for our student projects. In-between the difficulties we had with it, the final experience let us see a great learning potential, and we are more sure than ever in betting on it and in its growing community.

You can play both games (made in the beta-version of Godot 1.1) by downloading the git projects below:

(PS: A big thank-you to the other Gamux members for sending me the “Godot jam-report”, and my eternal gratitude for Gustavo Crivelli for proof-reading this post!)