bumbleknightsblog

[bumbleknightsblog]

An Engineus Journey in 2024

Hey everyone,

This post isn't your typical opinion piece or how-to guide. It's more of a journey through different engines and technologies, aimed at sharing insights and providing context for my choices. I usually add some bee-related puns on Twitter (yes, Twitter, it's not "X"), but this is more of a tech discussion, so apologies in advance for less of that!

Let's start at the top. I'm bumble_knight, the current lead developer at Beehive Games, an indie studio that's been steadily growing over the last 5+ years. We're a small team driven by passion, juggling game development alongside full-time jobs and life's other demands. I understand the challenges; committing fully to indie game development isn't easy when bills and responsibilities are buzzing around, especially in an industry that's not exactly in perfect health at the moment.

Personally, I've immersed myself in game development for a while, tackling various projects across different technologies and platforms. Now fully embracing the indie life, each game I've worked on has brought its own set of challenges and rewards.

Recently, we launched our latest project, "Getting There," available on Steam, Epic, and itch, developed using Unity. Since the beginning, Unity has been our go-to engine. I've optimized Unity projects of varying scales to ensure smooth performance. However, discussions around Unity's runtime fee initially left a sour note. While Unity has made adjustments, the fee poses challenges for larger studios with higher burn rates and the future of the engine is still a bit uncertain.

To be frank, this incident reminded us that decisions were being made by individuals possibly disconnected from their consumers, potentially jeopardizing stability. Though the situation has evolved, it was a stark reality at the outset.

I embarked on a two-week technology investigation for our upcoming turn-based RPG, "Gaol Story." Initially exploring Unreal Engine, I hesitated due to the daunting task of migrating from C++ and concerns over Unreal's tendency towards bloat.

With a background in XNA, I considered returning to my roots and turned to MonoGame. However, the lack of robust editor support compared to Unity posed challenges. Originally planning extensive game customization, we utilized Dear ImGui, with Unity as our renderer. Transitioning to MonoGame's Dear ImGui implementation proved beneficial, yet grappling with its content pipeline became a hindrance, exacerbating my "engineitus" — the desire to build a perfect system without the constraints of a pre-built engine. So I moved on.

Experimenting with Godot in the past left me unimpressed with GDScript, but a team member's positive experience with it on another prototype prompted another look, in particular the C# branch. While Godot's node-based approach appealed to some, it didn't align with my workflow preferences.

Eventually, we returned to Unity for "Gaol Story," while eyeing Unreal Engine for future projects.

Reflecting on these experiences, I realized it's easy to be swayed by social media trends. However, players generally care little about the engine used; skill and execution determine a game's quality.

That's about it. I'm not entirely sure of the exact purpose of this post anymore, but if you found it useful, that's fantastic! Through this process, I set a time limit and embraced a fail-fast mentality, proving invaluable.