Behind the Scenes #4: Coding the Game (Patreon)

Welcome back to Behind the Scenes, where I go in-depth on how each aspect of the game is made. This month I'll be talking about the area of game creation I was least familiar with when starting: actually turning the script and art into a playable VN.

I talked in Behind the Scenes #1 how writers and coders who weren't necessarily visual artists use Daz 3D to make the renders for their games. Similarly, for writers and artists who aren't coders, there's a handy program called Ren'Py that makes creating a visual novel approachable for amateur programmers.

What's Ren'Py?

Ren'Py is a free visual novel engine that simplifies using the coding language Python by having built-in, easy to use commands for displaying images, dialogue, menus, transitions, and more. If you've played many indie VNs, you probably noticed a similarity between menus and controls. That's because we're all using the same program built off the same templates.

If you've ever done basic HTML to, say, spice up your MySpace page back in the day, you can very likely handle Ren'Py.

Getting Started with Ren'Py

There are a ton of tutorials for Ren'Py that expand upon its detailed users manual, some of which I'll link below. Since I'm absolutely not a coding expert, I won't delve into the nitty gritty but will instead give a brief overview of the program and then delve into some tips and tricks I've picked up over the past few years.

The first thing you need to do, of course, is download Ren'Py. Like I mentioned above, it's completely free and comes with a tutorial that goes over the basics. When you're ready to make your own project, all you need to do is click + Create New Project, enter a title, pick a resolution (I use 1920x1080), and then choose your accent colors. 

I followed this tutorial to make my test scene, which you can download from this post. This test was simply a series of images and dialogue, and as such was very simple to put together. This is what the start of the script looks like:

What you're looking at:

• A comment with a hash symbol in front. The hash tells Ren'Py this comment is not part of the game and can be ignored.
• Connor and Marco defined. This sets the letter you type before a line of dialogue, and this letter tells the game what name to show above that dialogue and what color the name should be.
• A start label. Every Ren'Py game begins with this label so that the game jumps here when you click Start on the main menu.
• Dialogue, indicated by the surrounding quotation marks.
• Scene name and dissolve, which tells the engine what image to load and how to transition it in.

Simple, right? If you're a novice like I was, starting by following the tutorial and making a very simple test game is a great way to get your feet wet.

The Coding Program

Ren'Py is the game engine that translates code into a playable game. What you need to create and edit the code files is an external program that's not part of Ren'Py itself. The creator of Ren'Py recommends a program called Editra, which I'm not familiar with but is presumably beginner-friendly. I personally use Visual Studio Code (abbreviated as VSCode), which is used industry-wide.

You'll notice in the screenshot above that all the lines and terms are in different colors. This color-coding is called syntax highlighting and helps you discern what you're looking at. I've had to code without syntax highlighting before where all the text was white, and it was a nightmare; syntax highlighting is a must.

VSCode comes with built-in highlighting for common programming languages, so initially a Ren'Py script will be highlighted following rules for Python. Since Ren'Py is an adaptation of Python and has its own commands, you'll instead want to download a Ren'Py highlighting extension.

Colors can be adjusted if you have a color blindness or just don't like how it looks, but I use the default colors that came with the extension. Here's a portion of code from the full game with highlighting enabled:

Each color tells you at a glance what type of code you're looking at. For instance, the green text is hashed out comments that won't be displayed in the game; a handy way to take notes in the file itself. Purple is basic commands, like telling the game what to show if a choice variable is true and what to show if it's not true. Orange is text that will appear as dialogue, and so on.

Organization

Syntax highlighting helps with parsing code, and using consistent naming conventions for each element helps you keep those elements organized.

Everyone does this differently, so what you use for naming conventions is really what works for you. Some people like to keep labels as short as possible whereas I like to keep words mostly spelled out. This could seem like it extends the time if takes to type the code, but I have a trick for that below.

I use variations of the same naming convention for everything from image file names to sprite expressions to code block labels. Here's a look at some sprites; what you're seeing here is the shortened name I'll use within the code and then the full file destination:

For every sprite that shows a different expression for a character, I name it [character code letter(s)] [expression name] [type of sprite]. For instance, t annoyed d1 will show Tomas's annoyed expression in his day one clothing. The full file name is similarly named, just spelled out longer.

I use the exact same expression names for every character. So mt smiling d2 and l smiling naked semi will show smiling expressions for Matt and Leo respectively, with the bit after the expression specifying what version of that sprite needs to be shown. All day two clothing sprites end in d2 and all naked sprites end in naked [dick state].

Additionally, I label everything section of code with big hashed out label boxes, like this:

And begin specific sections within those labels using hashtags like this:

This way I can easily keep track of what each section of code is, and when looking to reference images or choice variables for a specific character, I can just do a search within the file for # Connor or similar.

No matter what makes sense to you as a naming convention, I think it's important you at least have one. And making use of hashed out comments will save you a lot of headaches later on!

Displaying Images

There are three types of images used in this game: scenes, sprites, and screens. A scene includes both CGs and backgrounds, basically any image that takes up the entire window. A sprite is an image of a figure with a transparent background that can change expressions and positions based on your commands. Screens are overlays that can be created to do all sorts of things.

The absolute simplest way to make a game is what you see in the test game: a series of CGs (scenes) that change each time you use the scene command. Many story games work this way.

