Hehe I've come across this tech from xxx games
Edit: I don't have the patience for these games but yeah I've seen the name before
The Ren'Py Visual Novel Engine
61–70 of 91 posts
Re: The Ren'Py Visual Novel Engine
#62I've always wondered if LLMs will slowly seep into this backyard. They are perfectly capable of creating the story (will probably be mid, barely interesting), the art (albeit easily recognized as AI slop) and the code (after some iterations) and with some tooling, even sign and deploy to websites all fully automated.
GenAI is becoming popular for image generation to add visuals to the novel.
Re: The Ren'Py Visual Novel Engine
#63As 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…
>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/Denpas…
Many examples can be queried from VNDB https://query.vndb.org/8e75036b2dcfe441
Re: The Ren'Py Visual Novel Engine
#64It's a player, like Flash.
What does it do that Flash didn't?
Re: The Ren'Py Visual Novel Engine
#65Earlier quoted context omitted.
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 i…
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 ca…
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.
Let me know if something is unclear.
Re: The Ren'Py Visual Novel Engine
#66It's a player, like Flash. What does it do that Flash didn't?
It has a DSL specified for writing VNs
Re: The Ren'Py Visual Novel Engine
#67As 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…
What does a "backlog" mean in this context?
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.
Re: The Ren'Py Visual Novel Engine
#68As 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…
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.
Re: The Ren'Py Visual Novel Engine
#69Earlier quoted context omitted.
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 ca…
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…
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
Re: The Ren'Py Visual Novel Engine
#70As 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…
>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/Denpas…
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