Ren'Py Best Ren'py games

[hamlet17]

What do you think are the best and most complex Ren’py games here considering development quality?

 

[muttdoggy]

Doki Doki Literature Club. The trickery and programming chops are outstanding.
SuperPowered is crammed full of variables, stats, powers, and is a time sink.

 

[Papa Ernie]

It's easy to forget that Summertime Saga is Ren'py due to the excellent animated town map, custom UI, and matching artistic backgrounds and characters.

 

[Aeilion]

I don't know a lot of complex game in renpy, I still respect View of family who uses a system of time per hour, which is not easy to manage compared to a time per period. That being said I did not shell the code to see how he did it so ... I don't know if it's done well or not, but it works.
Obviously Superpowered is complex in view of all its mechanisms but I do not like this game, to the point that it is difficult for me to imagine it as a reference ^^

 

[CobraPL]

You must be registered to see the links

it may not be best. But is professionally made. Especially music.

 

[anne O'nymous]

Not a single one and a lot.
Summertime Saga have not bad mechanisms, but the code look like 70's Basic ; to be fair it tend to be better now, have they changed their coder recently ? Super Powered use a lot of good tricks, and it's probably the best example of, "how to works with Ren'py", but the implementation can be better. Innocent Witches try to be innovative, but fail to use Ren'py mechanism ; clearly they don't read all the doc. Sakura Dungeon isn't bad, and innovate with its 3D old school map, but abuse of objects nesting (can go up to twenty time the same object nested in itself). Babe Runner's code isn't too bad, but abuse of nested list (one of them go further than 200 000 bytes).
There's also a lot of not badly coded games among the recent ones. But most of them tend to stay basic. So, if I should choose, I'll probably goes for Girl in big city. Innovative, and not too badly coded.

This said, I talk as coder, and like any coder, if it's not done like I would have done it, then it can be done in a better way (our way is always the best one, always). In the same time, when people reuse code ideas of another game, then I'm not impressed because I already saw it.
In the end, in matter of "development quality", there isn't a single game which reach a high note. Whatever how good the code can be, it also fail somewhere, and this include the code of my own mods.

Ren'py is too hybrid to generate high quality code. Firstly, because its own language is a mix of old school languages (Basic, Fortran, etc.) with some modern paradigms. Secondly, because it have in fact two languages, the script one and the screen one. Thirdly, because it's a front end on top of Python, using Python in top of itself ; so you're never really sure if you should put the Python code on the back or on the front of Ren'py language. Fourthly, because in a way it look like Perl ; there's always a lot of different way to do the same thing, and most of them are legit. In the end, the way a coder will do it depend of its own state of mind at the moment he wrote the code.

 

[Studio Errilhl]

I think the question is a bit too vague, or maybe naïve. "Development quality" is a very subjective criteria, and can be interpreted in several ways.

Others mentioned Summertime Saga. I haven't looked that hard at the code, but it IS messy. But the game is well designed, with good playability, good graphics, good story. It is also a non-typical Ren'Py game. It is a great inspiration for myself, although I'm at least trying to not be stuck with the same amount of code (although I can see how it has its merits as well).

Dating my Daughter is also a relatively good game, but I haven't looked at the code, so I can't say if it's just good graphics and style. DmD is, however, fairly plain - it's just a branching game, with slightly prettier UI and some nice menus and such. The rest is fairly straight forward Ren'Py.

General Practitioner is also a nice example of using Ren'Py, but again it's a fairly straight forward game, just with a lot of pathways.

Lust and Power is a "repeatable" Ren'Py-game - ie, it has a limited set of actions per day, and you repeat a lot of the actions. It's a fairly impressive use of Ren'Py as well, but again, I haven't looked at the code, so I can't say if it's a "good game" in the context of this thread.

 

[Last Moment]

It's easy to forget that Summertime Saga is Ren'py due to the excellent animated town map, custom UI, and matching artistic backgrounds and characters.

Only downside is start a new game with each update, which can be avoided easily in engine like Ren'py.

 

[Studio Errilhl]

Only downside is start a new game with each update, which can be avoided easily in engine like Ren'py.

That is true. I think the reason for that issue (which they are updating to not have to start over, if I understood them correctly) is that they started out with an older version of Ren'Py, that didn't offer the same amount of abilities (or they were greenhorns when they started), and they made their own functionality for quite a bit of what Ren'Py does built-in. Which does make it less likely to end up in the "development heaven" - the code for SS *is* messy. I tried looking it over, to see how they did specific stuff - I gave up, simply because the whole thing was so convoluted, with so many files.

 

[Last Moment]

That is true. I think the reason for that issue (which they are updating to not have to start over, if I understood them correctly) is that they started out with an older version of Ren'Py, that didn't offer the same amount of abilities (or they were greenhorns when they started), and they made their own functionality for quite a bit of what Ren'Py does built-in. Which does make it less likely to end up in the "development heaven" - the code for SS *is* messy. I tried looking it over, to see how they did specific stuff - I gave up, simply because the whole thing was so convoluted, with so many files.

I think the problem, is the SS programmers are declare all the variables in the beginning of the game, not when they need like other programmers follow to match the incremental development of the game.
But really i like that game, and i think they hire a new programmer to solve this issue.

 

[Last Moment]

I don't know a lot of complex game in renpy, I still respect View of family who uses a system of time per hour, which is not easy to manage compared to a time per period. That being said I did not shell the code to see how he did it so ... I don't know if it's done well or not, but it works.
Obviously Superpowered is complex in view of all its mechanisms but I do not like this game, to the point that it is difficult for me to imagine it as a reference ^^

I don't like the Super-Powered mechanism or may be the team didn't explain it well. The Game is huge but they need to improve the User Experience (UX)

 

[Aeilion]

I think the problem, is the SS programmers are declare all the variables in the beginning of the game, not when they need like other programmers follow to match the incremental development of the game.
But really i like that game, and i think they hire a new programmer to solve this issue.

There is no problem declaring all the variables at the beginning of the game. The real problem is how to declare them. And as most of the information that can be found on the web about this is no longer up to date, we end up with bad habits that are repeated over and over again. Many learn to code by looking at the work of others. And so uses old methods that caused a lot of problems.
And indeed the tutorial of renpy gives information that is out of date so ...

 

[Rich]

I think the problem, is the SS programmers are declare all the variables in the beginning of the game.

There is no problem declaring all the variables at the beginning of the game. The real problem is how to declare them.

The real issue is that if you're going to keep your saves compatible, you have to keep your variables identical (or, at least, "upgradable") from release to release. SS had several internal rewrites where they changed the mechanisms they used to track progress through various steps in the game, which meant that the removed some variables and replaced them with others, and redefined how some of them were used. It's very hard to maintain backward compatibility in a situation like that.

In "vanilla" Ren'py, where all you do is add some additional variables with a new release, there's no problem, and you can either do it "as you go along" or "all in one place," as long as you provide default values for the variables so that variables that aren't in the save get a known value. Or you can even do an "undefined" check on a variable before using it. Several different mechanisms, as @anne O'nymous pointed out.

But, in this case, I think the SS folks just said, "we're going to do what's easiest for our programmers. it's a beta, deal with it."

And, by the way, the current code is a lot more organized and a lot cleaner than the original code. They do, however, use a few "interesting" update mechanism that make the code a bit harder to follow than the traditional "branching" Ren'py game.

 

[anne O'nymous]

And as most of the information that can be found on the web about this is no longer up to date, we end up with bad habits that are repeated over and over again. Many learn to code by looking at the work of others.

Yeah, that's the main problem. "This game do what I want to do, I'll look at its code". And after few time if become, "all these games do what I want to do, and they all do it in the same way, it must be the right one".

And indeed the tutorial of renpy gives information that is out of date so ...

It seem that he updated it for the version 6.99.13, but I don't guaranty it. There's also his tutorials. But he don't have a generic index for them, so you must search in his tweet or on his Patreon page to find the links.
Anyway, it's sad to say it, but Ren'py's author isn't the best Ren'py coder which exist. He's the one who wrote the code of the feature, and he do it with an idea in mind. This lead to an obvious problem, he fail to see the other possibilities.

In "vanilla" Ren'py, where all you do is add some additional variables with a new release, there's no problem, and you can either do it "as you go along" or "all in one place," as long as you provide default values for the variables so that variables that aren't in the save get a known value. Or you can even do an "undefined" check on a variable before using it. Several different mechanisms, as @anne O'nymous pointed out.

It's a good example of what I said. To correctly add new variables you can :

• Declare them in an init bloc ;
• Declare them at the start of the first label using them ;
• Declare them in a "updateXlabel" label called at the start of the new code, or called both by the "start" and "after_load" label ;
• Check if the variable exist before using them (directly in the code of the game, or using one of the callback) ;
• Put all the variable in a object which will act like the "persistent" variables (if the variable don't exist, it still exist) ;
• Tweak Ren'py's store to create them on the fly ;

So, just for this, and without thinking hard about it, there's 8 ways to do it. All are valid, and only the last one isn't really legit.

But, in this case, I think the SS folks just said, "we're going to do what's easiest for our programmers. it's a beta, deal with it."

I think that it's way more simple than that. The code was a real mess. As example, they used list of objects for counting (if the list have 6 objects, then the value is 6), having a different object (from a different class) depending of the list. Then don't needed a different object and, obviously, can have used a simple integer for this ; which is what they now do.
So part of the restart are due by the fact that the code really needed deep changes

They do, however, use a few "interesting" update mechanism that make the code a bit harder to follow than the traditional "branching" Ren'py game.

I haven't took a look at summertime saga since some months, but for me Super Powered is the example to follow in term of branching. Basically speaking, all the labels are already handled, even the ones which will not be added before years. He just need to add the missing labels and everything will works, no need to touch the main part of the game.

 

[Rich]

@anne O'nymous - all very valid points. By the way, when I used the term "update mechanism" I misled people with my terminology. I didn't mean "how to update the game to a new version," but "how to update the variables during the day and for the next day."

But the "what's easiest for the programmers" comment falls back to the fact that SS has never (to my knowledge) allowed reuse of saves from one version to the next. I know they did a massive rewrite at one point, but they didn't do a one-time "ok, compatibility break" - it's been true of every update. Making sure that old saves can work in a newer game in Ren'py takes a little bit of care and discipline on the part of the programmers. (That's part of what we're discussing here, of course.) Globally saying "Nah, I won't allow it" allows the programmers not to have to take that care. Of course, it also means that they're free to completely rewrite any section they want at any time (both from a coding point of view and also a "game play" point of view.)

Not criticizing - just observing.

But given that Ren'py is the baby of just one guy (or so I understand), the fact that he focuses on maintaining the code and not on writing tutorials is probably understandable. Heck, you have big, for-profit, commercial companies like Daz that basically say "ah, the heck with documentation - we'll let the community handle it." You can hardly heap too much criticism on a little, not-for-profit team that does the same.

 

[anne O'nymous]

But the "what's easiest for the programmers" comment falls back to the fact that SS has never (to my knowledge) allowed reuse of saves from one version to the next. I know they did a massive rewrite at one point, but they didn't do a one-time "ok, compatibility break" - it's been true of every update.

They did it once, for the 0.11 or 0.12 version if my memory don't betray me. But you're right, they took care of their users and concentrated all the breaking changes in one update. If they changed something else since, they did it in a soft way (take the current value by using the old method, and replacing it by the same value using the new method).

Making sure that old saves can work in a newer game in Ren'py takes a little bit of care and discipline on the part of the programmers. (That's part of what we're discussing here, of course.) Globally saying "Nah, I won't allow it" allows the programmers not to have to take that care. Of course, it also means that they're free to completely rewrite any section they want at any time (both from a coding point of view and also a "game play" point of view.)

There's only one thing which will always break a saves game, it's the way Ren'py track the position in the code. Whatever you do, never ever change the last label of the previous update. If you do, the risk is that Ren'py will not find a correct "entry point" for the save file and crash. It don't happen every time, but better be safe than sorry. Let one update pass, and you'll be able to edit the label without problems ; the majority of the players will be further now.
For everything else, there's always a way to do it without crash/bug, but like you said, it need some discipline from the coder(s).

But given that Ren'py is the baby of just one guy (or so I understand), the fact that he focuses on maintaining the code and not on writing tutorials is probably understandable.

He credits few other persons, but they just provided a patch for this or that, so 99,99% of the code come for the same person, yes. And I fully understand that he have no time for the doc. Anyway he's a coder, and we suck at writing doc for our how code. Like I understand that he isn't the best Ren'py coder ; I said it, after thinking about a feature for weeks, when not months, it's hard to see it otherwise than what you had in mind at first.
He have way more to do, and he do it great ; well, it can be better because it's not how I would have done it More seriously, there's not this much people in computer history, who did such a good works all by themselves. So, I critic him, but there's probably a small part of envy behind this.

Heck, you have big, for-profit, commercial companies like Daz that basically say "ah, the heck with documentation - we'll let the community handle it." You can hardly heap too much criticism on a little, not-for-profit team that does the same.

Especially since he still wrote some doc, two tutorials, answer himself to a lot of questions on the official forum, and continue to update his code really regularly (3 officials update since november, and around 10 none officials).