Using sprites is also relatively simple thanks to how Ren'Py is built. You first need to define a character. Here are the main characters for the game defined:

Each character has a one- or two-letter label (c for Connor, ar for Asher, etc). What's defined here are the details of what should be shown when each character is referenced. So for instance, if you type mt before a line of dialogue, the game knows it should show that dialogue attributed to Matt, that his name should be a shade of red as designated by the color hex code, and he has a sprite that also starts with the mt label that can change based on simple commands.

In one of the above images, you can see that Connor's sprites are displayed differently. Each one has to be shown separately from his dialogue, and what's being shown is a screen. This is because his sprites are technically a screen overlay, which I did so I could position him exactly where I wanted next to the dialogue box. Screens work a little differently and are defined in a more complicated fashion, like this:

Each screen has a label that can be referenced in the code. Below the label, its attributes are defined, like how the screen should be positioned.

The last line for each image—the connor_expression tag—is something I only learned about a few weeks ago. Essentially it makes screens work like normal sprites in that all you have to do is show the new screen and the previously displayed screen is automatically removed since they use the same tag.

Up until now, I've been manually hiding each screen before showing a new one. I can't tell you the number of times I did not type the correct screen to hide, which led to multiple Connors being overlayed on top of each other. Now I'll never have to worry about that again. If you use screens, don't forget to tag them!

To sum up: Displaying images with dialogue is what Ren'Py was designed for, and so it's very simple to code. Just make sure everything is tagged and labeled correctly—consistent naming conventions save the day here as well.

Menus and Variables: Keeping it Simple

Menus and variables—the correct name for what I often refer to as choice flags—are something I overcomplicated for a long time. 

The coding for menus can become mazelike if you're, say, jumping between characters and then returning to the same menu, which is how some menus worked for the Frat Party Update. I learned from this for the Club Update and did two things differently. 

There are four entry points to the club: arriving solo, staying after hanging out with Asher, or coming with Alex or Isaiah. For Alex and Isaiah, I specifically did not let you go greet other people to avoid the back-and-forth of the frat party menu.

For the other two arrivals, the coding was very simple: A menu pointing to each person, and when that choice is picked, a variable is set so that when you return to the menu the option is no longer present. You either said hi or you didn't; there's no bouncing around.

Variables as a whole can get out of hand if you're doing tons and tons of choices like I am. I have 1000+ variables currently. Many of those are just for menus, setting a flag for a choice having been made to remove it as a menu option. But many are also relationship decisions.

To help with this, I'm consolidating multiple choices into a singular variable to help make writing and coding the upcoming sections of the game easier. It's not always possible to do this, but being able to reference one variable instead of several saves a lot of coding trouble.

In sum, if you're a novice like me, try not to get too ambitious with reactivity at first. The more variables you have and the more menu branches you include, the harder things become to test. Naming conventions and color-coding can only help so much!

Shortkeys

Lastly, I have a trick that greatly speeds up coding time, and that is the use of shortkeys. Think of a court stenographer—you type a few keys and a full statement appears. This means the statement is always spelled correctly and you don't need to spend the time typing it out in full.

I use a program called Breevy, which is free to try and then must be licensed for a low cost. This program allows you to assign a series of keys that will be memorable to you and what should be written when those keys are pressed. This is what some of my abbreviations look like:

This is where the naming conventions comes into play yet again. Let's say I want to show Alex's cocky expression in his day one clothes. All I need to type while coding is type ax (his character code) then `ck and cocky d1 will immediately pop in. Same as if I type gr (Griffin) plus `ck or any other character.

This can be used for absolutely anything you type repeatedly, and you can set any shortkey name you want. I use ` at the start because it's a key I never press otherwise, which prevents ck from changing to cocky d1 if I typed something like back. I know many people use back slashes for the start of a shortkey.

One thing to keep in mind: if you have a code liked `ck, you can't also use `cks for a different item as the phrase for `ck will immediately pop in before you can add the s.

It can take a little bit to memorize all your shortkeys, but it's a huge help. It has streamlined my coding tremendously and has prevented a ton of errors due to typos. I highly recommend it!

Tutorials

Those are the tips I have for now. Like I said up top, there are many tutorials that go further into detail on creating a visual novel using Ren'Py. Here are a few links to get you started:

Ren'Py Quickstart Documentation - The basics of getting started. Begin here! 

Zeil Learnings on YouTube - This channel has a number of easy to follow guides on creating things like image galleries. She also has templates that can be downloaded on Itch.io.  

Visual Novel Design on YouTube - Along with the basics, this channel gives tutorials on some more advanced Ren'Py features.  

Game Developer Training on YouTube - This guy covers a lot of different game development topics, including Daz 3D. He has some Ren'Py beginnger guide playlists that could be helpful.

Image-based main menu tutorial video by qubodupDev - This specific video is what I followed when making my game's main menu. The way he goes over figuring out image positioning is particularly helpful. 

And just in general, in your search engine of choice, type what you need help with + "Ren'Py" and you'll often find threads or web pages with the answers you need, as well as the official Ren'Py documentation for the feature.

I think that's enough coding talk for today. Not necessarily the most interesting of topics, but absolutely necessary to learn about if you want to make a visual novel of your own and are new to programming. Ren'Py makes VN creation accessible to most everyone—if worry of not knowing how to code has held you back, I hope this makes jumping into the world of VN creation feel less daunting!