Ren'Py has at least 3 major problems:<p>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.<p>2. The code design is utterly atrocious. Global variables are <i>everywhere</i> in the implementation, and it is <i>common</i> 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.<p>(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)<p>3. Ren'Py's home-grown scripting system tries to be "smart". In reality that just makes it fragile. The less said, the better.<p>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 ...<p>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.