Project Yojimbo Devlog: Picking the right engine for the new game

At Beehive Games, transparency and collaboration are at the core of our values, which is why we embrace the creation of devlogs. The aim is for these articles to serve as windows into our game development process, offering a firsthand glimpse of how we bring our games to life. The goal is to offer you an inside look into our thought process and the methodologies we employ in game development.

This article is written by Lindsay Cox, Founder of Beehive Games

After launching Space Haters to a modest reception on both Switch and PC, and as we continue to develop our new narrative-driven, walking-simulator-esque game with additional content (which is remarkably easy from a tech standpoint), I’ve been researching the technology options for our upcoming, title.

In order to maintain a vague element of surprise, as hinted in my previous article on Final Fantasy IX, a long-held desire of mine has been to create a JRPG (is that term still allowed?) ever since my early days of tinkering with RPG Maker 2003. It was a pivotal experience that shaped my journey into the realm of game development.

Introducing Project Yojimbo — a game that holds a special place in my heart and one that was partially created in the pub after my weekly bout of Fencing.

The name “Yojimbo” serves a dual purpose: not only does it pay homage to one of my favorite Aeons from the beloved Final Fantasy X, but it also represents the battle system that will power it (because I like naming tech).

While it’s true that all the previous Beehive titles have been powered by the Unity engine, and I am 90% sure that this one will follow suit, I felt it was essential to share my thought process with you.

Admittedly, relying solely on the same engine is not the healthiest approach and it is the reason I go through this process. Although it is in a good place now, the rug could get pulled from under our feet one day (see Renderware).

Despite me using Unity “before it was cool” and the abundance of tech knowledge and custom tooling I have associated with it, it is worth going though the alternatives. After all, it’s important to exercise due diligence and consider all possibilities before committing to the most suitable engine for any project.

First and foremost, let’s start by examining the core goals of the project.

1. As a JRPG game, it will require a robust set of tools to facilitate content creation effectively. Game code wise it is actually not that difficult, but content and tooling wise, it is potentially a substantial undertaking.
2. Considering this project will be pursued alongside my full-time job that acutally pays my bills, this new project will be a labor of love. I will be primarily developing it during my precious moments of free time — weekends, evenings, and days off… and even then life happens.
3. It is crucial that I avoid falling into the trap of “enginitus,” where excessive time is spent building the engine rather than the game itself.
4. The ultimate objective is to release this game on multiple platforms, including PC, Switch, and potentially even mobile
5. An essential requirement for everyone involved in the project is the ability to use the tooling seamlessly on any platform, enabling quick testing and iteration on different aspects of the game. Whether it’s a PC, Mac, or even a Chromebook, the ideal scenario is to have the tooling accessible through a web browser. This suggests that the tooling itself is likely to be integrated into the game code in some shape or form.
6. Efficiency and a reasonable development timeline are crucial considerations for this project. The goal is to avoid the project dragging on indefinitely and instead aim to complete it within a realistic timeframe of 2–3 years (ish, you know what game development is like and especially doing it on the side)
7. It is done on a shoestring budget as much as possible as it is my own money that is primarily funding it and life isn’t cheap

Custom Engine and Tooling

Looking at the design of the game and its core mechanics (which I won’t spoil, but don’t worry, it’s not on the scale of something like Final Fantasy XII in terms of content), there is a possibility of building a pure C++ engine from scratch. By taking this approach, I can avoid the potential bloat that comes with engines like Unreal, Unity, or Godot. While those engines offer convenience and come bundled with essential features such as physics, rendering, and input systems, they tend to be more generic, aiming to cater to a wide range of game genres. By building a custom engine, I can tailor it specifically to the game’s requirements.

Those benefits are also cons. I would have to go and create a lot of boiler plate systems myself, and the iteration time with a custom engine at the start of the project is potentially a lot higher than using a pre made engine. The same pros and cons apply with the tooling, but on top of the above, to get it web based I would potentially have to go and learn a whole new technology stack.

Another aspect to consider is the potential dilemma of finding the “perfect” architecture for the engine. When doing architecture design (which you really should for any large feature, system tool, or DARE I SAY IT asset store tool you are going to sell to consumers), I often find myself spending a chunk of time contemplating and fine-tuning to ensure it is solving the problem at hand, is optimal and can be easily maintained. However, even with careful planning, there are always lessons to be learned and moments where I realize that I could have implemented things differently or more effectively. This constant pursuit of improvement can lead to a certain level of self-doubt and second-guessing and when building a custom engine, I find that this could be magnified ten fold. Although it comes up when building systems in Unity and Unreal, in my opinion it is certainly more prevalent when building your own tech.

