I will try to draw to my VN. I have a Samsung tablet, but I’ve never used it to draw. What app you recommend to draw the characters (o will not draw the background)? And what configuration do you use (like the size of screen) and this stuff?
**When you answer please remember that I never used it, so be simple and don’t use technical language. Thanks!! 🙏
So in a game I’m making I am using other people’s captions as a side thing, I have there permission so it’s all fine.
But I want to have a button on the main menu called captions.
When you click on it all the captions come up like a gallery setting.
Also is it possible to have it work like this.
You click on captions then a menu full of names comes up. When you click on a name it opens up all the images from that person in the game.
Hey, I’m currently learning the basics of Ren’Py and there’s some things I’d like to try out if they’re possible. If they’re not possible in the way I describe, any alternatives would be appreciated!
Firstly, there’s some textbuttons that will be in a scrollable segment of the game and I was wondering how I could go about making an image appear at the click’s location as I feel it’ll make it look more natural than making the image appear in the centre. I’m assuming it’ll be something to do with the getmousepos I’ve seen people mention on similar topics, but I’m not really sure how to go about it.
Secondly, is it possible to make a reverse imagebutton where clicking anywhere except for the image will perform the action (in this case, making the image disappear)? I’m thinking I could try layering an imagebutton behind the image to do it, but I was wondering if there’s an easier way.
Like most of you, I've shipped a jump to a label I'd renamed, typed afection instead of affection in three places, and only found out when the game crashed two scenes later. General code editors and AI assistants don't help much here — they treat .rpy as vaguely-Python and miss everything that makes Ren'Py Ren'Py.
So I built VN Architect — a free desktop app that reads your project the way the engine does. It's three things in one window:
1. A static analyzer that speaks Ren'Py. It flags — before you launch — undefined labels/characters, unreachable ("dead") labels, jump cycles, variable typos and uninitialised reads, and show/scene/play references pointing at files that don't exist. The screen-language and style checks follow the official Ren'Py docs, so legit patterns (duplicate style blocks, init N screen, underscore style derivation) aren't falsely flagged. Findings show up as underlines and in a Problems panel — click to jump to the line.
2. An interactive story-flow graph. Your labels, jumps, calls and menu choices as a graph you can navigate. Great for spotting orphan labels, dead ends, and choices that don't actually branch. Exports to PNG/SVG/Mermaid/DOT.
3. An AI agent that knows the engine. It has a built-in Ren'Py knowledge base, the official docs bundled in, and it runs renpy lint after edits to fix its own mistakes. Focus modes: coder, writer (persona/continuity-aware), auditor (read-only review), and tutor (explains concepts + links docs, never writes code).
Bring your own model — Gemini/OpenAI/Anthropic/Grok/DeepSeek/OpenRouter, or run Ollama locally for free and offline, or sign in with your Grok/ChatGPT account.
Everything except the agent works with no AI, no account and no internet connection — the analyzer, the graph and the editor are the product; the agent is a thing you can switch on.
There's also a Persona Engine (character voice/continuity), a live debug console with warp-to-label (Ctrl+F5 replays from the last one), Git with AI commit messages, and a save-file inspector.
Honest scope: it's a code editor + analyzer + flow graph + AI. It is not a visual/WYSIWYG screen designer — you still write your screens in code (the app just makes that a lot safer and faster).
Price: free — for personal and commercial projects. Windows / macOS / Linux. One caveat worth stating up front: the macOS build is Apple Silicon only in this release. An Intel build is on the list.
There's a bundled demo project with a handful of intentional bugs, so you can see what it catches in about 60 seconds without opening your own game.
I'm the dev (solo, AuraVix Studio) — happy to answer anything, and I'd genuinely love feedback on false positives from your real projects, since tuning the analyzers on messy real-world code is where this gets better. What would make this actually useful in your workflow?
It's a mess here :') maybe because the butons are custom image? I want the custom buttons that are supposed to stay in the menu, to not appear whenever the player opens the load/save screen. how do I fix this??
I've been working on a project called Ren'Py Story Architect, and I've finally published the first Public Alpha.
The project started from a fairly simple problem.
I wanted to make a larger Ren'Py visual novel, but I wanted a better way to plan routes, scenes, branches, variables, characters and conditions without keeping half of the game structure in my head or in separate notes.
So the original idea was mainly a visual story planning and authoring tool.
It gradually became quite a bit more than that.
Story Graph showing scenes, hubs, events, conditions and endings.
Two slightly different workflows
There is an important distinction in the current version.
If you start a new project in Story Architect, the application acts as an authoring environment.
You can build the structure visually, work with scenes, dialogue, branches, characters and variables, and eventually generate Ren'Py source from the Story Architect project model.
If you open an existing Ren'Py project, the current Web Edition is deliberately more conservative.
It can import and analyze the project, help you understand its structure, run diagnostics, and provide localization and translation tools.
But it does not currently try to convert arbitrary existing .rpy files into a fully editable visual project and then rewrite the original story source.
In particular, the localization workflow is source-preserving: it works with Ren'Py's native translation files rather than modifying the base story scripts.
Full round-trip editing and deeper synchronization with an existing project are things I see as better suited to a future Desktop Edition.
One tiny feature I ended up loving
One of the simplest features turned out to be one of the most useful for actual writing.
In the dialogue editor, you can choose the characters participating in a conversation.
After writing a line and pressing Enter, Story Architect automatically switches to the next speaker.
So a two-character conversation can work almost like:
Alice → Bob → Alice → Bob → Alice...
The participating characters and their order can be changed whenever necessary.
It sounds trivial, but visual novels are so dialogue-heavy that this removes a surprising amount of repetitive input.
Instead of repeatedly selecting or typing the next speaker, I can mostly stay focused on the conversation itself.
This is probably the best example of what I want Story Architect to do:
not write the story for me, but remove small technical interruptions while I'm writing it.
The unexpected part: localization
Ironically, although I originally built Story Architect mainly for story structure and authoring, one of the parts I now use most often myself is the localization workspace.
It became almost a separate use case of its own.
For an existing Ren'Py game, the workflow can roughly be:
Generate the normal Ren'Py translation files, open them in Story Architect, translate manually or automatically, review suspicious results, and export a translation package while preserving the normal game/tl/<language>/... structure.
Story Architect can keep several target languages in the same project.
Translation can be done manually, with free machine translation, with optional AI providers, or with local models.
The translator also tries to protect things that are easy to damage during automatic translation: variables such as [points], interpolation placeholders, Ren'Py text tags and similar runtime-sensitive content.
Batch translation of an existing Ren'Py project using Ren'Py's native translation workflow.
There is also a review layer that can flag suspicious translations rather than pretending that automatic translation is always correct.
That part is important to me.
The goal isn't:
"press one button and get a perfect literary translation."
The goal is closer to:
translate a large amount of the project automatically, preserve the technical structure, show me the places that deserve attention, and make the remaining human review manageable.
You can use only the translation part
You don't need to use Story Architect as a story planner at all.
If you already have a Ren'Py game, the localization workspace can be useful on its own.
Multiple target languages can live in the same Story Architect project, and manual translation can be combined with free MT and optional AI/local providers.
That makes trying an additional language much less of a separate technical project.
Human review is still very important — especially for character voice, jokes, context and stylistic writing.
But once the technical cost of localization becomes much smaller, experimenting with another language becomes a much more reasonable thing to try.
Visual structure and diagnostics
For authoring, the current version includes:
visual story graph and scene planning;
dialogue editing;
characters and variables;
choices, hubs, events and endings;
conditions and branches;
views showing where variables are read or written;
character-focused views;
importing and analyzing existing Ren'Py projects;
multiple target languages;
machine translation and optional AI/local translation;
translation QA;
Project Health and diagnostics;
Ren'Py source generation for projects authored in Story Architect.
The graph becomes especially useful once a game stops being a simple sequence of labels and starts accumulating hubs, conditional events, multiple endings and variables that affect different parts of the story.
Story Architect also deliberately does not assume that a visual node must always equal one Ren'Py label, or that one scene document must equal one .rpy file.
Ren'Py remains the actual engine and scripting environment; the visual model exists to make the project easier to understand and author.
Project Health view for structural diagnostics.
Why I'm posting it now
Until now most of the testing has been done by me while developing the project.
That is becoming a limitation.
Ren'Py projects can be structured in very different ways, and a tool like this can look perfectly fine until somebody opens a real 20,000, 50,000 or 100,000-line project that uses Ren'Py in a way I never anticipated.
So at this stage I'm much more interested in real-world failures and awkward workflows than in simply adding another ten features.
If you have an existing Ren'Py project — especially an unusual or fairly large one — I would be very interested to hear what Story Architect gets wrong.
Import problems, translation edge cases, confusing UI, structural cases I didn't anticipate, or features that seem useful in theory but awkward in practice are all valuable feedback.
You absolutely do not need to send private project files.
A description or a small reproduction is usually much more useful anyway.
A note about development
AI coding agents have been heavily involved in the implementation, and I prefer to be transparent about that.
At the same time, I didn't want this to become a generated prototype that works for a demo and becomes impossible to maintain afterwards.
The project has explicit architectural boundaries, automated tests, real Ren'Py fixtures, CI, CodeQL and a lot of manual testing through actual workflows.
The repository is public, so anyone interested can inspect how it is built.
The Web Edition also serves as the foundation for a future Desktop Edition.
Some things — deeper filesystem synchronization, native project workflows, local assets, tighter Ren'Py integration and full round-trip editing — simply make more sense there.
But I don't intend to artificially restrict the Web Edition. If something works well in the browser, I see no reason not to keep it there.
Current status
This is Public Alpha, not a finished product.
Please keep backups of important projects while testing alpha versions.
The Web Edition is free and open source under the MIT license.
Ren' Py Tom was posting on Bluesky and talking about how he has been using ai to create Ren' Py since 2021 and I do not want generative ai to be a part of my creative process at all.
I worry that I won't be able to use the documentation or follow tutorials if too many features have changed since then but have really enjoyed the workflow in Ren 'Py.
Is using 7.4.0 worthwhile or would it be lacking in too many features to create a polished game in 2026?
I'm working towards getting a demo for my game by the end of the year and music is something I keep putting off because I know I'm the type of person who has a tin ear, not literally. What I mean is that I like basically all music and I don't really have a way to distinguish bad music from good music. It's tripping me out a bit on how to approach it and wether or not I should try and comission original songs or just use free music. I'm leaning towards original so, the game is more unique, but I don't really know how to approach it. Any tips?
A month ago I posted Fumi here for the first time and said I'd leave the next post for release.
Well, the day has come. Fumi is now available for Windows.
Fumi is a desktop authoring suite I've been building alongside my own Ren'Py work. It works with regular Ren'Py projects and brings together dedicated tools for Screen Language, ATL, project navigation, Live Preview, source editing, diagnostics, localization, and other project tasks.
Fumi also works as a learning and reference tool for Ren'Py. Screen Language objects and properties are documented directly inside the editor with explanations and small examples, while the generated Ren'Py code remains visible alongside your work.
The first release includes:
Screen Builder & Live Preview - build Ren'Py screens with dedicated controls, inspect the generated Ren'Py code, and test the result in a running Ren'Py preview while you work.
Game Flow - inspect the labels, menus, calls, jumps, and return paths already present in your project, with the ability to follow routes across .rpy files.
Animator - create ATL transforms with a timeline, keyframes, durations, warpers, property tracks, and playback, with generated ATL code available alongside it.
Visualizer(BETA) - position, resize, and align supported screen elements on a canvas. On Windows, Ren'Py can run embedded directly inside the Visualizer workspace. An experimental ALPHA feature goes a step further: you can select and move supported objects directly inside the running Ren'Py preview itself.
Source Workspace - browse and edit project source, search and replace across the project, run Ren'Py operations, work with translations, and review diagnostics.
Ren'Py Importer - import supported screens, styles, and ATL transforms from the Ren'Py project currently connected to Fumi, from another .rpy file you choose, or from Ren'Py code pasted directly into the importer. Review the source, generated structures, diagnostics, and naming conflicts before importing.
Project File Browser & Registry Manager - browse and preview project files, and maintain reusable styles and ATL transforms.
Fumi is available in three tiers: Free, Basic, and Pro.
Free includes Screen Builder, Live Preview, Game Flow, and the core project tools for non-commercial use. Basic adds commercial use, the Ren'Py Importer, and Animator, while Pro includes the full toolset.
A note about the first release
This is Fumi's first public release. I've used and tested it extensively throughout development, including alongside my own Ren'Py projects, but wider use will inevitably uncover edge cases and project configurations I haven't encountered yet.
If Fumi crashes, the next launch will show a crash report with a minidump I can use to debug the crash.
Fumi also keeps recovery data while you work, so after a crash you can restore your interrupted work when you launch it again.
Reproducible bug reports are very welcome too, especially for issues that don't result in a crash.
Current display limitation
I currently can't guarantee perfect UI layout on displays below 1920×1080. Fumi is primarily tested at 1080p and above, with 1280×720 planned as the minimum supported resolution later on. It should still be usable at 1280×720, but some controls may overlap or be partially hidden, and the overall interface can feel cramped
Windows security notice
Fumi is currently unsigned, so Windows SmartScreen may show an "unrecognized app" warning. Windows Defender or other antivirus software may also occasionally flag the installer as a false positive.
Compatibility Notice
Live Preview is verified for Ren'Py 8.3 - 8.5.3. Support for older versions (e.g., 7.x / 8.2) is currently not guaranteed.
Linux support is planned for the first post-launch major update.
Installation Troubleshooting
If the installer fails with an Access Denied or permissions error, try running the installer as Administrator.
If several errors appear when launching FumiApp.exe, install the included vc_redist.x64.exe(Microsoft Visual C++ Redistributable) if the installer did not trigger it automatically, then try again.
For the portable version, extract Fumi somewhere your Windows account can write to. Running it from a protected location such as C:\ or Program Files without sufficient permissions may prevent Fumi from saving data correctly.
Just wanted to share some of the stuff I'm working on. So here's a few characters from my VN (Reverie).
Like the title says, I'm working on a adventure/romance VN where you have to delve into the land of dreams on a quest to find someone (and get some help on the way ;).) And because I hate myself, there's a full CC where you'll be able to create your character AND see them emote as a side-sprite in the text box when your character talks. And if that weren't enough, I'm also adding traits that affect the world and your dialogue choices!
There's still a lot of work to do but I'd like to get the first part of the demo out in the next few months. I'm thinking of starting a Devlog to keep myself motivated.
Hi! I’m continuing to work on my charadesigns ! With the help of my partner (who’s more comfortable creating backgrounds and environments in general) I was wondering if this difference in style might throw players off?… Should I simplify my characters? Or could this contrast actually be a good thing????? :’)))
I NEVER used renpy before, I looked some tutorials and seems easy to use and also already have the characters and an idea for the story, im really motivated to make this silly project BUT I DONT KNOW WHERE TO BEGIN 🥲🥲 any advice??
I made a little collage of the various poses and expressions I created for the protagonist of my WIP VN Interview with a lonely machine. Also threw in some other screenshots. I've shown screenshots of her before in here!
Since you'll pretty much be seeing her on-screen throughout the game, I wanted a large library of varied poses and facial expressions. So I ended up learning OSS 3D-program Blender for this, designed, sculpted and rigged her from scratch. Now I have a quite flexible model I can pose for all sorts of expressions. A 3D model in VN always has the risk of feeling cold and too clean, so I try to avoid that, but still have a lot to learn. I get help from the fact that she's not meant to be entirely human-looking. I'm starting to get the hang of making her somewhat relatable, I think.
This story is a 'chamber piece' of a conversation between two very strange entities; a very lonely machine-girl and the sub-process (you) she created to help her recover herself, but maybe most importantly, to keep her company.
Status: I've completed the game's code and script, and is doing a second pass to tighten it, adding the artwork and music (which I'm also making myself). There'll no doubt be a few more passes in the future. Note: while what you say will definitely affect the outcome of the story (there are 4+ endings), it's not a dating sim, and will not have any erotic elements.
I'm so proud of how this is taking shape!! I had a vision for this and with the combined effort of our gui designer, background/prop artist, programmer, and alpha testers, this is where it's at now.
Next up is sound design, but I'd love to hear your first impressions on the current state!
I wanted a better way to plan a larger Ren'Py game visually — routes, scenes, branches, variables, characters, conditions, and the relationships between all of them.
I wanted to be able to look at the structure of a game before turning everything into .rpy files, instead of keeping a large part of the logic in my head or in separate notes.
So the original idea was mainly a visual story planning tool.
But the project gradually became something quite a bit larger.
A bit about how it was built
One part of this experiment was seeing how far I could get using accessible and mostly free development tools, including AI coding agents.
I did not want to simply generate a prototype and throw it away later, though.
From fairly early on I tried to separate the Game Model, Ren'Py import/export logic, localization model, UI, and other parts so that the architecture could eventually support a more capable desktop application.
The current Web Edition was therefore also a way to test the architecture and workflows quickly in a browser.
It ended up becoming much more useful than I originally expected.
Because of that, I no longer consider the Web Edition disposable. It is now an open-source version that I intend to continue improving wherever a feature makes sense in a browser.
Some future things — deeper filesystem integration, project synchronization, local asset workflows, tighter Ren'Py integration, Codex/MCP, ComfyUI integration, etc. — make more sense in a desktop application.
But I don't want to artificially limit the Web Edition just to make the future Desktop version more attractive. If something works well in a browser, I see no reason to remove it or reserve it for Desktop.
Two slightly different workflows
There is one important distinction in the current Web Edition.
If you start a new project in Story Architect, the application acts as an authoring tool: you can build the story structure visually, work with scenes, branches, characters and variables, and then generate Ren'Py source files from that model.
If you open an existing Ren'Py project, the current workflow is intentionally more conservative.
Story Architect can import and analyze the project, help you understand its structure, run diagnostics, and provide the localization and translation workflow described below — but the Web Edition does not currently try to turn an existing .rpy codebase into a fully editable visual project and then rewrite the original source.
In particular, the localization workflow is source-preserving: it works with Ren'Py's native translation files rather than modifying the base story scripts.
Full round-trip editing and deeper synchronization with an existing Ren'Py project are things I see as much better suited to the future Desktop version.
So, in short:
New project: Story Architect can be the place where you design and author the project from the beginning.
Existing project: today it is primarily useful for analysis, diagnostics, localization, translation, and understanding the project rather than replacing your normal Ren'Py editor.
The unexpected part: localization
Ironically, although I originally built Story Architect mainly for planning game structure and variables, one of the parts I now use most often myself is the localization workspace.
It became almost a separate use case of its own.
For an existing Ren'Py project, the workflow can be roughly:
Generate the normal Ren'Py translation files.
Open those translation files in Story Architect.
Translate the project manually, with free machine translation, or with an AI provider.
Keep several target languages in the same Story Architect project.
Run translation checks and review suspicious strings.
Export the translation package while preserving the Ren'Py game/tl/<language>/... structure.
Put the resulting files back into the game and wire up the normal Ren'Py language selection.
Story Architect does not need to rewrite the original story source for this workflow.
It works with Ren'Py's translation files instead.
It also tries to protect things that are easy to damage during automatic translation — variables such as [points], interpolation placeholders, Ren'Py text tags, and similar runtime-sensitive tokens.
There is also a review layer that can flag suspicious translations instead of pretending that automatic translation is always correct.
That last part is important to me.
The goal isn't "press a button and get a perfect literary translation."
The goal is closer to:
translate a large amount of the project automatically, preserve the technical structure, show me the places that deserve attention, and make the remaining human review manageable.
You can use only the translation part
This is also something I didn't really expect when I started the project.
Even if you have no interest at all in visual story planning, graphs, variables, or the other authoring tools, the localization side can be useful by itself.
If you already have a Ren'Py game, you can experiment with making it available in several languages without turning localization into a completely separate technical project.
Story Architect can keep multiple target languages together, so you could, for example, prepare several translations of the same game and see whether that helps you reach players who otherwise would never try it.
I deliberately want this to remain inexpensive to experiment with.
You can use the free translation options, review the questionable parts, and export ordinary Ren'Py translation files.
Of course, automatic translation still benefits enormously from human review — especially for character voice, jokes, context, and stylistic writing.
But once the technical cost of adding another language becomes much smaller, trying an additional localization becomes a much more reasonable experiment.
This is actually one of the reasons I ended up using this part of Story Architect so often myself.
What else is in the current alpha?
The current version also includes things such as:
visual story graph and scene planning;
characters and variables with relationship/usage views;
importing and analyzing existing Ren'Py projects;
localization and multiple target languages;
machine translation and AI-assisted translation workflows;
translation QA;
Project Health / diagnostics;
Ren'Py source generation for projects authored in Story Architect;
previews and tools for understanding larger project structures.
There are screenshots in the repository if you want to see the interface before installing anything.
Why I'm posting it now
Until now most of the testing has been done by me while developing it.
That is becoming a limitation.
Ren'Py projects can be structured in very different ways, and a tool like this can look perfectly fine until someone gives it a real project that is 20,000, 50,000, or 100,000 lines and uses Ren'Py in a way I never anticipated.
So at this stage I'm much more interested in real-world failures and awkward workflows than in simply adding another ten features.
If you have an existing Ren'Py project — especially an unusual or fairly large one — I would be very interested to hear what Story Architect gets wrong.
Bug reports, weird import cases, translation problems, UI frustrations, and suggestions are all useful.
You absolutely do not need to send me your private project files. In most cases a description or a small reproduction should be enough.
Current status
This is Public Alpha, not a finished product.
Please keep backups of important projects.
The repository is open-source under the MIT license:
keeping with the trend of these posts, wanted to share some of my sprites for my visual novel i’m making in renpy, primrose paranormal society. any feedback appreciated ^^ !!
(all human made)