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.
Choice of Mods
Join our amazing community to find Choicescript games and modifications to improve your gameplay!
What is an immediate red flag for you guys?
- Thread starter Levant
- Start date
Amazing, top quality seal, shockingly too, the game is really well written, outside of the smut.
Fair enough, most of them are pretty hit or miss.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.
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.
I mean, sure, it's not easy, but it also is?
When L was explaining this to me, he said that yeah, while most people are intimidated by stuff like JS and whatnot, but you can find all the codes online, since someone has already done them. You can just copy paste them, and tweak them if necessary.
The key is knowing what you want to add, and how you want it to look. Everything else? Easy.
CSS is easy, it's just customizations.
HTML is easy, albeit a bit of a slower process, though that highly depends on the work.
And JS is JS, for which you can either find the codes online, or you don't have to use that much.
He told me that the key is basically finding the easiest way for something to work, and then gave me an example of the save file system. He said that while he could make a brand new one, he can also just use a little bit of js code to call upon the original twine sugarcube one, and voila. It doesn't have to be overly complicated.
Sure, Twine is much vaster, and allows you to really go crazy, but you need to understand that there's no need for that, at least not in the majority of the cases.
You explained it well here, but this explanation seems much more complicated than it really is.
You mention span and divs, but that's literally just this:
<div>
<span class="whatever"></span>
</div>
That can be explained the way you did, but if you truly know the subject, which by the looks of things you do, you can't possibly say that this is something insane, when in reality it isn't. And you give all these folder structures, but they are just that, files in which you add things. It's really not that big of a rocket science. It can all be explained much simpler, or you can explain it the text book style, the way you did.
But the biggest problem is one that you kind of mentioned, about writers not wanting to bother with all this. They think they are some coding geniuses when they manage to do the simplest of things, and call it a day. That's where the problem is, because they barely do anything in Twine, despite Twine giving them an option to.
They don't know how they want their work to look visually, and that's the actual problem. Not coding itself, since coding itself, unless you're really going above and beyond, is not that hard imo
I think you’re actually proving part of my point without realizing it.
You’re right that not every project needs high complexity, and that you can get pretty far by keeping things simple or reusing existing code. For small-scale projects, that approach works fine.
But that’s exactly the distinction I was making.
It’s relatively easy to make something work on a small scale. It becomes significantly harder when you have to maintain it as the project grows. A 20-passage story with basic choices is manageable with copy-pasted code. A 100+ passage WIP with interconnected systems, persistent state, dynamic conditions, and consistent presentation is an entirely different challenge.
Copying code doesn’t eliminate complexity — it only postpones it. The moment something breaks, needs adjustment, or has to interact with other mechanics, you still need to understand how it actually works. Especially in SugarCube, where systems constantly interact with each other.
Saying “everything else is easy, just look it up” assumes a level of technical familiarity that not everyone has. Knowing what to search for, how to adapt it correctly, and how to debug it when it inevitably breaks is part of the difficulty.
And that brings us to the core difference: writing compelling narrative and designing robust systems are not the same skill. Some authors deliberately choose tools like ChoiceScript because they want to focus on story, pacing, and character rather than technical implementation. That’s not a lack of ambition — it’s a different priority.
So yes, Twine can feel “easy” at a small scale. But once you move into larger, sustained projects with real ambition, the difficulty isn’t in finding a solution. It’s in making everything continue to work together cleanly over time.
Personal opinion, but I feel Twine makes more sense for games like Wayfarer or the new version of Shepherds, which make use of RPG elements and so benefit from all the additional coding possibilities. Else it's good for authors who are good at visual design and have a strong vision of what they want the game to look like.
I mostly just care that the text is legible and that stuff works/is easy to debug. Even if I were to switch to Twine, I'd probably just end up using some boring template and close to zero of additional coding features. I did try to transfer an old WIP to Twine some years ago, and it was indeed not difficult because I didn't need/use anything but the basics lol. But then why switch?
Last edited:
I might be a bit insane, and look too much into things, but this is legit how ChatGPT answers, down to the t. But aside from that.
I'm not proving any point of yours
It's pretty easy to make anything work on any scale.You just need to literally remember what variables you use, and what things can happen. That's not something you do with code, but something you do with your personal notes. That's how ifs work.Just because a work has 10, 100, or 1000 passages doesn't matter. If code works, it will work regardless of the number of passages. It's not that deep.
And copying code doesn't postpone anything. If it works, it works. Period. It's not going to magically break just because you added more text in game. Why would it
Though I do agree that not many are familiar with looking things up, since you do have to know some basic, general coding for that, but to learn that? Takes a few days at most, for the average joe.
Though yes, many of the writers aren't good in either one of those. Writing and coding. They usually suck at both
So to conclude gpt, no, the scale of a project doesn't matter. If we were talking about keeping track of things, then sure. But if we're talking coding specifically, it doesn't matter one bit. The code will work regardless of the scale, and if something needs to be fixed, basic knowledge and a bit of a keen eye will do the trick
That IS chatgpt spiel lmao, dude didn't even cover up the constant comparisons or constant em dashes, mfs can't even think for themselves without chatgpt nowI might be a bit insane, and look too much into things, but this is legit how ChatGPT answers, down to the t. But aside from that.
I'm not proving any point of yours
Just because a work has 10, 100, or 1000 passages doesn't matter. If code works, it will work regardless of the number of passages. It's not that deep.
And copying code doesn't postpone anything. If it works, it works. Period. It's not going to magically break just because you added more text in game. Why would it
Though I do agree that not many are familiar with looking things up, since you do have to know some basic, general coding for that, but to learn that? Takes a few days at most, for the average joe.
Though yes, many of the writers aren't good in either one of those. Writing and coding. They usually suck at both
So to conclude gpt, no, the scale of a project doesn't matter. If we were talking about keeping track of things, then sure. But if we're talking coding specifically, it doesn't matter one bit. The code will work regardless of the scale, and if something needs to be fixed, basic knowledge and a bit of a keen eye will do the trick
I knew that I was going back and forth with a robot!That IS chatgpt spiel lmao, dude didn't even cover up the constant comparisons or constant em dashes, mfs can't even think for themselves without chatgpt now
I thought I was being hypercritical when reading their posts but I kept constantly wondering if they were using AI. I really don't know what I said that warranted the use of AI to respond to me though. I find Twine easy. I haven't coded anything since 2018 but was able to pick up Twine relatively quickly using free resources and the Sugarcube documentation. I also thought it was strange that they overcomplicated pretty simple concepts in Twine and made them sound so foreign. I promise, it's not as difficult as the AI described. As Serpent said earlier, it seems to be drawing directly from academic textbooks when describing concepts. It's all easier in practice after you read tutorials, the documentation, and make a test game with everything you've learned. I didn't mean to come off as dismissive of people who might struggle with Twine. I just wanted to let people know it's not as hard as it seems. Obviously the more stuff you want to implement, the harder it'll be. A standard interactive fiction will be easier to make than a game with a combat system, a game with health and sanity mechanics, a game with lots of layered images and animations, or a sandbox game, or a combination of ALL of those. I just felt it was a bit weird to be like: " yeah it's easy unless you're making something super complicated" because most people aren't going to be making super complicated games.
Speaking of Chat GPT, a lack of voice or personality in the narrative. I only finished Blue Dominion once because the writing felt so sterile (for lack of a better word RN), like there's no emotion or even urgency in it.
Well, dismissing a legitimate technical argument as “it sounds like ChatGPT because I don’t like your answer” and then doubling down on the same thing makes things pretty clear to me. Literally everything you’re saying reminds me a lot of YandereDev’s mindset: “if it works, it works; it’s not that deep.” And we already saw how that project ended. As for whether my answer sounds like ChatGPT… the person I was responding to initially acknowledged that they knew about programming, so I saw no reason to hold back. I was just giving my opinion based on things I’ve been working on directly in SugarCube for months. But that’s fine. If copy-pasting works for most people, go ahead. Everyone chooses their own level of depth.I might be a bit insane, and look too much into things, but this is legit how ChatGPT answers, down to the t. But aside from that.
I'm not proving any point of yours
Just because a work has 10, 100, or 1000 passages doesn't matter. If code works, it will work regardless of the number of passages. It's not that deep.
And copying code doesn't postpone anything. If it works, it works. Period. It's not going to magically break just because you added more text in game. Why would it
Though I do agree that not many are familiar with looking things up, since you do have to know some basic, general coding for that, but to learn that? Takes a few days at most, for the average joe.
Though yes, many of the writers aren't good in either one of those. Writing and coding. They usually suck at both
So to conclude gpt, no, the scale of a project doesn't matter. If we were talking about keeping track of things, then sure. But if we're talking coding specifically, it doesn't matter one bit. The code will work regardless of the scale, and if something needs to be fixed, basic knowledge and a bit of a keen eye will do the trick
Those GPT identifiers are crap. Since AI has to be trained on actual human writing first, and taking into consideration people tend to be too lazy or too dumb to follow language norms all the time (I'm both), any proper dissertation with correct grammar and punctuation will be flagged at least partially as AI. I do agree with you, but this specific piece of evidence is flimsy.
They remind me a lot of those plagiarism detectors that weren't accurate either I had in my classes before ai checkers tools which I'm now guessing teachers use instead. They detect almost anything as AI because AI has scraped a lot of human-written texts and these detection systems use AI and look at AI for the answers. The most prominent example I've seen is someone putting a paragraph of Frankenstein into one of these and it came back as 100% AI.
While that may be, the messages above are def ai
When an author has so many WIPs and the number keeps growing; especially when there's a new trend in IFs. And they get offended when they're asked out of concern if they can possibly finish all of these games when they update only 3 of the games very infrequently. But you're just supposed to take their word that their other 10 WIPs aren't abandoned and will be updated eventually. Also, when an author advertises their work as "dark" or "dark romance" and when you play it the setting and ROs aren't "dark". At most, the setting is more realistic and the ROs are the gloomy, broody, closed-off types.
Last edited:
It's not a legitimate argument, and I proved all the points you mentioned as wrong
Also, I never said that it sounds like ai because I don't like your answer, but because it is aiI know about programming as well, and you saying that the code will somehow get ****ed up if the work is bigger is simply a lie
Also, you said a lot that didn't make any sense, trying to make it sound complex when in reality it isn't. No point have you made in terms of coding that was explaining your view being right,and that's all that I was pointing at.L has been working in sugarcube for a good year now, so more than you. If he says it's easy, and then explains to me why that is, and you say here that it's not because you need some knowledge in coding, yeeeeeee, that's not a good argument my guy