Game Dev Journal Entry 1: Deciding on a Game Engine
“Do a lot of work. Finish a lot of work. Share a lot of work.”
I am a software engineer today because of the Starcraft Campaign Editor. Back in 4th grade, my friends and I played the original Starcraft everyday before school, after school, and on weekends. We often played custom campaigns which, I learned, can be made by anyone with the Campaign Editor. I had my first game engine in front of me. I spent hours and hours on it, never really finishing any of my “games”. But it gave me my first window into programming and game development.
More recently I’ve used programming libraries such as XNA, Phaser, and LibGDX. I’ve liked how they’re code-only tools, but I’ve seen how that results in a lot of boilerplate that can add up and it’s generally more work. I think I could benefit from a fully-featured game engine and it would help me speed up the development process.
What is my goal?
Before a pick a game engine, I believe it’s beneficial to first figure out “why am I doing this?” and “what is my north star?”
Eventually, my dream game is an open-world game that I think of as a mix between Pokemon and Animal Crossing. I love the idea of world-building and exploration and I think those are my ultimate ambitions.
However, I believe that it’s best to work iteratively and to start with small steps. So first, I will make smaller-scale games to get some experience under my belt, keeping my ultimate goal in mind.
Thinking about what I am NOT trying to do:
- I am NOT trying to make money off a game or necessarily grow a community around it
- I am NOT trying to make something 3D.
Requirements
Now that I have this direction, what are my requirements in a game engine?
- Free
- Easy to use (otherwise, I’ll go back to LibGDX)
- Large community with documentation
- Deployment options including desktop, web, Android
- Github version control
- Linux compatibility
- Some programming
- Multiplayer/networking capabilities (nice-to-have)
- Deployable to Nintendo Switch (nice-to-have)
Ruled Out
Looking into game engines, I quickly ruled out a few. Unreal Engine seems primarily for 3D games, and Lumberyard is meant for larger-scale projects. GameMaker seems like it tries to minimize coding (as a software engineer, I’m more comfortable working with code). I didn’t feel it was necessary to explore much further and I narrowed it down to Unity and Godot.
Unity
Unity seems like the most popular game engine at the moment and is chock-full of documentation and features. My first inclination was to go with Unity because of its pervasiveness. But then I heard some more opinions and my impression is that that legion of capabilities comes at the cost of feature bloat. I don’t think I’ll be doing anything too complex in my games, so I think this feature bloat wouldn’t be worth the cost. I also started hearing suggestions for Godot as an alternative (thank you bei from the Game Dev Field Guide Discord), and so I looked into it.
Godot
Godot is an open-source game engine that is growing quickly in popularity. It has a large community and a ton of documentation and has a focus on 2D games at the moment (to be clear, there are robust 3D capabilities, I’ve just heard the 2D experience is better). Most of all, I keep hearing people talk about the “simplicity” and “user experience” of Godot, and that particularly caught my eye. It also appears that Godot has the minimum set of features I need: free, deployment options to web, desktop, & Android, Github version control, Linux compatibility, and even some multiplayer/networking capabilities. The one apparent downside is that it has its own native programming language (GDScript) as its de facto scripting tool. Ideally, I would be gaining familiarity using a programming language that I might use in other software engineering contexts. Godot does offer the ability to use C# (and I even saw unofficial plugins for other languages), but I think if I were to use Godot, I’d want to “use it the way it was intended to be used” and would take up GDScript.
Verdict: Godot
I think you can figure out which game engine I decided on. In truth, I didn’t spend a lot of time evaluating this decision and was quickly drawn to Godot. I was convinced by the reviews about its user experience, the large, growing community, the focus on 2D, and the open-source nature (I’m interested in contributing in the future). Using GDScript isn’t that big of a downside, and I’d still probably be learning programming lessons that I could translate to my software engineering career.
For the next couple of months, I’m going to give Godot a shot and build some small games with it. I plan to report back later after playing with it for a bit and share my experience.
Shout out to the Game Dev Field Guide and Zackavelli. I listened to his helpful episode on game engines and I’ve really enjoyed the community and podcast in general so far, so check them out if you’re interested!
’Til next time!
