It’s difficult to believe that we’re already 5 weeks into this term and 4 weeks into development of our project. Progress has been going steady, but we have run into many technical hiccups along the way. Looking back at the technology we decided to use, I’ll share my thoughts on how that’s been working out for us so far.
Our Technology Stack
We’re building our game in the Godot game engine. This was a decision that primarily stems from the open-source nature of Godot. We really wanted to make this project and have that sense of ownership over it. Larger game engines like Unity and Unreal had strings attached that meant we wouldn’t truly have the ability to do anything we wanted with our game.
For programming, I’ve personally been using C# as Godot has that as one of its major options. GDScript is a custom language developed for Godot, which is also available to us when the need arises.
Godot has a built-in code editor, but each of us has external preferences for programming. I use JetBrains Rider for my IDE, as I’m familiar with the entire JetBrains ecosystem. I’m sure some of my team members use Visual Studio instead. The only thing that matters is that it works for the individual to get our project made.
For 3D game assets, aside from what we acquire from 3rd party sources, we’re using Blender for creating 3D models. Blender is another open-source program that aligns with our beliefs, but beyond that, it’s simply a fantastic tool with plenty of support. I’ve had the pleasure of creating assets in Blender for other classes, and it allows us to turn ideas into importable game assets amazingly fast.
For 2D game assets, i.e. textures, we once again each have our own preferences. I stick to GIMP as I use Linux, but any program that lets you create art works. There’s also plenty of 3rd party assets available, so we have tons of options for obtaining the ideal textures.
Last but not least, Git and Github have been our version control tools of choice. We’ve all used them plenty of times by now throughout OSU (and outside of OSU), so it was a no-brainer to choose them.
Godot, Git, Blender, any art program, and any code editor is all we’ve really needed. Godot does the heavy lifting as our game engine, and from there it’s a matter of using other tools to give it the assets it needs. While things have been going relatively smooth, there are some things to mention about quirks we’ve run into.
Godot
I’ll admit that I’m the primary advocate for Godot amongst my team. The go-to for most people looking at game engines is Unity. Unity has always been the king of indie game development, with countless tutorials and free assets at your disposal.
What drove me away from Unity was the debacle a few years back with them demonstrating how they can become heavy-handed at any moment. I knew that I wanted to stick to open-source and maintaining true ownership over what we make. While exciting at first, we have dealt with strange hangups throughout development.
Looking back, many of them were indeed caused by our lack of experience. When we were trying to work through them, it was a lot easier to put the blame on Godot. I believe this boils down to Godot simply not feeling premium coming from the open-source community as opposed to a large company like Unity Technologies or Epic Games.
That’s not a knock at Godot as I still love FOSS, but it did mean that we would need to figure out a lot more on our own, which adds to the already steep learning curve of using an entire game engine.
The biggest problem we’ve had is that C# integration relies on a weird quirk of Godot to function properly. As the only person using C# thus far, I’ve had to help my teammates troubleshoot when the project wouldn’t compile with my scripts. They were unable to get the project to run, only receiving a vague error about C#.
We found out that Godot only builds the C# project when creating a new C# script for the first time. It turned out that my csproj file was never committed to Git, only my sln file. This left my teammates in a state where they had to create a new C# file and immediately delete it just to get the project built. It was ultimately my fault, but it goes to show that Godot wasn’t going to make it easy to figure out what needed to be done.
Git
The second problem we faced was with Git. Our workflow has been to work on separate branches and then create a PR to have them be merged. This has worked plenty well, with a requirement of another team member’s approval on the PR to ensure it’s being checked.
I ran into a particularly nasty merge issue a few days ago that nearly gave me a headache. GitHub was telling me that my branch was perfectly merge-able with main. Once my PR was approved, it then told me that there was a merge conflict.
It took me about 2 hours just to get past that merge conflict. I was so stumped on what the problem could be as it was claiming a debug statement’s removal was causing a conflict with the main branch. While I still don’t understand how it was conflicting, I was able to resolve it through a bit of messing around with the commits on my branch.
After that hassle, I greatly appreciate the CLI for Git. I can’t even begin to imagine how I would resolve that if I didn’t know a bit about the command line tools. GitHub was no help to me with a vague “Merge Conflict found” message.
I would 100% recommend you make sure you can avoid the easy tools like a GUI via GitHub, just for annoying cases like these. The last thing you want is to be completely stuck trying to google Git commands you don’t understand to resolve a problem.
Conclusion
Progress has been pretty great! We have a decent prototype of our map, a working player character, and a nice audio system. The most important thing is that we’ve been able AND willing to help each other out. There’s nothing I’ve appreciated more than feeling comfortable talking about problems I run into, and knowing that my teammates feel the same.
Our technology stack is just the tools by which our project can exist. The real test is if our team can continue to leverage these tools into creating something amazing.