I have been a Unity user from 2012 and, in a way, Unity was the first software that made me feel like I could make a game. I am extremely grateful for all I learned by using Unity but, to put it in the most diplomatic way, recently I felt like the engine and the company behind it is going in a direction that I don’t want to follow.

On top of that, I feel a designer must be as tool agnostic as possible. I worked on different engines, and my professional career has been on proprietary engines for the most part, but still I didn’t feel happy with one “default engine” for personal projects.

And so I made a game with Godot in my spare time within two weeks.

When I talk to students or beginners who wonder how to start making games I always suggest to remake a classic game concept but introducing a little twist. You know, like “Snake but physics based” or “Pac-Man but turn based“. I feel it’s a good way to start from an established design base, which gives you something solid to build upon and makes it easier to learn the tools, but also will let you learn something about design rather than just execution.

Finally, and I cannot stress this enough: you learn way more completing small projects than starting and abandoning big ones. Finishing is a skill in itself, the last 10% takes 90% of the time etc. etc. Prototyping is fun, but if that’s the only thing you do you will never learn how to make all those systems needed in a complete game – from saving and load to proper UI, scene management, audio etc. If you want to learn a game engine, make a complete game with it, even if tiny.

Anyway, let’s cut to the chase: Calcio Mattone can be described as “breakout but you control a kid playing with a football”. That’s it. It’s a small idea that I got talking to my son, who apparently plays some breakout clone at school (yeah, I know). Also he likes football, so I put one and one together. To be fair, it’s not even the first game about breaking bricks that I made. So maybe this is my first spiritual sequel?

I never used Godot before, so here’s what I did: I downloaded Godot 4.1, followed the two, excellent, tutorials on making a 2D and a 3D game and then I just jumped into this project.

I managed to make the whole thing within two weeks, working occasionally one hour here and there outside of working hours.

You can play it here:

So how is Godot for a Unity designer?

In one sentence: it was a revelation.

In more sentences:

Scripting

I am not a coder but I can code in C#, started with Unity Javascript, used several different proprietary scripting languages and visual scripting systems, copied and pasted Rust code, played with LUA… In other words, I am not completely new to picking up new languages. But GDScript was by far the smoothest transition I have ever experienced. It’s fast, perfectly tailored to the engine it’s used on and it removes one million little inconveniences that are inherent in any general purpose language used to make games.

I still don’t love the fact that whitespace has semantic meaning, but I sort of understand how that essentially solves the problem of formatting and, in theory, improves readability. Still don’t love that but I will survive.

General structure of the engine and workflow

Probably the most vague concept but also the typical thing that will make us love or hate an engine.

Every engine has an “ideal use” or “ideal shape of a project”. You can pretty much do anything with any decently advanced engine but some things will be easier depending on whether you are following the “intended” workflow.

Every engine is opinionated in a way or the other: I tried to make Tetris with Blueprints and Unreal once and I felt like I was fighting the engine. And that, for what is worth, is one of the reasons why I didn’t choose Unreal as the engine for personal projects: I think Unreal is great for commercial, large projects, but I also feel that anything outside a 3rd or 1st person game in Unreal requires workarounds of some sort. As a designer I want an engine that is as genre agnostic as possible.

You can find more in-depth analysis of the node structure of Godot and its philosophy in general. But, as a Unity user who initially felt quite confused by the concept of “everything is a scene”, I have to say that it took me very little time to get into how projects are structured on Godot, and now I think it is a much more modular and solid approach than the looser one of Unity. To be fair, I think that a well structured project in Unity will not look much different than the default workflow logic of Godot. Moreover, in some way, new prefabs in Unity are, for all intents and purposes, scenes – at least in the way a user will experience modifying them. But the fact that Godot forces you to think of the project as a tree with nodes that are added and removed when needed makes it just a bit easier to do things properly.

I still have some doubts about the scalability of it all, and I wonder how well Godot’s workflow functions on a large project with many collaborators. But that, probably, is not the kind of problem that can really be engineered away. It is, in a sense, a human problem.

Final note: I dislike the fact that tabbing from one script to the other is sort of annoying and I wish the built-in editor made it possible to have multiple scripts visible at the same time – though it sounds like a nightmare UX-wise – but if that’s the price to pay for having everything on the same application I’ll take it.

The annoyance multiplier

If you ever used tools that you disliked you will be familiar with the feeling of “I hate doing this specific task”. It’s usually fairly small UX annoyances, like having to click too many menus, or categories that are not well structured etc. But these small things tend to reinforce each other: find enough of these annoyances and your general impression of the tool you’re using will be negative. So, how did I feel using Godot?

I felt good. I rarely had trouble finding what I wanted and most things worked the way I expected them to work. The fact that the whole engine is so quick, responsive and compact makes it a joy to use. As a user, I always prefer tools that prioritize the user experience and the ease of doing something rather than the ones that try to be all-encompassing and “professional grade” but end up being pedantic and confusing.

Working on this project on Godot I put my hands on a lot of systems, from UI to sound, to animation, save and load, physics and more. I didn’t find any dealbreaker in terms of understanding how these work.

How did the game turn out?

Look, it’s a game made in two weeks by one guy in his spare time using this game engine for the first time 🙂

Jokes aside, I am pretty happy how it turned out. It’s a tiny game with no commercial ambition but I think it has a nugget of fun. You can play it on itch.io: the desktop version is much better but I also made a webgl version (with fake shadows, as real ones are not available for webgl in the current version of Godot, and some brutal hiccup the first time a particle effect triggers). It plays much better with a controller but it’s also playable with mouse and keyboard.

But I realize how incredible it is to be able to create something – for two platforms, no less – on a tool I’ve never used before and have it made and playable in such a short time.

I was already a supporter of Godot for many different reasons, but now it feels like I found my new favorite engine.

What’s next

Unless I get some spurt of inspiration, I think the game is done. If you are an artist and want to make it look better let me know. Otherwise, I think it is the best and most pain-free “let’s make something quick to learn this tool” thing I’ve ever made. So I’ll take this little win.