It Is Happening Again…

When I first started working on Terror High, it was in Clickteam Fusion 2.5, an engine I had essentially spent my entire gamedev life in.

As longtime followers will know, I made a decision relatively early on in the process to switch iHorses mid e-stream to Unity. This was not without its complications, as I switched from script-free programming to learning C#, as well as acquainting myself with and working around all the quirks of the Unity Engine itself (of which there are many).

Progress was slow, but steady. I began to feel more and more confident in my skills in the engine, and the switch to Unity opened so many possibilities that were limited by the previous engine.

…and then capitalism struck.

I’m not going to bore you with too many details, as plenty of others could cover it better (it caused such an uproar that even the nerds at NPR got a hold of the story), but essentially Unity Technologies rolled out a poorly messaged, poorly thought out, and most shockingly retroactive “per-install” revenue sharing plan that had game developers confused, anxious, and furious.

The absolute mad lads eventually walked it back (after a deafening silence that lasted over a week) to a more reasonable percentage-based revenue share, but the damage was already done. Their attempt to force another retroactive Terms of Service change after their last disastrous attempt at forcing a retroactive ToS change in 2019 (after which they pinky-promised they would never, ever try something like that again UwU) shattered too many people’s trust—including mine.

But much like famed anarcho-communists Chumbawamba, when I get knocked down, I get up again. (Unlike Chumbawamba, I generally don’t mix whisky drinks and vodka drinks. Also, remember to hydrate, kids!)

Like many other indie devs, I started researching other engines. The two biggest contenders were Unreal Engine and Godot. Unreal offered a lot of “graphics machine go brrrrrrr” potential, with free use of everything from Quixel Megascans to MetaHumans, but the thought of coding with Blueprints or diving into C++ after getting so used to C# didn’t really appeal to me. Besides, those hyper-realistic assets wouldn’t really mesh with the established aesthetic of the existing assets, so they were essentially useless for Terror High.

Godot, on the other hand, was much more similar to Unity in form and function, and even had support for C#! It also had the enormous benefit of being FOSS (Free and Open-Source Software), just like my other software bestie, Blender.

FOSS is, frankly, just more in line with my ideological jimmy-jams. I love the ecosystem and philosophy of open-sourced software, and how it spits in the face of the absurd idea that profit is the only thing that drives innovation. Humans like making shit! The more freedom and tools they have to make shit, the more cool shit they’re gonna make! You really gonna turn down cool new shit because some poor schmuck couldn’t pay out the ass for a Creative Cloud license in perpetuity?

(This is also why I have absolutely zero interest in any generative “AI” garbage. I’d rather see the most technically inept art made by someone with heart and passion than a mechanically perfect image without soul. For this same reason, I like/upvote absolutely any fan art I see on any social media platform, because someone loved something enough to make something. That’s beautiful. Who gives a fuckin’ shit if their technique is off? Sucking at something is the first step towards being sorta good at something!)

…but I digress.

After an initial comparison of what I needed from Unity and what Godot had to offer, seeing what some other developers were deciding for their projects, and getting a feel for the engine itself and what it could do, I decided to try porting some things over and seeing how it went. I could always back to Unity if it didn’t work out.

I think it’s safe to say I’m not going back to Unity.

Even if it weren’t for the incredibly shitty corporate practices of Unity Technologies, using their engine had become such a slog. I found myself juggling the benefits of the various renderers and builds, knowing that upgrading for one basic feature meant breaking another, relying more and more on third-party developers for what I wanted, and knowing those third-party assets were just as prone to breaking or rendered completely unusable with any upgrade. It was a struggle.

Godot, on the other hand, just seems to…work? I know it has its own quirks* and pitfalls, and I’m sure I’ll butt heads† with it as the porting continues, but I can’t really describe what a breath of fresh air it is to be able to load a project in seconds and just plop something as simple as a decal in a scene and have it work. No realizing the feature you want is locked behind an entirely different render engine, no $50 third party asset. Just a functional, understandable game engine.

This ease of use was fortuitous in more ways than one, as shortly before the Unity debacle I was already contemplating another major change to the basic structure of Terror High…

Since the early days of the project, I struggled with the best way to display the game world. The game started life as a 2D game simply because that was the only way I thought I could make it at the time. Eventually, I made the leap to 3D, but still aimed to keep that 2D aesthetic. Had to keep my eyes on the prize, right?

But just as I was struggling with the Unity engine, I was also struggling with the limitations of the perspective. “How do I let a player know an enemy is nearby but just offscreen?” “How do I make a realistic space that’s easily navigable from this perspective?” “How do I do all of this and make it scary but fair?”

The more I thought about these concerns, the more I realized I just wasn’t happy with any of my solutions. But there was another possibility, an idea so radical, so risky, so dangerous, so goddamned crazy…

What if I just changed the camera perspective?

So I did. Just to try it. As a bit.

And I loved it.

At first it was just a test, but soon I became enamored with the change in view. The pixel art graphics went from evoking the 16-bit era to the 32-bit era, from “Clock Tower” to “Silent Hill” — and it instantly solved all those issues I had spent so much time banging my head against the wall on.

Now, the reason why the switch to Godot proved beneficial to this decision is that, even though I loved the new camera perspective, I was still struggling with the Unity Engine to get a nice, smooth movement out of it. For some reason, no matter what I tried, there was some kind of a stutter with either the player or the camera. However, in Godot, it just…worked.

Now, some of you might be saying, “Alex, isn’t this kind of a major change in game structure and engine scope creep?” And to that I say, “What? No. Shut up. Your mom is a scope creep.”

“But, no, I don’t believe this is scope creep,” he continued defensively. It has not impacted the asset creation process, as after the move to Unity, nearly all assets were already fully 3D, anyway. There are a few locations that might require some additional set dressing if the player is able to see where they previously weren’t, but generally speaking the additional work required is minimal.

Porting also provides a natural opportunity for refactoring and optimization, which the game and its maker can only benefit from as progress continues.

I’m excited by this new direction, as it brings the experience I want for players that’s in my head closer to being a reality. And that’s a neat concept!

That’s it for this update — but, hey, it’s only been 6 months since the last devlog instead of 2 and a half years like last time. And people say there’s no such thing as progress.

Until we meet again, Terrorteers — stay creepy.

* “It’s the little differences.” “Example?” “You know what they call a Serialized Field in Godot?” “They don’t call it a ‘Serialized Field’?” “Nah, man, they got the metric system, they wouldn’t know what the fuck a Serialized Field is.” “Then what do they call it?” “They call it an ‘Export’.”

† As I’m writing this, I’m trying to figure out why the exact same node setup in Unity Shader Graph produces entirely different results in Godot Shader Editor.