Since playing the video games Final Fantasy 6 and Earthbound on the Super Nintendo, I have wanted to make my own 2-D RPG game. For many years as a hobby I have tried to do Game Development on and off, bouncing from tutorial to tutorial and from game engine to game engine. I seem to just scratch the surface of a game engine then find myself hitting a roadblock preventing me from progressing. Going into detail with the experiences I have had with Unity, Defold and Godot.
Unity
When you look up game engines, probably the best “free” one you will hear about is the Unity Game Engine.
Free resources
Unity is a blur of free tutorials for me. My experiences of going through the tutorials were not great. I didn’t see a lot of value in the tutorials Unity offered. A lot of the tutorials, although great for their own thing, still made me have difficulty visualizing or recalling how to do things or implement it in my own project. It wasn’t until recently they started adding more 2-D features and more 2-D tutorials in line with what I wanted. I eventually learned enough to start my own prototype. Obviously it was going to be a full fledged top down adventure in the style of Earthbound. I grabbed a bunch of free assets from Open Game Art and some sprites from Spriters Resource and got to work.
3-D Engine
I started with creating a character for my Unity prototype. I decided on doing 8-directional animated movement for the character. This involved looking at more tutorials and a few road blocks deciding how to implement it. I made the 8-directional movement using a 3-D animation mechanism for Unity. This is when I learned that Unity is mainly meant for 3-D development while 2-D is done to a lesser degree. Even with 2-D game development I felt like I was working with more then what I needed.
Layer struggles
I then had trouble with something that I have had trouble in every game engine, layers. I just want my character to go behind and in front of things depending on the y-axis. I spent what felt like ages looking through countless forum posts asking about y-axis layering to find the right combination of settings to accomplish this. This was another problem I had with Unity was the countless settings and menus I had to go through to accomplish what I wanted. I personally found it very confusing and hard to remember where the settings were for configuring something.
Unit Testing
At one point I got into game development tutorials involving Unit Tests and Dependency Injection in Unity. I thought these were both things I would want to implement in my own game. I downloaded a package to get the unit test to work. A good programming practice to be able to implement unit tests is to use dependency injection in your code. I only had a few scripts at the time in my game but the re-factoring and adding the unit tests was difficult and required a lot of figuring out. My code re-factoring was either breaking my game in some way or it wasn’t working for the unit tests. I eventually got it working, but honestly it wasn’t needed for my video game prototype. I learned when it comes to prototyping doing things the quick and dirty way can be okay and fixed later on. As much as I want a good foundation for my game with testing and dependency injection practices, focusing on the core game for the prototype itself can be more important.
Defold
I found Defold to be a lot more simple than both Unity and Godot.
Less menus, more code
Defold has less menus and settings to go through to do what you want to do. Because of this there is more coding. This felt good though as it allowed more control.
Sprites, Tilesets, Animations
One of my biggest things holding me back from game development has been 2-D assets for my game. The free things I had found previously weren’t cohesive enough, even for a prototype, for me. I eventually stumbled across and paid for Omega Modern RPG assets pack from a Humble Bundle. This was very comprehensive for me in terms of making my own top down 2-D RPG. Although when I tried to put these assets into Defold I had trouble with the animations when setting them up. I never figured out the correct settings to get it to work. I didn’t want to have to hard-code the animation or modify the tilesets images in a way that could be used by Defold’s tiled animation.
Collisions
Defold was good at making the setting of collisions a bit easier because you could just set it via an image. This was great until I wanted to do more advanced stuff. I ran into trouble when I wanted to have a separate collision on the same tile. Like a separate collision that would handle interacting. I tried to get it to work with layers and masks but was never really able to figure it out. I could think of a way to do this easily in Godot. This is when I thought I should switch back to Godot with the new assets because I felt like Defold as a game engine was a little lacking for what I wanted to do.
Godot
Godot I found to be easier to learn then Unity and have more functionality then Defold.
Tutorials
I feel like everybody who is learning about Godot right now knows about Heartbeast’s 2-D action RPG tutorials. These tutorials were very useful for the type of game I wanted to make and they are perfect for a beginner like me. I felt like I learned more useful information from these tutorials then any of the Unity tutorials I had gone though in the past. I expanded upon the completed tutorial by adding a randomly moving NPC with dialog.
Scenes and Nodes
One of the first things you learn with Godot is about its structure of Scenes and Nodes. All nodes can have a tree like structure with different properties depending on the node type. Those nodes can be saved and re-used as a scene. I enjoy this system a lot and to a certain degree all game engines have a similar concept to this but in Godot it feels like it promotes more re-usability. Unity has something kind of similar but I was never able to grasp it. The important thing in development of anything is always to think of ways you can re-use a piece of code or a game object. The way it is done with scenes and nodes in Godot always seems to work for me.
Signals
Godot has some built in decoupling when it comes to communication between nodes. This is through their Signals. If you are familiar with the observer pattern in coding this is kind of the same idea. With the usage of signaling I am not sure if I want to do it through the Godot built in registering for listening to signals or through the programmatic way of registering to the signals. Either way, the usage of the observer pattern as signals is nice and works pretty well. Being able to navigate to see what references or listens to a signal through the Godot IDE is useful.
Conclusion
I spent a lot of time trying to learn Unity but I was not able to do the complex things I wanted to with that engine. I tried Godot after that and was able to learn it pretty well but then I found the workflow to still be more complex then I wanted. Then I tried Defold and found that simplifying the workflow meant a bit of a loss for the more complex things I wanted to do. So I went back to Godot and I think this is the engine I want to stick to for my top-down 2-D RPG game for the time being.
Author: Beam
Last modified on 2021-05-16