Cthangover - visual novels with RPG elements

My project (https://cthangover.github.io) is a mod-oriented platform for visual novels with RPG elements, and a game built on top of it (you can think of it as a full-fledged game, or as a demo to test-drive the engine).

Yes, it’s a classic visual novel: text, pictures, and one and a half programmers.
Yes, the basic feature set barely scratches the surface of what Ren’Py can do… for now.
Yes, I couldn’t wrap my head around Lua, so I wrote an engine within an engine, just because I can.
Yes, it’s 2026, AI is writing 3D games, and here I am trying to show off a visual novel.

However, there’s an architectural twist that, I believe, opens up interesting possibilities for virtually unlimited expansion of a finished visual novel…

The game’s inner workings are based on a code core and a few basic scenes. My Godot project has practically no assets — literally. The core assembles the final game from mods located in the root folder, in mods/, which contains various parts — scenes, scripts, resources, third-party code in source form, compiled form, etc. All of this is processed and activated at runtime, after which the assembled game runs within Godot’s scenes. By removing or adding mods, you can remove or add scenes/scripts, mechanics, and individual game elements.

It sounds like something strange, but you have to give it a try, let it sink in, and then a path opens up for people (be it developers, modders, designers, or just enthusiasts who want to put together a prototype or a fix for something in half an hour) — a path into endless modding, or even developing your own project on top of such a core, which would be unique in its own way and not even resemble the original project. You don’t even need Godot or an SDK on your PC to work on mods.

  • Is that all?
  • Not quite.

Actually, this project is also Open Source ( GitHub - cthangover/cthangover: cthangover engine · GitHub ), MIT License. I believe the project’s idea isn’t hollow — someone might want to get involved, help it grow, or even just take it and experiment with it.

What do I offer in terms of basic game features?

An automatic shader-based time-of-day calculation system. One background — instead of hundreds of variations for day or night phases.
A 2D lighting system that “brings to life” the atmosphere and immerses the player in the displayed backdrop.
An interactive scenario-building system with a fairly simple syntax, which can be expanded both within the engine and via mods.
Basic RPG building blocks — systems for: characters, quests, inventory, skills. (everything can be changed and extended)
A battle system implemented as card-based combat. This isn’t a modern action game, nor even an average turn-based clone of well-known titles, but a fairly simple foundation that will need a lot of polishing and improvement — but at least it’s something…
A mod system. The game is built from transparent building blocks; each one can be examined, some can be “pulled out” to see how the game simplifies and mechanics disappear.


I’m a complete beginner in Godot, but for some reason it literally inspired me. For more than 6 years I seriously “waged war” with Unity, trying to make dynamic resources, fluid architecture, something that changes at runtime, and every time I ran into huge walls that I had to overcome with pain and effort — my experience and background (over 12 years) in a field completely unrelated to gamedev didn’t help much. At some point, while applying yet another crutch against Unity, I poured my soul out to a DeepSeek chat, and it reasonably pointed out — much of what I wanted fits beautifully into Godot’s architecture and capabilities; one of my projects was literally 80% portable to Godot without significant changes, bypassing all of Unity’s crutches! Within 3 weeks on Godot, I fully ported the project, with some rethinking, and achieved what I couldn’t manage in over 6 years of studying Unity. I even had regrets about spending so much time on that lumbering giant, when I could have figured out a simpler, clearer, and most importantly — working — Godot.


  • Why am I even writing this, and what do I expect here?
  • Criticism. I need constructive criticism.

Unfortunately, my eyes have gone blurry — I’m missing future problems in the current architectural core of the project. Initially, the project was written solely for my own game, but it seemed to me that the potential is greater. So, what I tailored for a specific game might turn out to be too narrow a solution — I need advice, the experience of other visual novel authors, or even feedback from someone trying to use what I’m offering! I’m not asking the community to actively develop my project — it would be enough to have interested people who occasionally check in on progress, or even suggest how they see it from the outside.

After spending some time on analysis, I came to the conclusion that there are very few similar projects, and as it happens, on Godot there are exactly zero. It’s in my interest to capture this peak and dig in thoroughly.

  • What’s ready at the moment?
  • The core capabilities of the future engine, and a small sketch from my game.

As I mentioned, I had an idea that I tried to implement for several years in Unity. I spent a huge amount of time thinking through what I needed, how I could present it, how to implement it in Unity, how the story would look and unfold, etc. I started it and abandoned it many times, came back, but realized I was fighting the engine again. Only recently (4 weeks ago) I started writing all my ideas in Godot.

Right now I’m describing cthangover (Cthulhu + hangover).

This is the story of how the great Al-Azif, also known as the “Necronomicon,” met its one and only invincible enemy — a chronic alcoholic. The protagonist, a lost soul from a parallel reality, accidentally read a couple of lines in an unfamiliar language, after which the sky cracked, and through the gaps poured tentacles, claws, and indescribable forms from worlds beyond sleep. Humanity plunged into chaos, but the culprit of the apocalypse is picking his nose indifferently, mistaking the roar of cosmic horrors for hallucinations. The deadly curse of the Necronomicon, which shatters the minds of the mightiest mages, shatters against the “impenetrable” stupidity and chemical dependency of a drunkard. The Book itself, trapped in this absurd bond, finds itself at a dead end for the first time in its existence: it is immortal, but doomed to share eternity with a being who couldn’t care less about it. The hero isn’t thrilled either: he was just looking for his stolen stuff and a drink to cure his hangover, but instead got an eternal companion that can neither be silenced, nor sold, nor destroyed. Who even needs to save this world? Well, if it helps get rid of that annoying book…

Dark humor, dirty words, absurd situations, and an unconventional plot. All of this, digested and refined over a long time, dictated to me the core of the future system — the very thing capable of conveying this chaos, capable of changing every part of the game on the fly.


The project is still in development, but some mechanics can already be seen. I understand that the project is raw and empty in places, but I no longer have the mental strength to roll out a polished, colorful sample in the form of a good demo. I think I’ll take a little break; however, I’d be happy if someone could take a look at it and give feedback, or even constructive criticism. I think in about a week I’ll be able to continue in earnest and finish polishing the interactive objects (these aren’t just dialogue choices, but colliders that you can interact with using the cursor/finger on the scene when the dialogue is closed).

3 Likes

This is pretty close to what I’m working on right now. But there are some significant differences.

How exactly will this be put together? How will mod compatibility be checked?

It turns out to be something like procedural generation for visual novels. The issue, as with any procedural generation, is that it can be implemented reasonably well using very simple components. Making them more complex leads to practical unworkability.

It’s a good idea, but it requires a lot of effort to test — and, of course, a large professional team.

If it weren’t for C#, we could discuss this in more depth.

Well, six years ago, Godot was a little different.

1 Like

Currently, the conflict situation is resolved in two ways (depending on what exactly the mod overrides).

If it is a battle mechanic — any number of them are allowed simultaneously, and during the game, the modder or developer may even specify which particular system to choose, or rely on the default behavior, which will select a random system at game start.

If it is another resource, such as an image, sound, or shader — a merge occurs, and the first one provided is selected and locked in (maps of the form “resource ID” → “resource or definition” are built in memory). During the resolution process, a “dependent” module may be taken into account in the mod’s manifest; this establishes the priority order for traversing mods (we try to resolve in such an order that the most dependent ones come last).

Perhaps you misunderstood me. There is no generation. It’s just that when I write a script:

scene: town_entry
priority: 10
condition: MeetingMurakamiQuest.notHasTag("wolf_battle")
---
select "[A dull growl came from the darkness]" key=meeting_murakami/growl
option "Return to the house" key=meeting_murakami/opt_home -> :home
option "Check the alley" key=meeting_murakami/opt_alley -> :alley

:home
switch_scene home_outside
end

:alley
action quest.set_status quest_id=MeetingMurakamiQuest status=Progress
background "town/meetingmurakami/00055-1920617752"
text "[A hungry wolf that had wandered into the city in search of prey bared its fangs, blocking the way]" key=meeting_murakami/wolf_appear
text "- Oh..." key=meeting_murakami/marao_scared first=marao/what
text "[There was no doubt left: a fight was inevitable]" key=meeting_murakami/battle_inevitable

action battle.init scene=town_entry enemies=wolf_1,wolf_2 quest_id=MeetingMurakamiQuest new_tag=wolf_battle

switch_scene Battle
end

I use many resource IDs, but where exactly a given resource will actually come from — that is up to the end modder, who may override it in their own mod. By “resource” here I mean practically everything: text, character IDs, enemies, scenes, backgrounds, etc.


In the coming days, I am planning to add images, GIFs, and videos to more clearly illustrate what I am talking about, because the truth is that I am currently presenting the project incorrectly. I realize that it is huge, and by using only text, I am only making it harder to understand. In reality, I just need to show it by example (the demo is already split into several mods that complement and override each other, which will allow me to demonstrate with concrete examples how things can be done).

1 Like

Could you at least outline your concept in general terms? If it’s not too much trouble, could you also provide a description of the problems you see, along with the proposals or implementation that have solved them or will solve them?

I think I’ve already posted this link in every other thread on this forum. But I’ll put it here too.

My project isn’t an exact copy of yours, but some of the problems and solutions are somewhat similar. I’m working on a life simulator. Visual novels are just one part of it.

So, my project is no less epic than yours. And, yes, it’s extremely difficult to describe it briefly. :grinning_cat_with_smiling_eyes:

BTW, I finished the 2D visual novels a long time ago — they were among my very first projects when I was just starting to learn Godot. They weren’t meant for distribution, so I didn’t bother translating them into obscure languages.

33984612m

Night Glows_a04.exe (75 MB)

Now I’m working with 3D.

The problem lies in filling the world with content. That requires intelligence. Whether artificial or natural isn’t all that important, but the result may differ.

To put it very briefly — I’m inspired by the approach implemented in NWN, with its system of “modules”. Users created their own versions of the game, and that kept people entertained for more than 20 years after the game’s release.

We’re starting with the simplest games and plan to gradually evolve by creating more complex ones. We’ll solve problems as we go, testing possible approaches in practice.

A documentation section with various examples has been added: cthangover

1 Like

GDScript is coming…

1 Like