I think all of us nerds have dreamed about developing our own video game at one point or another. It’s an incredible ambition, too, combining all sorts of artistic talent into a single medium.
A painting has a single artist with a set of tools and can be posted online as-is, but a book needs far more people to be considered “completed”. In a traditional publishing route, there’s the author, an editor, a publisher, and their employees, a cover artist, and so on and so forth.
Creating a Triple-A video game can require just as many if not more people involved. Directors, marketers, programmers, concept artists, 3d-modellers, mo-cap actors, sound designers, play testers, and animators are all necessary to make the hardware pushing titles you know and love.
But you don’t need hardware melting technology to make a good game.
Some of the best games on the market are innovative indie titles that take chances on interesting new ideas or thought provoking stories. “Her Story” and “Return of the Obra Dinn” are two of the best detective games on the market, despite being far outside the box of what we would normally consider a “detective” game. Their success and the success of thousands of smaller but creative games truly push video games forward as an art form.
And if you want a slice of that pie, here are some tips and tricks to making your dreams come true.
Game engines are a powerful collection of tools that help developers start making games as fast as possible. While back in the nineties, each studio had to develop it’s own tools from scratch just to do the basics of moving box on the screen, nowadays free engines such as Unreal, Unity, or Godot do the majority of that legwork for you so that you can get right into developing games smoothly and easily.
If you’re interested in that more cutting edge, graphical side of game development, then Unreal or Unity are definitely the way to go. They each have their advantages and disadvantages, but ultimately are incredibly versatile and powerful in their own ways.
However, if you don’t need all that graphical power, or if you’re more interested in 2d design, then I recommend that you use Godot instead.
The Godot Game Engine (pronounced Guh-Doe) is an open-source game engine explicitly built with an eye for a more community focused development. While all the game engines I’ve listed are free, both Unity and Unreal require royalty payments (admittedly, the bar for who has to pay is really high, though. Unity only expects you to start paying once your game starts earning over one hundred thousand dollars, while Unreal requires your game to gross over a million).
By contrast, Godot operates under the MIT license and will NEVER require you to pay a dime. Heck, you can even break apart the engine, rework it into a new program, and sell it as your own product! Don’t believe me? Dungeon Draft, Pixelorama, and Material Maker are three in-development programs that will end up doing just that!
The other main advantage of Godot is it’s intuitive, in-built scripting language, called GDScript, and it’s powerful 2d development tools.
I’ve heard (anecdotally, mind) that Godot’s 2d tools and performance even beat out (or are close to beating out) Unity and Unreal’s 2d tools. GDScript is easy to learn, the syntax is intuitive and flexible, and the performance is on par with C#.
Godot also runs better on lower-end systems. My potato laptop, for instance, can run Godot fairly well but struggles to even open Unity, and I never even bothered to try DOWNLOADING Unreal.
In short, Godot is smaller but packs a powerful wallop.
While the mono version of Godot does support C#, it lacks almost any auto-completion or good documentation. GDScript is where it’s at if you want to use Godot. I have never learned Python, but I’ve heard it’s similar if you’re familiar with it. Regardless, if you’ve done any kind of programming before, GDScript will come very naturally to you.
Since GDScript it designed by the Godot team, for Godot, it has a lot of internal optimizations that native features to streamline your development process. Unlike C#, however, it is not Object-Oriented but has a lot of nicer syntax. Instead of typing out “&&” or “||”, you can simply type “and” and “or”, respectively. Things like that.
Oh, yes, this is another huge distinction: GDScript is not an object-oriented language in quite the same way that C# is. Each script IS the class. If you’re used to the component system in Unity, then you’ll need to change your mindset around working with Godot’s node system.
Objects in Godot are designed as modular nodes that you can attach as children to the parent objects in your game. If you squint your eyes enough, it’s kind of like Unity’s component system. Instead of attaching the script to objects, in Godot, you attach Nodes as children to other nodes.
For instance, let’s say I want to add a rigidbody in my game. In Unity, I would have to spawn in a random object and attach a rigidbody component to it.
In Godot, we spawn in a rigidbody node and attach whatever we want to the rigidbody. If we want our rigidbody to have a visible shape, we need to attach a Mesh node as a child to the rigidbody. If we want the rigidbody to have collisions, then we need to attach a Collision shape to our rigidbody. Each of these nodes becomes children of the original Rigidbody, and we use the hierarchy to navigate all the different bits and bobs.
All this stuff involving Nodes and GDScript might seem like Godot copied Unity’s shtick, but Godot starts to bring it all together with its own unique Signal system.
GDScript is designed intentionally in a way that becomes harder to break accidentally. Although referencing objects through the inspector (like in Unity) is out, calling signals between Nodes and scripts is in.
In Unity, if you wanted two objects to talk to one another, you would need to hard code a reference path between them. Then, if you changed or even removed one of those objects, your game would break because the code would be attempting to talk to an object that no longer existed.
Godot gets around this problem with its signal system. An object in Godot can basically just shout out into the void, and any object that’s listening can react to it. Neither object will break if the object calls out into an empty room, and neither do the listening objects break if there’s no one to listen to. It removes a level of dependence that you have to work around in other engines, which is great!
Godot’s Input System
Let me just say that Godot’s Input system is probably the simplest and most streamlined Input System among all the engines I’ve tried out. I haven’t used Unity’s new system, but from what I’ve seen of it, it just looks like a worse version of Godot’s system, which must be vindicating for the developers.
Unity’s old system was complete garbage. You had to type out which key to use per input, and all the inputs were in a list, and you couldn’t remove or add inputs from the middle of the list and blech.
Basically, Godot allows you to define actions. Each action can correspond with a key or set of keys (or even controller input) that can be referenced from a script as either pressed, just pressed, or just released. It’s not exactly ingenious, but it’s streamlined, intuitive, and easy to use. It also doesn’t send me into a frustrated rage because I didn’t realize that the shift key needed to be capitalized in the input box in order to work or that the X button on the controller is actually Input #17 and not #18, or whatever.
Tips and Tricks
One thing that Godot sorely lacks, being a smaller engine with a smaller community, is good tutorials. There’s decent documentation for most of Godot’s main features, and the tutorials that do exist are excellent- there’s just not nearly as much as there is for other engines. While Godot’s main toolset is excellently put together, there are some things that can be a bit unintuitive to new users.
Navigating the Hierarchy
While signals are a powerful and versatile tool for allowing objects in your game to talk to one another, sometimes you just need to get information from another node in the hierarchy. Googling this will lead you down a frustrating rabbit hole of get_node() methods and root reference paths. The real solution is the symbol, “$”.
$ allows you to easily reference child nodes and will begin to suggest reference paths and options almost as soon as you start typing. Navigating down the hierarchy to a child node is as easy as typing $, followed by the node’s name. Badda-bing, badda-boom, you’ve got a direct connection to your Tween node, or whatever.
So, this is more a general coding trick than anything specific to Godot, but it’s a feature I LOVE. Boolean Integers might seem like a contradiction in terms, but allow me to explain. If we break down all code into its fundamental state, we end up with machine-code and binary. Ones and zeros.
Booleans are variables that store two states: True or false. One or Zero. You can convert booleans to their integer counterpart with a simple cast of int(bool). Now, this might not seem all that useful, but I’ll remind you that operation expressions are ultimately converted to booleans too!
(1 == 1) is read by the computer as “true” while (1 == 0) will be read as “false”. You can use this will more complex expressions, such as, (Player.is_pressing_forward_Key), which will be read as true if the player is holding down the forward key on his keyboard.
Now, if we have a video game with a little character, and we want to be able to make that character walk around, we can do something like this:
Character.movespeed = SPEED * int(Player.is_pressing_forward_Key)
In this line of pseudo-code, we’re telling the character to move forward by whatever we set his SPEED to be (let’s say 3 pixels per second). We’re then multiplying his speed by the integer of the expression int(Player.is_pressing_forward_Key). Remember, this returns one if the player is holding down the forward key and returns zero when he isn’t!
In other words, we’ve created a simple system where the player can tell the character to move and stop without ever using a single IF statement! Ain’t that something?