My favorite part of any game, dev project, or experience has always been the beginning. A time when the possibilities are endless and an existing structure is not holding you back or slowing you down. The number of new game saves I have in Satisfactory versus completed games (zero) is embarrassing, but I thoroughly enjoy getting to a new stage of development only to learn how everything I did in the prior stages is holding the next advancement back. Now I get to go back and more effectively implement the initial stages to ensure successful setup for the future.
Granted, I do also enjoy finding creative ways to rip out/update only what’s necessary of an existing build to achieve the necessary goals, but given that such tasks are often the most common in your career, with large pre-existing codebases and all, it’s most fun in my free time to have the experience of actually getting to start from scratch, nice and clean.
With this personality quirk in mind, I was developing Bad Dog as a C++ SDL project, while also animating, designing, and planning the entire project. This was always an ambitious first project, but the deeper I got into it the more I realized I was bogging myself down with yet another large C++ project that is slow to refactor. I was actually in the process of redoing a good amount of the project to align it more with an Entity-Component System where levels, actors, items, etc could be specified as collections of components, which would be created and tuned via a library of JSON files.
This was actually quite enjoyable and was being done with the intent of speeding up my overall implementation of the game mechanics themselves, while also allowing me to try out a new design pattern that is becoming more common in games. The early stages of this can be seen here though don’t judge me on the lack of content, much of this work remains uncommitted while I was hammering out the update.
Anyways, while doing this work I was reflecting on why I was working on this project in the first place. A large part of it was to have fun, but the other necessary part was building up career skills in my free time. As a more vanilla software engineer working towards a career in original game development, I began to question the need of struggling through the barebones setup I was working through. My resume easily highlights a good level of experience in C++, but was lacking game design and experience in a more common engine such as Unreal, Unity, or Godot.
Additionally I sometimes wanted to simply prototype some of the game mechanics I was considering for Bad Dog without having to spend a week creating the necessary systems to see those mechanics come to fruition.
Given my prior points made on Unreal for 2D, I considered Unity and Godot. At the time of this consideration, Unity was deservedly getting dragged for its new fee structure. So I began to look at Godot, a free, open-source solution that has been growing in popularity of late.
On top of the obvious perks of open-source, I liked the surrounding community, ability to easily work on 2D or 3D games, option to work in GDScript (a Python like language), C#, and/or C++ within the same project, and had personally enjoyed some games from the engine, such as Dome Keeper. I decided to roll with Godot at least as a tool for prototyping mechanics in my game. The long and short of that is after working with it for a month, I simply decided to move the entire game’s development to Godot. If there were ever a need to optimize the game and develop it ad hoc, I would easily be able to fork the engine itself or rip all of my mechanics and implement systems from scratch where the desired mechanics were already known.
Needless to say I was able to advance on the game design part of my project rapidly in comparison to the old model of implementing everything from scratch in C++. This was a boon when considering that the amount of free time I have to commit to game projects always competes with a career, time with my wife and dog, the gym, family, friends, yadda yadda.
Within a few months and some further animation I was able to easily create a backyard test level, create AI that wandered, ran away, and chased, implement a health/energy/movement system (with dog zoomies) that powered the player, and start to hammer out game mechanics quickly. This was aided by easy to understand scene structures, a fantastic support community, and GDScript’s ease of use, especially with my prior experience in Python which feels incredibly similar.
Granted there has been a learning curve as a C++ user with respect to Godot’s, “every script is itself a class,” way of thinking, but this was helpful as a new way of thinking, and will help when I inevitably work more with C# (Or you know, decide to start this game from scratch again using Unity).
Anyhow, I do feel like I write a lot of posts justifying picking engines or methodologies. I just hope to give insight to the madness and maybe express how I like to operate. I don’t want to get too deeply into the nitty-gritty of the work I’ve done so far at this point in Godot, I just wanted to appreciate the engine publicly and throw a thumbs up behind any movement to further fund it and make it more of a norm. Similar ease of use is obviously the case for many engines, but Godot is the one I ran with.
As previously stated, Unity has its own troubles being proprietary, and Unreal is sure to have similar issues in its future if you’re not already counting the fees attached to releasing a game with the engine as it stands. Godot may never have the support a private company can offer for its own tool, or be given access to the kinds of funds that allow Unreal and Unity to innovate deeply, but it does offer a fantastic jumping off point for an indie dev or any game studio with the resources to take the open source engine and build on it themselves.
I hope that the work I am doing here eventually becomes more marketable as Godot grows in popularity, but I do fully intend to eventually work more with Unreal and Unity, as being one-dimensional is never fun or good for anyone.