The Unity fiasco and the future of Spire of Slime

Calm down! The project isn’t being cancelled! We have more good news than bad news.

The Unity game engine

You probably already saw the news, but if you haven’t, here’s a quick description: Unity, the company behind the game engine we use on Spire, announced several days ago that they would be changing the terms of their license, they also claimed that those changes would retroactively apply to all users, including those using older versions of the engine (I was using the 2021 version), it would also include developers who don’t even use the engine anymore but are still selling a game made on it. The worse part of the license changes take effect if the developer’s game satisfies two conditions: 

1 - The game has to be making more than US$200k/year in gross revenue

2 - The game has to be installed (yes, installed, not purchased!) more than 200k times a year.

If the above conditions are satisfied, then the developer has to pay Unity US$00.20 (20 cents) for each install made above the 200k threshold. This means that a player can make the developer lose money by simply installing/uninstalling the game. Unity did not mention how they were going to keep track of the number of installations, a few days later they mentioned it would be based on a “self report” system, where developers would provide Unity with this data. There are so many things wrong with those new terms, but I’m not going to spend more talking talking about them as many journalists/youtubers/developers already have covered the subject.

Also, after major backlash, Unity gave up on this change and announced new terms, which are much more reasonable. The issue is that this endeavor has proven the “dev friendly” Unity of several years ago no longer exists, developers can’t continue using it knowing that Unity could try this same move at any point.

How Spire of Slime fits into this

At this moment, Spire doesn’t make anywhere near 200k/year, but that is to be expected since the game is on it’s early stages and we aren’t selling it. However, finished games that have similar features to Spire are making a lot more than 200k/year, if we continue to use Unity we’ll always be at risk of having to deal with new absurd terms.

Considering that we are still early in development, I believe the best option for the future of the project is to switch to a different engine, more specifically a Free Open Source one, that is guaranteed to never give us any “legal” problems.

The moment Unity made that announcement I started scouting for other game engines, testing them, trying to figure out which one would suit Spire best, and I found a promising candidate. I’ll be talking about it at the end of this post.

Funding

Initially, my goal was to make Spire mostly through crowdfunding, however, that is not possible without spending significant time on marketing. And I absolutely despise marketing, I want to make games, not sell games. By focusing all my time on Spire, I wasn’t earning enough to sustain myself, and eventually my savings ran out. With that happening, I had to spend a significant amount of time freelancing in order to pay my bills. Fortunately, now I have some good clients, I’m able to earn enough to sustain myself and to fund Spire out of my own pocket. This means now I can afford more assets for the game (art, sfxs, music, etc), without the need to make revenue share deals. This also means we don’t have to rush production or spend any time on marketing, I’ll use all my free time to focus solely on getting the game done.

In the end, I believe this will be for the best, having enough money to sustain myself and the project makes me feel a lot more comfortable, I don’t have to worry about being burned out or have to lose my sanity by engaging on marketing.

This is not a permanent decision, SubscribeStar is still relevant for us, the more money we earn there the less freelancing I have to do and thus I have more time to work on the game.

All of this also means the next update is going to take a while, I’m porting the game to another engine and on top of that I have less time to work on it than before. This is just the programming side though, Akanimyr (our main artist) is still creating art at the same pace, and now I’ll be able to pay him so he’ll be able to make even more. We also now have a professional sound engineer making the game’s sfxs and music.

The new Engine: Not Godot, Not Unreal (Warning: Programmer Rant)

First, I’ll start small, I’ve seen many developers claim that Unreal is the best choice now that Unity isn’t viable. What they fail to realize is that Unreal, who’s owned by a publicly traded company, also has the power to attempt a similar move, their goal is profit, not games, this is the company behind Fortnite, a micro-transaction clown fiesta, and I have some pretty strong and negative opinions on micro-transactions.

Godot is the closest alternative to Unity, their designs are very similar, it’s also completely free and open source, which makes it a great option for developers migrating from Unity.

However, despite liking the ease of use that Godot provides, it’s not appealing enough for me. I’m not happy with any of the languages it officially supports:

• C++’s complications aren’t justifiable on a game that is not bottle-necked by performance.
• C#’s version that Godot uses is even older than Unity’s (and I actually enjoy a lot of the new features), and C# itself isn’t attractive for me.
• GDScript is out of question, I have some very strong opinions on dynamically typed languages and I don’t want to turn this post into a holy war against Python.

Godot, through it’s bindings, also makes it possible to support a lot of other languages, and there are some community projects that have created support for a few. The problem is interop, my years with Unity have taught me that it just complicates things. As someone who specializes in programming, using a language that is isolated from the rest of the engine just makes things more complicated and bug-prone. Since Godot is open source, it allows me to also edit the engine’s code – but doing so is very inconvenient and can lead to a lot of problems if you’re not familiar with it’s source code.

I’ve made my mind that I want an engine that runs entirely on a single language, while also being FOSS. That alone narrows it down to a few options, and I’ll likely be stepping on uncharted territory, but I’m not afraid of it, I’m constantly learning and I’m sure this will help me get even better at programming. Spire’s most complicated code is the combat system, there are a lot of things going on there, the perks make it even more complex, since most have unique interactions.

I made the mistake of binding too much of it to the rendering systems, I also tried to stick too much OOP where it wasn’t necessary, with this in mind, my first goal is to ensure the code is independent from any engine, while making it more solid and reliable.

Since I’m part of the Rust cult, the choice wasn’t hard. I started porting the combat’s code a few days ago and it has been going very smoothly, it’s honestly scary how smooth it is. At this rate I’ll likely have it done much sooner than I initially thought.

As for game engine, I’m learning towards Fyrox, it has all the requirements that Spire needs, the only downside is that it’s not a battle tested engine, so I might run into unknown issues at some point. In any case, I don’t have to make the choice yet, the combat’s code is going to be engine agnostic anyway, so I’ll focus on getting it done first.

That will be it for now, thanks for coming to my TED talk.