As somebody who has read a large number of visual novels (VNs), I consider Ren'py one of the better engines as a consumer:
- It has all the basic featured you'd expect, ranging from proper backlogs, to key bindings, and much more. You'd be shocked how many VN developers think that they can just pop out an VN engine themselves, and end up producing something that lacks even basic features.
- It is performant. You'd be surprised how poorly many VN engines run really poorly. Fast-forwarding past already-read text is often capped at a surprisingly slow rate, with your CPU pegged at 100%, due to how inefficient many engines are
- It is easily moddable, as you just need to plop a (pseudo-)python script into the game folder, so you can easily tweak or turn off annoying bits of UI
A number of localization companies have also ported (typically older) Japanese titles to Ren'py, instead of having to struggle with poor to non-existent support for non-Japanese systems in the original engine, as well as extremely expensive engine licenses, and just straight up poorly written bespoke engines. Examples of companies having done this includes JAST USA, FAKKU, MangaGamer, and (IIRC) Sekai Project/Denpasoft. In other words, the heavy hitters of VN localization.
The other main contender for best VN engine (in my mind) is the KiriKiri engine, which I believe is also open source, but which lacks the large, English-speaking community that Ren'py has built.
Despite that, Ren'py does have a bit of a poor reputation in the older VN reading community, more specifically among readers who mainly read localized, Japanese VNs, due to its association with low-budget, originally English visual novels. Typically the same people have only heard of DDLC and Katawa Shoujo, when it comes to originally English visual novels
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.
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
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), 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.
The script graph can be thought as a DFA, but a 'game state' (images showing on screen, music playing...) is different from a node of the script graph, and there is not a one-to-one mapping between them
For example, if the script loops through a node (and there is a choice to go out of the loop), and the node moves a character on screen to the left by 5 pixels each time, then there can be different game states with the same node. It happens in a common trope of VNs when the story lets you explore different places and go back to the original place each time
In the design of our VN framework, the game state is determined not by the current node, but by the node history (and other things like 'global variables'). If the author changes some script in the new version, then all saved data with the affected node history need to get updated
If there is no choice added/deleted, then the update can be implemented by simply re-running the nodes. However, if there are choices added/deleted, the update can be more complicated and involve graph isomorphism in the worst case
>The script graph can be thought as a DFA, but a 'game state' (images showing on screen, music playing...) is different from a node of the script graph, and there is not a one-to-one mapping between them
Sure. I would say it's a pretty bad idea though, and for instance in JOBifAI we manually managed savepoints in these case to stay isomorphic to a DFA anyway, because it's already hard enough to manage when the game has a big scope.
>If there is no choice added/deleted, then the update can be implemented by simply re-running the nodes. However, if there are choices added/deleted, the update can be more complicated and involve graph isomorphism in the worst case
Well. what you call 'global variables' is what I called 'persistent variables' above (using renPy's terminology).
If you consider that they can get any value, your problem can be reduced to the halting problem.
There are 2 ways you can get around that:
- any use of these variables in conditional transitions segments the domain into a finite number of subdomains (in that case it's just a proxy for a long expansion into a much bigger DFA)
- the variables belong to an infinite domain but are not involved into any state transition (for example, setting your name is not restricted but does not change any state transition)
Since the halting problem isn't solvable, if you use these two solutions you don't need to solve the graph isomorphism problem.
If you delete a node Si and your history contained Ss => Si => Se, you just need to find a path from Ss ==> Se. If you take the first in lexicographic order you even have a canonical solution.
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)?
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
I think you can accommodate most changes by storing ordered list of IDs of visited nodes as well as variables set by choices. This way if you'll delete or replace some nodes or branches you can walk back to still existing parts.
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
The best thing about Renpy is that the text rendering actually looks good, which is true of shockingly few VN engines even today.
Especially when you increase the window size or run fullscreen, most VN engines just render the whole game at a fixed resolution and upscale it up but Renpy makes the framebuffer match the window size and renders text at the full resolution.
>A number of localization companies have also ported (typically older) Japanese titles to Ren'py, instead of having to struggle with poor to non-existent support for non-Japanese systems in the original engine, as well as extremely expensive engine licenses, and just straight up poorly written bespoke engines. Examples of companies having done this includes JAST USA, FAKKU, MangaGamer, and (IIRC) Sekai Project/Denpasoft. In other words, the heavy hitters of VN localization.
That caught my curiosity, but I couldn't find any examples of older VNs being ported to Renpy. Could you share any examples?
Examples include 'Love Duction!' (2014) published by Sekai Project/Denpasoft, 'Sona-Nyl of the Violet Shadows Refrain' (2011) localized by MangaGamer,
multiple re-releases of late-90s/early 2000s titles published by JAST USA such as X-Change (1997-2004), Water Closet (2000), and Heart de Roommate (2003), and 'True Love 95' (1995) published by FAKKU
Something noticeably missing from almost every other type of text-heavy game which perhaps wouldn't be if games developers were less snobbish about where they draw inspiration from.
On the other hand, writers of games with metatextual stories benefit from their target audience not knowing how well-trod the ground is.
Agree, as a person with accessibility issues, I prefer this engine because it has a basic TTS support that I can mod and plug my own custom TTS script.
I also seen people reinventing poorly the engine in Unity so for me text based games or visual novels in Unity are just a NO , because of TTS support.
I agree as for my own VN I started working with a custom-made engine until I completed the rollback-feature requirements; after seeing the scope of it, I checked renPy and found it basically did everything right already.
In many ways I felt that the engine was designer for beginners rather than developers in a way that are antagonistic to each others.
No real debugger, no support for libraries, leading to re-implementation of basic stuff, etc. I had a love-hate relationship with it. Pseudo-python is the right term for it.
In the end I was happy with the Steam features it already had to make distribution easy, although I had to actually patch the engine as the Steam session ticket function was broken.
Sorry, as others have said, I meant a text log or "history". Basically, the ability to view the last N lines of text. For some VNs, this log also allows you to replay the voice lines, to jump back to specific lines/scenes, and even to bookmark specific lines, separately from saving the game. Ren'py is actually a bit unusual in this regard, since the default behavior is a rewind feature rather than a text log. However, most commercial Ren'py VNs will show the history as a log.
I think they meant scrollback. as conventionally a backlog would evoke "work yet to be done", whereas in this context we're talking about a conversation history one can revisit.
Like you can either read a log of what characters said in a scene so far, or simply go backwards through the story to reach an earlier line and view it again.
Much like books, that depends on what kind of stories interest you. Though it'd be advantageous for you if you enjoy romance, because that genre is heavily over-represented.
But if there are no titles that have already caught your interest, then my personal recommendation is to start with hybrid games such as VA-11 Hall-A, the Danganronpa series, the Ace Attorney series, WILL: A Wonderful World, and 999.
VNs are at their core a reading experience, frequently involving more words than what you'll find in the entire Lords of the Ring trilogy, but hybrid games like the above allow you to dip your toes in the VN genre without it purely being reading
Misericorde volumes 1 and 2 on Steam and Itch - both renpy based I believe. Fantastic example of an immersive novel, a murder mystery set in a 14th century abbey.
- It has all the basic featured you'd expect, ranging from proper backlogs, to key bindings, and much more. You'd be shocked how many VN developers think that they can just pop out an VN engine themselves, and end up producing something that lacks even basic features.
- It is performant. You'd be surprised how poorly many VN engines run really poorly. Fast-forwarding past already-read text is often capped at a surprisingly slow rate, with your CPU pegged at 100%, due to how inefficient many engines are
- It is easily moddable, as you just need to plop a (pseudo-)python script into the game folder, so you can easily tweak or turn off annoying bits of UI
A number of localization companies have also ported (typically older) Japanese titles to Ren'py, instead of having to struggle with poor to non-existent support for non-Japanese systems in the original engine, as well as extremely expensive engine licenses, and just straight up poorly written bespoke engines. Examples of companies having done this includes JAST USA, FAKKU, MangaGamer, and (IIRC) Sekai Project/Denpasoft. In other words, the heavy hitters of VN localization.
The other main contender for best VN engine (in my mind) is the KiriKiri engine, which I believe is also open source, but which lacks the large, English-speaking community that Ren'py has built.
Despite that, Ren'py does have a bit of a poor reputation in the older VN reading community, more specifically among readers who mainly read localized, Japanese VNs, due to its association with low-budget, originally English visual novels. Typically the same people have only heard of DDLC and Katawa Shoujo, when it comes to originally English visual novels