Ren'Py
github.com
github.com
If you have a friend who is a writer or artist who loves creating original stories, doing a project in renpy is an interesting way to collaborate and create something together with them.
Is there any interactivity?
1. Zero-or-minimal interactivity. A sequence of scenes with the occasional multiple-choice menu. When you get the occasional branch or maybe some randomness, it quickly leads to either a merge with the other branch (sometimes: just missed content on one side) or a Bad End. These are probably the vast majority of VNs, and the reason VNs have such a bad reputation - they're basically equivalent in complexity to the dialogue of a single NPC in a real videogame, just with more useless filler. At best these can be a way of the author showing off their ability to draw.
2. Moderate interactivity. Although still clearly based on a DAG of menus connected by scenes, these have a little state and long-term consequences from early choices. You might get a concept of player stats or custom menus (see #3) for a change, but they're not critical. Most "good" VNs aspire to this.
3. High interactivity. Since they have all the essential complexity of a real videogame, these really don't deserve the stigma of being called Visual Novels (even though they're implemented on a VN engine), and it's unfortunate when they are tagged as such (because that means people will filter them out). This doesn't actually make them good (many of them comparable to the slop that comes out of RPGMaker etc.), but at least they're meaningfully called games. The critical factor here is you revisit the same "menus" multiple times in a playthrough; often these menus have custom UI (for example "click where you want to go on the map"). Usually you have some kind of resources to manage and there's a meaningful day counter (where each day you get roughly the same choices).
1. It predates the fact that the "obvious" one-VM-to-rule-them-all is the web browser. Yes, it has a WASM version, but that's just several MB of overhead; these days it's just plain silly to target anything but HTML/JS-first (not necessarily only; an efficient native version isn't unreasonable if you plan for it) unless you explicitly need backward-compatibility. The fact that you get to write not-quite-Python rather than JS isn't enough to make up for this.
2. The code design is utterly atrocious. Global variables are everywhere in the implementation, and it is common for VNs to write to them from arbitrary places. Expect random breakage if you ever try to upgrade the embedded copy of Python or Ren'Py (either as the end user or as a VN author), even though this also means Ren'Py can't refactor its own code to be sane.
(note that I don't actually consider the mere fact of embedding to a problem per se; for once it's a reasonable decision for the target audience, even if it's a bad idea for most of the cases developers do it)
3. Ren'Py's home-grown scripting system tries to be "smart". In reality that just makes it fragile. The less said, the better.
4. It relies heavily on Pickle, so say hello to arbitrary code execution from data files! Granted, the backward-compatibility problem means you're probably downloading a random binary (plus assorted unsandboxed Python scripts) to execute in the first place ...
I invite everyone to try running the Ren'Py demos by installing them from Debian stable. Yes, Debian sucks for not updating things ... but this kind of error wouldn't even be possible with a sane design.
Re Pickle, besides the counterpoint you already mentioned, people probably aren't downloading saved games off the Internet, so to exploit Pickle an attacker would already need to have disk write access. At that point, exploiting a VN would appear to be low-ROI.
I haven't used it, but I don't love the script syntax. I think it wants to look like a screenplay, but it actually looks like the unholy lovechild of Python and assembly. I can easily believe it gets worse from there.