I hope this is the right place for this but I was messing around learning Renpy and built a template for a weight gain life simulator. I’m not feeling creative enough to write a whole story with it so hopefully someone out there would be interested in using this template for their own story? Anyone can feel free to use this however they want (personal, commercial, etc).
Some features include:
-A day cycle consisting of morning, afternoon, evening, and night.
-Stats for gaining/losing weight.
-Stats for a college GPA.
-Based out of your apartment with options for college, restaurants, a gym, some nightlife, and more.
-Every place is it’s own file so it should be fairly easy to read the code and understand how the structure works. (Hopefully good for beginners to learn from and build onto).
Gamers, Digital stated that it is a template for a game, it is not a game. You could use their template in Renpy to make a game, but at the moment, you are probably looking at just code
An issue with this is that none of the called labels ever seems to return, so the call stack will go on growing and eventually cause the game to crash.
I’d personally recommend any life-sim type game includes a main loop to simplify the structure of the game.
Not exactly how i would phrase it, in python with functions and with renpy labels the return is implied at the end of the python function(in python the interpreter does not make you expicitly call return at the end of a function it is implied and done automaticly even if you dont explicitly type out return to return, renpy engine is using this the end of a label has an implicit return when you call the label) or renpy label, so technically they all have a return rather because you call a new label before you ever exit the menu statement or previous label you never hit said return in any label most of the time, there for have an infinite recursion.
In this case call is the incorrect way to move from label to lablel it is not possible fix this by adding reurnts even assuming a main loop, and putting return after every call in the menu options, you would still get a infinate recursion problem.
This is why renpy has jump it is exactly what is appropaite here, your not calling the label your moving your point of execution to that point in the script. it avoids the infinite recursion issue.
If you wanted to fix this to use call and not jump rather than make a main loop which would not fix the issue, each menu options actions or text would need to be broken out into their own label and that label be the thing thats called such that it returns to the menu which then finishes and returns to whatever called its label. Also despite the rare exception any label calling itself is most likely going to end up in an infinate recursion problem. As architected which is like the example in the renpy sdk tutorial for renpy script you should be using jump.
This is very confusingly written, and in the case of Ren’Py script labels, utterly wrong! Ren’Py labels just mark points in the script, and there is no implied return when the next label is encountered, instead execution falls through to the next valid block of script. The only “implied return” is when the executing script drops off the last line of the last file, when it restarts the Main Menu.
Wrong again I’m afraid. It can be fixed with a main loop, and there is no infinite recursion if the returns are added. This is how Tramp works after all.
Ren’Py has jump, yes, and it is appropriate for some trivial games. But in a life sim it creates issues, as you have to know where to jump back to. The only solution is to hand-craft what amounts to a call stack, which is a dumb move as you’d be re-inventing the wheel. It’s why so many mid-sized Ren’Py games made right here have fall-through issues and unchecked (typically end-of-day) conditions. Again, there’s no “infinite recursion issue” if the returns are in place. Infinite recursion can only happen if a label unconditionally calls itself, or a chain of labels unconditionally call each other.
The whole idea of a main loop is to perform one player action and then return to the loop to check what happens next. There is no infinite recursion, and when the loop executes, just one entry on the stack: the call to main_loop.
If you’ve created inifinite recursion in a Ren’Py game then you are objectively doing it wrong and really need to brush up on your basic programming before offering advice.
Just because one brief tutorial for completely unskilled and novice programmers uses jump, it does not make it the best architectural choice, especially when te example is a simple branching narrative and not a life sim! I think we can all agree that the Ren’Py tutorial and its documentation are not great; if they were we wouldn’t need Fenicks and Lezcave!