Question About - Basic Frame for Daily Life games

Hello all! I was wondering, do we have any tutorial for setting up the framework and feedback loop for renpy-games in a similar style to The Weighting Game or Gain of Life? They obviously function very differently from traditional visual novels, like Forks or Handler Hazing, with the feedback loop and stat-tracking and constant daily choices.

Does anyone have a guide to get started on that basic framework? I’d be interested to try making a game in that style, but I don’t have the foggiest idea how to build that concept, so I haven’t put much time or effort into the actual ideas for the game.


There are a number of different coding styles that support it. You can do it with just a bunch of variables, conditions, and jumps - but it will get messy fast. There are two main things to consider: you need some kind of “clock” or “energy bar” (or both) to limit the number of things the PC can do in a day, and the other common thing is tracking where physically the PC is. Ren’Py’s menus obviously have a limit on how many choices can be presented at once (which is actually a good thing), so you do need to think about how you are going to manage “travel” without presenting too many choices at once.

I would say that these life-sim type games need a fair bit of variety in the events that happen, so any structure you can build on that allows more events or variations to be added as you go will pay off in the long run.

When I started writing Tramp I made a lot of use of call/return (and call expression), so events could be easily plugged in as wrtitng progressed. After each event completes it returns to a main loop to perform the time based checks before offering the next choice based on the PC’s location. Each location in the game (such as “bar”) has a label that presents a choice menu (label bar.freeChoice:) and in simple terms the main loop repeatedly does call expression pcLoc + ".freeChoice during the waking hours. When the day is done it has other labels it knows to call such as label bar.retHome: to describe the PC travelling home and label home.sleep: to describe them sleeping before the main loop advances the PC day, does some housekeeping, and calls label home.wake: before going back to freeChoice again.

This does turn the typical VN code structure on it’s head somewhat, but avoids having to repeat the “is-the-game-over-do-they-need-to-sleep” etc checks all over the code for each location. You can look at the source for Tramp, as it’s not archived, and I’m okay with people borrowing bits of it, but it is a programmer’s approach to the problem.

A little care is needed around the idea of clock day/hour and the PC’s “day” (or rather “sleeps”) if they are ever going to be up beyond midnight.

Depending on the nature of your game you may need code to handle future events, so a list of things the PC said they would do (eg. Anne agreed to go on a date with Ben on Friday night). Having a main loop again helps here as it can check if one of the scheduled future events has fallen due before calling that freeChoice label. This avoids the problem of the PC missing an event because they weren’t in the right place at the right time; instead it asks the player “You said you were going to go on a date with Ben, do you still want to go?”.