If we read back at everything I have talked about then and look at the objectives, going down the custom egnine route is not logical and not going to hit the project goals.

Godot

Emerging as the apparent darling of some indie developers and the seeminlgy go-to choice for participants in the Ludum Dare game jam challenge, Godot is the newcomer that potentially wants to challenge both of the “U” engine dominance.

Although the recent version 4.1 shows promise and the tooling has seen significant improvements, it still has a way to go before being truly ready for commercial use (there are exceptions from other teams but I don’t see why they didn’t stick to Unity as the same product would come out at the end of the day).

While it appears relatively user-friendly and accessible, my experience in developing professional games that are intended for commercial release and played by gamers suggests that it may not meet the demands and expectations required for my project. In fact, integrating this engine into my workflow could potentially pose challenges and complicate my development process rather than simplifying it.

While exploring the options for programming the engine, a couple of notable issues surfaced. Firstly, it’s unclear from the outset which platforms are supported by each programming option. This lack of clarity creates confusion regarding the compatibility of the engine with specific platforms. Seeking clarification, I reached out to the Discord community for insights, and the response received was as follows:

“GDScript is supported on all platforms.

C# still has problems on some platforms. I’m not sure about Switch support (though for Switch you’ll need to look into porting anyway, godot does not ship with export templates for it. There are some companies that do porting for you though, see also: https://docs.godotengine.org/en/stable/tutorials/platform/consoles.html)

C++ (or any native language you add via GDExtensions) will support any plaform that you yourself compile it for.”

Having an existing tech stack built in C#, there was a possibility of porting it to C++. However, upon thorough examination of the documentation and tutorials, it became apparent that utilizing C++ with Godot could present certain challenges, particularly when it comes to cross-platform development. While the idea of leveraging the benefits of C++ was intriguing, the potential roadblocks and complications that could arise in integrating it with Godot were quite clear.

When it comes to console development, the options are not as straightforward. One possibility is to enlist the services of a porting company, but this would likely exceed my goal of sticking to a shoestring budget. On the other hand, handling the porting process myself is an option, but it may require a significant amount of time and effort, especially considering that it already works relatively smoothly on other engines.

Taking the above into account, it became clear very quickly that Godot was not correct for this project.

Unreal Engine

Although Unreal Engine is undeniably a powerful tool, it tends to be more suitable for larger teams with significant budgets.

While smaller projects have been successfully developed using the engine, if my focus is on extensive programming and delving into the intricacies of optimizing for lower-end hardware, it may require more developers than are currently available to me.

Additionally, within the development circles I am part of, Unreal Engine has garnered a bit of a reputation for struggling with performance on the Switch. Some have even stated that it’s “not really built for that platform,” despite the success of games like Octopath, SMT V, and Triangle Strategy. These considerations make me question whether Unreal Engine is the ideal choice for my current project especially targeting end hardware like mobile and the Switch.

Developing tooling within the engine, especially web-based tooling that essentially functions as a variant of the game with embedded tools, could be quite challenging. Although engines like Godot and Unity offer the capability to build for WebGL, I haven’t come across any official information in 2023 that explicitly confirms Unreal’s compatibility or an official plugin or solution that allows a web build to be possible. I know a very old web build existed, but the lack of clear documentation raises concerns about the feasibility of creating web-based tools with a UE5 project.

Conclusion: Unity

Let’s cut straight to the chase. There’s no denying that Unity has faced some criticism recently due to choices made by the company behind it. However, despite the noise, the core foundation of the engine remains strong. Unity still excels in its ability to quickly get things up and running and offering compatibility across various platforms. Despite the company’s best effort to self-sabotage, Unity is still a very good engine if you use it properly and are experienced with game development software patterns and where to utilise them.

Additionally, in my opinion it remains the easiest engine to extend, providing ample opportunities for customization.

On a separate note, it’s important for outspoken developers on Twitter to move past Unity’s missteps in the business realm and focus on what truly matters: making games. To be outraged on a social media platform is easy, to make quality games and then be successful is extremely difficult.

Overall this due diligence was worth it, even if it reinforced what I already suspected. Unity is kind of a no-brainer when you compared it with the project’s objectives.

Thank you for taking time reading through this post. Making an informed decision when choosing the tech on any software project is an important process and I hope this article has shed light on the considerations and thought process involved. Remember, while no engine is perfect, what truly matters is bringing our creative visions to life and delivering memorable experiences to players.