Hi! We are the developers of Devil’s Terminal, an occult mystery visual novel. We’ve been working on the game for almost 10 months now, but this is our first technical devlog. Recently, we added Timofey "Tim" Khakhanov—an experienced visual novel developer and technical director—to our team. In this first devlog entry, he introduces himself and shares insights into the project’s evolution, the overall technical setup, and the strategic decisions we’re making to bring the game to life. Now, passing the mic to Tim.

This is the first attempt at a technical devlog for Devil's Terminal.

Let’s skip technical specs and hardcore engineering talk—that would be too boring. Real-life indie development isn’t as technical as, say, military systems, building software for street facial recognition, or Deutsche Bahn train scheduling solutions and any other anti-human systems.

Indie game development is first and foremost about the humans, so we will start with them, not computers.

Context (almost) unrelated to computers

I'm Tim. I'm 27, I love retro shooters, cats, and being the smartest person in the room.

22 years ago, I was shown Doom. You could say I was DoOmEd to make games.

4 years ago, I released my first major visual novel as lead developer. It was a small success.

2 years ago, I released another as technical director. It bombed, and I swore off visual novels for good.

2 weeks ago, I broke that promise. Now, together with the Drama Club team, I’m making Devil’s Terminal.

In between, I developed other games, launched two startups, created my own visual programming framework, burned out, emigrated, and replayed Half-Life 2 eight times.

This random series of events shapes my decisions more than specs or industry practices. But I call it technical strategy.

Why visual novels again? The Unity Apocalypse made me throw away everything I’ve been working on and switch engines. To call myself a Godot developer, I need actual Godot releases. What’s easier than doing what I know best? And apparently, I know Devil’s Terminal.

Setup: context, tools, and strategy

This project is my kind of gig: a team with indie passion and care, but without the disorganized, student-project approach. No burnout yet—just a lot of artistic vision and ideas balancing between genius and madness. The focus is on visuals, effects, and genre-blending features,—that’s right up my alley.

We’re using Dialogic as a framework. It’s like a wannabe Renpy written in GDScript, designed for building a visual novel with minimal coding. But, as someone who’s worked with Python, I have a built-in anxiety towards GDScript. “No code” solutions often mean custom features are a pain. Still, I can live with that.

As for the editor, we’re using our own CMS in Google Sheets, that compiles dialogues into Dialogic scripts. Extravagant, sure, but smart, given the time constraints. My inner mad scientist approves.

At this point, the prototype runs in the editor and capable of basic functionality, but there’s plenty of work ahead, and that’s when I’m coming to stage.

GDScript? More like GoodBye Script

GDScript is a not a good programming language.* ** ***

** subjective opinion*

*** for full-scale commercial development*

**** compared to more mature, statically typed languages with real IDEs and years of infrastructure*

It’s good for beginners and learning; it has its merit for some projects. But working with a language that lacks static typing and professional IDEs is painful. Large amounts of code become slow and costly to debug. My experience from For the People (written in Python 2) taught me this lesson.

Thankfully, Godot supports other languages, and C# works right out of the box.

It took me a few days to rewrite the main game modules and screens in C#. It’s now a much more pleasant experience, and I’m confident we can scale without sacrificing reliability.

Bonus points: I quickly got into all the game code.

Dialogic

Porting from GDScript to C# would’ve been trivial if all the code was in-house. But we’re using Dialogic, and I didn’t port it to C#.

It’s not impossible, but the cost would be to high. It’s easier to write a framework from scratch than to rewrite someone else’s. C# and GDScript work together, so custom game logic and interfaces run on C#, while Dialogic stays on GDScript. We use a buffer layer that converts data between them.

I was pleasantly surprised by Dialogic—for flexibility in custom features. You can easily replace the provided screens with your own, and, aside from design settings, it’s pretty convenient.

Online CMS

Writing dialogues in Google Sheets is an interesting choice. It’s far less convenient than a proper script editor—after all, you’re writing code, not just lines. Scripts have system commands that are easy to mess up, and maintaining this setup could get costly.

That said, Google Sheets lets the team collaborate in real-time, without version control headaches.

Building a custom tool for scriptwriting is simple, but adding collaborative editing is complex, time-consuming, and demands serious infrastructure.

For now, we’re sticking with if it ain’t broke, don’t fix it” The team likes the CMS.

But if we need to scale, we’ll have to weigh the cost/benefit. The script is the heart of a visual novel—working with it should be fast and efficient, or it can easily slow you down.

Level up: where we go from here

We’ve moved to C#, integrated Dialogic, and kept the CMS online. Along the way, we fixed some UI bugs. Not bad for a start. This is definitely workable, and I’m excited to use my experience to make the game technically solid for both players and the team.

In the next devlog, I’ll talk about the progress we’ve made, best practices from large-scale commercial development and how to adapt them for indie projects, and also about some cool visual effects.

Join our Discord to stay updated and discuss the cool stuff about the game!