What are best practices when designing and programming a VN?

[Happiness+]

I will be releasing my visual novel this summer. It will be my first one. While, I am doing that I wanna learn what are some best practices when it comes to visual novel development. Thanks in advance.

EDIT: In am looking for prerelease best practices and handling post release. 

Edited May 18, 2018 by Happiness+
Clarity on position

[Narcosis]

Visual novel development (and game development in general) is a very broad topic, incorporating many different trades it's hardly possible to cover everything in a bunch of simple answers.

What are you interested in the most? Publishing and game release? Product management? Post-production? If you're interested in plain development, there are already topics around here that cover a wide variety of different subjects. Look in the appropriate boards.

[tymmur]

1 hour ago, Palas said:

the most important thing overall, I think, both for design and for programming, is to have the structure of your game displayed in a visual format you can understand.

This is the essence of what I would say. Writing on the computer is no good and while pen and paper is better for something like this, you need to go big and make an overview, something like this:

Spoiler

Place a pin to mark where the story starts. Next place one for each branching point and each ending. Next you put strings on the pins to indicate the flow of the story and to visualize how the branching points are connected. Next you take a small piece of paper, write the title of an event and then you pin it on/next to a string. Repeat with all the events. You will end up with a visual overview of distribution of events and order of events. As you write each scene in more detail, you will likely figure out some events needs to happen in a different order and you swap them as needed. Events can be a scene or just some information like "protagonist remembers having met heroine years ago". Basically you add a piece of paper for anything where order will affect how other events are written.

Back to the future had the script and hence the timeline made this way. Naturally without the branching points, but the order of events were planned like this. Some scenes required Marty to have experience with something and then that something was written on another paper and it had to go into the story earlier. A proper overview for planning is required for something like that to work well.

 

As for programming, I would say make a file for each event and give them proper names. This will help if you want to swap something at some point or insert a new scene between two existing scenes. Since the story has to match the plan, the files/programming should too or you will lose the overview.

[tymmur]

This time I will write about my main field of expertise: programming. It's entirely different from the previous post (planning the story) and as such justifies splitting the two topics into two posts. This post assumes using Ren'Py, though it should be doable with most or all engines. I just had to make a choice if I write specific keywords.

First of all, don't be afraid of adding more files. Ideally you should use a one file, one task approach. Also name the files in a way that allows you to find them easily and use a folder layout if possible. You need to split between setup, file access, flow control, story etc.

Setup

Make a file where you list backgrounds and their filepath. Add spaces to make the paths align on top of each other. That way it will be easy to spot typos in the paths. Do the same for music, possibly in the same file.

Next up is characters. Make a list of characters (possibly in a new file) and assign names, color etc, again with spaces and an aligned layout. Add comments at the end of each line to write the color in human readable text (as in not the color value numbers). Also list the characters to set sprites for each. Possibly do it in one file for each character or in one file, but then sort them alphabetically. You should sort them in the same order as the first list, but it's a good idea to keep the names and colors as a list to get an overview.

Make a file with sound effects using the same approach.

If you do this right, you have some files, which list all the media files you use. No other text files access media files and changing the media files can be done from the setup files only. Also the setup doesn't contain much other data than shortcuts to the media files.

Story

For each scene, make one file. If done right, it's close to one file for each paper on the board, but in some cases one paper-one file is not the best option. Start with a label, name it the same as the file and name the file something fitting. End the file with a return. Write a story where it's just the story. No jumps, questions or anything like that. All the media file usage comes from the setup files and nothing is called directly.

Each file should set the scene, like setting music and background at the top and clean up as in removing all sprites at the end as well as canceling all audio and leave the screen black.

Asking questions to the player and branching accordingly contains some exceptions to those rules. More about that later.

Flow control

Make one file containing flow control logic. It exploits the difference between jump and call. Simply put, call will go to a label and when it encounters a return, it will go back to the line it called from and continue from there. Jump will not go back, meaning if you call and then jump, the return will go all the way back to the call.

Now you should add a call to each label in the order you want the labels to be called. Since each event file ends with a return, the story will return to the flow control and move on to the next line. This way the order of events is purely controlled by one file and is not mixed into the story.

Questions/branching/flags

In case a question is asked, return just before asking it. Next you ask in the flow control and branch according to the answer.

You need to make labels in flow control and when you get the answer from a question, you jump to a label in flow control and continue from there. Since you aren't going back, jump should be used and not call. Each such labels will then call an event and since the screen should not be black while the question is asked, events ending with a question and those starting with one should skip cleaning up and setting up and just continue. This is the exception to the cleanup rule.

If you want to use flags, you set the flag in flow control and you test for flag conditions when figuring out which event label to call, which is also done in flow control. This way you have all flags and actions based on flags placed in the same file.

Testing

When writing an event (story), just add call scene after start and testing it will be quick and easy. This will allow testing text, sprites etc without having to consider flow of the story. It's a huge timesaver to not have to fast forward to the scene you work on for each change you need to test. Naturally you should test the VN in the final form before publishing, but you will likely do a lot of small tests multiple times a day while working on it to catch typos and similar as early as possible.

Final words

If you follow this guide, you will end up with a layout where each file has a purpose and it's easy to tell the parts apart. It helps a lot of you want to swap the order of events as this can be done without touching the story itself. Likewise you can't break the flow control by accident by changing the events and changing which media files to use will not affect either. In other words it's a design, which heavily reduce the risk of bugs and it also reduce the need for testing after making changes.

Now put those two posts together and make sure you have at least one paper for each event file. However in some cases it might make sense to merge multiple papers into one event file. It's something to consider in each case and I can't tell you in general if it's right or wrong to do it in your specific scene. It's one of those things you have to figure out on your own.

[Happiness+]

Thanks for all the info so far guys, I will be coding in the Ren’Py engine. I have done some encapsulation, but not enough to what most people would expect. It will be linear VN, a kinetic novel. Less than an hour readtime. Like Indie of Indie, right here. I apologize for the vagueness of the project, but when I need to know most is how to release successfully, and handling post-release.