The mod (game?) is getting close to something considered a reasonable state, summer is a busy time for us, but hopefully we can show something off soon (tm). The rest of this post is about my thoughts relating to the relationship between renpy, python, and gamedev.
Some thoughts of which I am unsure where to put elsewhere:
Renpy is simultaneously really powerful and really not. What I mean is that renpytom has a very specific philosophy about the type of engine he is building, which seems to be: my engine is for visual novels. As I have worked extensively with renpy for several months now, I would like to add to that statement. Specifically, renpy is for "reversible" and "skippable" visual novels with basic minigames thrown in. When I first started working with renpy it seemed like a really nice API for displaying images and text with pygame. Later, as I got more familiar with it, I found that in actuality it is a really nice "reversible" API for displaying images and text with pygame, which is a key difference. Nearly everything in the engine is either: building the API, or accommodating non-linear time. I have read so much of the renpy source code building this thing and I am super impressed. Not only does he comment his code really well, but what the engine does with python is amazing. This is a trap I nearly fell into, and I want to explain.
When I first started, I was quite excited, as I have a lot of experience with python and I originally tried to do as much as possible in it. I even got a little bit of the mod working with pure python. Then I tried running it, and saving it, and loading it, and rollback. Needless to say it broke, it broke so hard that renpy's usual error messages didn't work and it wouldn't crash. I then went back and redid it in as much of renpy as possible, this actually worked! This was the start of my philosophy about the use of python in renpy: use renpy constructs or ensure that I am just transforming/creating core python objects (or classes made up of core python objects which extend renpy.store.object). The reason I do this is to ensure that anything I do in python doesn't conflict with renpy and it's reversibility. It is also why I do all the building of the objects at the start and use renpy.retain_after_load() to not let it undo that (this also allows me to use python which can't be transformed backwards in the initialization step of objects).
After reading the source code I later learned that Renpytom rewrote most of the core python objects so that python would work with rollback (though based on documentation he really doesn't want you to go too far away from renpy stuff). This is a core tenant of the engine by it's design and by renpytom's words on github and lemmasoft (The warning about disabling rollback here:
You must be registered to see the links
undersells it) as how renpy saves/loads is also based around this principle.
Our mod is a visual novel, or at least a modification of one, so renpy is perfect for this, and while programming I keep in mind that everything I am building in it is in service of one. So even with all the new objects and managers, I want to ultimately make it easier to make conversations and change around when, where, and how conversations happen and look. I try to use renpy where possible to ensure rollback and skipping still works (Outside of the texting conversations, which is a small part of the game). The ultimate gameplay mechanic is still interacting with/triggering conversations which tells the story.
When encountering how powerful renpy is (esp with custom displayables), I found that it was easy to get lost in the weeds start using it as a pygame API (for an example which I learned from:
You must be registered to see the links
). I have since seen one or two examples of projects trying to do too much with renpy and start breaking the engine or fighting with the engine then giving up (which I found in my googling adventures and I am trying to avoid). If you find yourself needing to disable rollback for your game to work or starting to not build a visual novel, then you probably need to switch engines. I recommended Godot with dialogic (
You must be registered to see the links
) if you find yourself hitting a wall with renpy as GDScript has python-like qualities to it while being a fully featured game engine (which is free and open source).
TL;DR: Renpy is a reversible visual novel engine which makes it really easy to make said visual novels. If you need something more than that, choose a different engine.
P.S: set(renpy.game.context(-1).scene_lists.shown.shown) gives you a list of images currently on screen and which layers they are in. I couldn't find this mentioned anywhere on the internet.
P.S.S: For the love of all that is holy and unholy, do not build an engine yourself if you ever want to release a game:
You must be registered to see the links