So you’ve decided to take the plunge and delve into the world of Ren’Py screen language. Screen language is a huge part of Ren’Py, and very powerful. It can be used to make minigames, game systems, or even to just customize the look of all the UI screens like save/load, preferences, etc.
And, if you’re coming here after taking a look at something like screens.rpy, it can also be very complex and daunting. But before we get into that: what are screens and screen language?
This tutorial is for beginners! You do not have to have any prior familiarity with Ren’Py screen language or UI.
What is a Screen?
A screen is what Ren’Py calls a collection of UI elements shown to the user at the same time. So, for example, a default Ren’Py project has a main menu screen, a preferences screen, a save and a load screen, a dialogue history screen, and more. There are also smaller screens which often display on top of or as indicators for in-game events, like the notify screen, the skip indicator screen, and the confirmation prompt screen.
A screen is designed to hold UI elements, like images, text, bars, and buttons, some of which the user may interact with to do things like adjust the game volume or play a minigame.
What is Screen Language?
Screen language is the way you describe to Ren’Py what a screen should look like and how it should act. It’s a description of how the screen looks and acts – screens don’t execute code line-by-line like labels, but are read and run more like one big chunk. As such, screens aren’t a place where you will put game logic like $ ashwin_points += 1. Rather, you can tie those sorts of things to occur on events, like when the player presses a button, or when a timer has finished counting down to 0.
Screen language is somewhat comparable to something like CSS, in that it’s designed almost entirely around assigning properties to various screen elements, like text, images, and buttons, in order to dictate things like how they look, where they are on-screen, and what they do when interacted with.
You can use screen language to modify the existing menu screens or make your own new ones, to add gameplay screens such as a route-select screen, or a free-roam map screen, and to add minigames like a puzzle screen or a point-and-click investigation section.
Getting Started with Screen Language
I want to start with a few words of reassurance for anyone who’s attempted to play around with the screens in a default project and had difficulty getting it to do what you want.
First: using screen language is a skill, and it’ll take some time to become familiar enough with it to easily do what you want
Second: I’m of the opinion that the default UI screens are actually an entire nightmare for people new to screen language. They’re built to be easy to reskin – swap some images in the gui/ folder, adjust some numbers in gui.rpy – but I’d argue that not only is the actual code that puts together the screens obtuse and spread out, it involves some very complex parts of Ren’Py that you will never need to use when creating your own screens. Most of the default screens are set up in a very specific way to plug into the values provided in gui.rpy. If you aren’t using those values, or if you’re making a new screen from scratch, Ren’Py doesn’t really have any examples in a default project to show you the simpler ways of making styles and screens.
So, if you’ve felt discouraged or frustrated trying to figure out screen language using the default Ren’Py project for guidance, or by trying to modify existing screens, you’ve essentially been attempting to learn screen language on Hard Mode. The good news is, there are much easier ways to go about it!
Easy Ren’Py Gui
In particular, when we get to examples of putting together entire screens, I will be using a new project template I created. It’s called EasyRenPyGui, and it does away with as much of the complex part of screen language as possible. You can find it on itch.io below, or on GitHub as a public template you can clone.
I do use styles and style prefixes in EasyRenPyGui, which are things I will explain as you read through these screen language tutorials, so don’t worry if you don’t quite understand all the bits and bobs yet. Importantly, the screens and style in my template are as stand-alone as possible, something that can’t be said of the default Ren’Py project template. So, if you change something in one screen, or in one style, it doesn’t have a cascading effect on other parts of your game. Where I’ve reused common elements, they are easily removed or replaced on a case-by-case basis.
Next Steps
For the upcoming screen language tutorials, I will be going over some of the basic building blocks of screen language first so you have the tools to start putting together your own screens. Later, when you have some more experience and sufficient tools, we will also look at some examples of putting together custom UI screens.
If you’re already familiar with the content in some of the tutorials, you’re welcome to skip over them to get to the tutorials with more examples. That said, I’d still recommend skimming them if you have time, as I also try to cover some of the lesser-known aspects of the various properties and screen elements that you might not know unless you make a hobby of reading the Ren’Py docs like a novel.
And with that said, it’s time to dive into Ren’Py’s screen language! Head over to the next tutorial: Ren’Py Screen Language Basics – Declaring and Showing a Screen
