Making a game involves a truckload of decisions: What's the concept? Who's the audience? Which platforms will it be on? Very quickly game devs can get lost in a maze of big and small decisions, one minute having to tackle art style, only the next to come face-to-face with the multi-faceted beast that is game design. 

With Unicopia nearing completion, there's undoubtably a slew more decisions I'll be making over the coming months. Some will be big, and some inconsequential, and then right at the end I'll be asking myself if I'll ever brave making another game? However, there was one decision that was so fundamental that without it Unicopia would be just another entry in the encyclopedia of incomplete games.

Before discussing that decision I need to wind back, back to mid-2019, when I first decided to make a game. 

Having just started working alongside the games industry, I wondered what it'd take to make a simple little game. Starting with Lua and Love2D, I began making a basic tower platformer, along the lines of the 80's classic, Nebulus. Love2D was fun. It had a good community–albeit, one driven by innuendo–was easy to get started with, and very quickly I had something up and running.

Nonetheless, after a couple of months, I was coming unstuck. My problem was the tooling, especially around Love2D's scripting language, Lua.  Although Love2D is a C++ framework, it uses Lua for scripting, and what I found was the more complex the gameplay became, the more complex the scripts became, and the harder it was to trap and isolate runtime errors. Without compile time error checking, and without a fully-feature IDE to help iron out minor bugs, the dev cycle was growing more painful the bigger the codebase grew. After a few months of tinkering with my game, I put it down.

Six-months later, I realised I'd been bitten by the game dev bug and wanted to try developing the game again, but decided to stick with what I knew best, which meant using C#. Eschewing good advice from industry insiders to use a game engine, the engineer in me wanted to get my hands dirty, so I settled on using  MonoGame. Although it's got a solid pedigree in indie gaming, MonoGame is a framework rather than an engine, meaning it has lots of features to help develop games, but doesn't provide a prescriptive approach, nor a full set of tooling.

Leaning heavily on community assets– such as the highly functional Nez library–I managed to build on my Love2D experiment, and  within a couple of weeks had a working prototype of a game. Working evenings to day-job I'd added some pickups, added a couple of basic enemies, and had a nicely rotating tower design. However, there were two key problems I had to deal with. Firstly, there were some really rough edges in various systems, such as moving platforms, and my decision to avoid using an engine was starting to rack up the bugs. Secondly, and more significantly, I'd become victim to scope creep. 

What had started out as 2.5D game was rapidly becoming a 3D game. The initial design of using a 2D tower with a layered rendering trick to simulate 3D rotation, had given way to a full 3D tower, with 2D sprite billboards rotating to continually face the camera. By failing to keep my enthusiasm in check, every new line of code was rapidly taking the game further away from ever being completed. 

Realising I didn’t have the headspace, the time, or the resources to finish a 3D game, I decided it was time to stop again.  Although my choice of using a framework rather than engine had its part to play, I'd essentially been scuppered by my unbound enthusiasm and useless scope management.

About a year later in early 2023, I started learning Unity, and thought it’d be good experiment to port my C# code into Unity. I did a PoC and had the ore code working within a month. I was highly tempted to continue and take the game further, but I was worried. Even prior to Unity's licensing gate in late 2023, their general monetisation approach and acquisition by IronSource in 2022  worried me. Clearly Unity's  a powerful engine, is a great choice for C# developers, and would have been more than capable of doing what I needed. But my nervousness about Unity's corporate was enough to curb my enthusiasm.

So I decided to try Godot. Although I was very tempted to port the C# code again, I really wanted to learn how to maximise the use of Godot's node system, and starting with an existing codebase was going to work against that. Starting from scratch using GDScript was all it took to convince me to continue with the game. Godot's Node system was easy to use, and while I missed various C# features, GDScript was fun and quick to use. Most importantly, Godot's 2D functionality, it's IDE, and it's quick development time gave me renewed confidence I could get a game finished. Reducing the scope back from 3D, back from 2.5D, and settling on 2D, I got started on Unicopia…

And 9 months later, as I get close to finishing to Unicopia, it's clear to me that choosing Godot was the single most important decision I made for developing the game. Getting things working in the Godot IDE has been fun, and that fun has been instrumental to keeping me going. While there's many paths up the game dev mountain, it's a long climb, so you need to choose a path that will keep you inspired to reach the top. Starting a game is easy, but reaching the finish, not so much.

Clearly my earlier experiments had taught be a lot, and clearly Unity, MonoGame, and Love2D could have technically handled the 2D gameplay, but what really catalysed my progress was Godot's simplicity.  Learning Godot was a breeze. Unlike Unity, it's not littered with partially complete and competing designs and systems. Unlike MonoGame, it provides a full on engine that makes it simple to create moving platforms, to add particles, and to dip into shaders.. And unlike Love2D, the engine and IDE gave me enough support to keep the complexity in check as the project size grows. Although GDScript still suffers some of the problems of interpreted languages, the IDE is powerful enough to makes it easy to forget it isn’t compiled.

So as I get close to making Unicopia feature complete, Godot deserves my thanks for giving me the confidence I needed to get here. Godot stopped me worrying about licensing, it stopped me worrying about technical challenges, and, most importantly, it took away the uncertainty I had about actually finishing a game for once.