What is an immediate red flag for you guys?

[AGoldenExperience]

Yep that one, true monsterfucker certificate

In the same romance he cums so hard on you, you literally nearly choke and drown.

Amazing, top quality seal, shockingly too, the game is really well written, outside of the smut.

 

[vellan]

Martial arts as a main theme lol

Immediate turnoff for me. They're like bad shonen anime in my opinion and I can't take them seriously.

If that's your jam then more power to you but I don't like it.

 

[AGoldenExperience]

Martial arts as a main theme lol

Immediate turnoff for me. They're like bad shonen anime in my opinion and I can't take them seriously.

If that's your jam then more power to you but I don't like it.

Fair enough, most of them are pretty hit or miss.

 

[Kim-Tong]

I don't wanna be that person but Twine is actually really easy.. Maybe it's just because I've taken the relevant coding classes but yeah. And there's many tutorials that authors have made available to help new writers. Not to mention the documentation is pretty easy to follow. There's also quite a few guides made for each twine format. I always assume people switching to Choicescript are either frustrated with learning twine (which doesn't take long by the way) or wanting to make more money because of Choicescript games being more popular. And this isn't coming from someone who knows nothing because I also use Twine. For me though Twine is the obvious winner because I find Choicescript games monstrously ugly and bad for those with sensitive eyes. The settings, for example. Either blindingly white, blindingly white with a tinge of ****, or jet black with white text. I read e-books and pdfs just fine with white backgrounds so I have no idea why Choicescript games bother me so much.

I don’t want to be that person, but saying Twine is easy is a generalization that can be quite misleading depending on the context. It’s easy if the goal is a short, one-hour project using Harlowe, Chapbook, or SugarCube at a basic level, without JavaScript and relying exclusively on the most common macros from the documentation. But building a real WIP in Twine is a completely different story, and I think that distinction is exactly why most demos end up abandoned.

To do something even moderately serious, you usually have to move away from Twine’s vanilla editor and switch to Tweego, which already means learning how to compile and manage external files. On top of that, you need to maintain a coherent and sustainable folder structure: passages, story.js, style.css, widgets, images, and everything that comes with that—without even getting into StoryInterface if the author decides to move beyond SugarCube’s native limitations. Twine is not ChoiceScript: it’s not enough to just write text. You need semantic HTML, clear and reusable structures, a conscious use of classes, containers like div and span, and data attributes. And that’s assuming the author already understands that HTML is just the foundation.

CSS demands quite a bit more if you want the game to feel like something with its own identity rather than another generic Flash-style project. Some people use templates and modify them, which has its advantages but also its risks: if the author doesn’t understand what they’re changing, they’ll break things and won’t know how to fix them. To do it properly, you need to handle advanced selectors (>, +, ~, .class .subclass), the full box model, Flexbox and Grid as essential tools for modern layouts, and CSS variables to maintain visual consistency across the project. The more polished demos go even further: responsive design for mobile and desktop, dark and light themes using prefers-color-scheme or dedicated classes, animations with transition and @keyframes, refined typography with Google Fonts and font-feature-settings, handling states like hover, active, and disabled, and pseudo-elements like ::before and ::after for decoration. All of that can coexist with great art and still be technically demanding.

And we haven’t even reached JavaScript yet, which is where the supposed simplicity of Twine completely disappears. The basics—objects, arrays, and functions—are manageable. But a real WIP requires much more: complex objects and arrays, functions with closures and IIFEs, using setup as a main namespace, DOM manipulation with jQuery (.html(), .on('click'), .off()), state management with State.variables and State.temporary, postdisplay and predisplay hooks, algorithms, timing and asynchronicity, execution contexts inside widgets, protection against undefined variables, and optimization. And above all, you have to deal with SugarCube’s restricted mode and eval behavior, which can block or break mechanics in ways that are not always easy to diagnose or resolve.

I say this as someone who has spent a lot of time using Twine, and I fully understand that a project’s complexity is defined by its author. Not every project is going to be something like The Shadow of the Eagles, which is essentially a programming monster built in SugarCube. But maintaining a WIP in Twine requires very specific cognitive skills that not all writers are willing—or need—to develop. Not every writer wants to spend two hours debugging why a mechanic isn’t working. And that’s fine, but then we should be honest about it: Twine isn’t simply easy. It’s accessible on the surface and deeply demanding once you try to build something with real consistency and ambition.