3 ms·

One thing Ren'Py does well that many other engines do poorly is forward compatibility of saves. When VNs are released in pieces over time it is important to ma

One thing Ren'Py does well that many other engines do poorly is forward compatibility of saves. When VNs are released in pieces over time it is important to make sure the saves carry forward. Nothing kills momentum like "you will need to start over from scratch after every update". As far as competitors go, the list is not very long. Sugarcube/Twine works ok, but tends to bog down as the projects grow large because it doesn't have a good way of breaking up the core logic across different files. The save system is also a bit of a problem since the in-browser saves tend to get lost in version updates. QSP is just a buggy confusing mess every time. People try to shoehorn RPGMaker into doing the job but it is just so clunky and slow. Custom engines, typically built in Unity, are almost always massive resource hogs and lacking in one or more of the basic features Ren'Py provides by default. Plus there is just the community aspect of it, with Ren'Py having so many developers there is a lot of institutional knowledge to be had. If you run into a problem you are probably not the first, someone else has probably solved it already.

optionalsquid 2y ago
I took a quick look via query.vndb.org, and the top 10 most popular engines in terms of releases are Ren'Py, KiriKiri, TyranoScript, Unity, NScripter, LiveMaker, RPG Maker, YU-RIS, Flash, and Artemis (from most to least). This is of course not an exact ranking, since the same game can have many (nearly identical) releases, but it roughly matches my experience
- snvzz 2y ago
  Notably nscripter has a third party open source reimplementation in onscripter[0], which in turn has a fork in onscripter-en[1]. 0. https://github.com/ogapee/onscripter https://github.com/ogapee/onscripter 1. https://github.com/Galladite27/ONScripter-EN https://github.com/Galladite27/ONScripter-EN
woctordho 2y ago
Forward compatibility of saves is harder than people thought. VN scripts have choices and loops, so in general they are graphs, and upgrading the saves to another version requires matching two graphs. I'd be happy to know if there is a good diff algorithm for graphs In practice graph matching can be helped by manually tagging the same nodes (labels in Ren'Py) in the two versions, but that cannot cover all the edge cases I'm developing a VN framework for the own use of my indie VN dev group, and we mostly implemented the diff algorithm for the 'linear' part of the graphs. You can search my handle to know more
- KomradeKeeks 2y ago
  Hey, thanks for the context in this thread; I've been working on a project in I7 because I love the form factor of parser &choice-based IF. I'm looking to release the project like a webcomic, with monthly/quarterly chapters, but the backwards compatibility issue in I7 has been a blocker. In your indie VN dev group, are there any devs working on cross-platform, parser & choice-based VNs (ie I can read a work on mobile as choice-based, but if I want to continue that same save on my computer/ enter commands, I can do that)?
  - woctordho 2y ago
    We use Unity so it's cross-platform, including mobile. But we never implemented a server for cloud saves, so you need to sync the saves using other tools
- woolion 2y ago
  If you take the graph of the game, you basically have a DFA (deterministic finite automaton), so the problem is purely a reachability one which is trivial. In renPy, you have arbitrary variables that can be used to define the possible transitions. So reachability becomes a problem depending on the automaton state X persistent variables. Unfortunately, that means that now reachability is now Turing-complete, since you need to analyze the code that interacts with all variables. So say you have a transition tau from state Si to Sj, you need to make sure the labels contain any persistent variable that is used to trigger tau. You can make sure to be forward compatible by (1) never removing states, and (2) making sure that any state x (value of persistent variables) has a transition. Of course, that condition (2) is often violated by assuming that if you are in state Si, you must have gone through state Sk which sets a given variable to x, and fail to realize that there is another path to Si that does not go through Sk and you are stuck. If you add new states or new variables to your game, you are effectively creating this situation for all states. Reachability is a trivial problem, but checking the values all variables can take is kind of famously Turing-complete. So if you want to be able to do that, you need your use of variables so that basically you could eliminate them by replacing them by having more states. Btw, the problem you mention is a notoriously painful one (https://en.wikipedia.org/wiki/Graph_isomorphism_problem https://en.wikipedia.org/wiki/Graph_isomorphism_problem), but with VNs you have labels so I think the issue is not to produce a diff but make it useful enough to check all game conditions. Let me know if something is unclear.

optionalsquid 2y ago

I took a quick look via query.vndb.org, and the top 10 most popular engines in terms of releases are Ren'Py, KiriKiri, TyranoScript, Unity, NScripter, LiveMaker, RPG Maker, YU-RIS, Flash, and Artemis (from most to least). This is of course not an exact ranking, since the same game can have many (nearly identical) releases, but it roughly matches my experience

snvzz 2y ago
Notably nscripter has a third party open source reimplementation in onscripter[0], which in turn has a fork in onscripter-en[1]. 0. https://github.com/ogapee/onscripter https://github.com/ogapee/onscripter 1. https://github.com/Galladite27/ONScripter-EN https://github.com/Galladite27/ONScripter-EN

woctordho 2y ago

Forward compatibility of saves is harder than people thought. VN scripts have choices and loops, so in general they are graphs, and upgrading the saves to another version requires matching two graphs. I'd be happy to know if there is a good diff algorithm for graphs In practice graph matching can be helped by manually tagging the same nodes (labels in Ren'Py) in the two versions, but that cannot cover all the edge cases I'm developing a VN framework for the own use of my indie VN dev group, and we mostly implemented the diff algorithm for the 'linear' part of the graphs. You can search my handle to know more

KomradeKeeks 2y ago
Hey, thanks for the context in this thread; I've been working on a project in I7 because I love the form factor of parser &choice-based IF. I'm looking to release the project like a webcomic, with monthly/quarterly chapters, but the backwards compatibility issue in I7 has been a blocker. In your indie VN dev group, are there any devs working on cross-platform, parser & choice-based VNs (ie I can read a work on mobile as choice-based, but if I want to continue that same save on my computer/ enter commands, I can do that)?
- woctordho 2y ago
  We use Unity so it's cross-platform, including mobile. But we never implemented a server for cloud saves, so you need to sync the saves using other tools
woolion 2y ago
If you take the graph of the game, you basically have a DFA (deterministic finite automaton), so the problem is purely a reachability one which is trivial. In renPy, you have arbitrary variables that can be used to define the possible transitions. So reachability becomes a problem depending on the automaton state X persistent variables. Unfortunately, that means that now reachability is now Turing-complete, since you need to analyze the code that interacts with all variables. So say you have a transition tau from state Si to Sj, you need to make sure the labels contain any persistent variable that is used to trigger tau. You can make sure to be forward compatible by (1) never removing states, and (2) making sure that any state x (value of persistent variables) has a transition. Of course, that condition (2) is often violated by assuming that if you are in state Si, you must have gone through state Sk which sets a given variable to x, and fail to realize that there is another path to Si that does not go through Sk and you are stuck. If you add new states or new variables to your game, you are effectively creating this situation for all states. Reachability is a trivial problem, but checking the values all variables can take is kind of famously Turing-complete. So if you want to be able to do that, you need your use of variables so that basically you could eliminate them by replacing them by having more states. Btw, the problem you mention is a notoriously painful one (https://en.wikipedia.org/wiki/Graph_isomorphism_problem https://en.wikipedia.org/wiki/Graph_isomorphism_problem), but with VNs you have labels so I think the issue is not to produce a diff but make it useful enough to check all game conditions. Let me know if something is unclear.