Watercress Developer Blog #3 - Nolan's Programming Process

Hello, fans. As reddit is quick to point out, I am /u/NintendoToad, but you may call me Toady, Nolan, NintendoToad, or whatever else happens to be easy to type.

Today, I represent our coding department, so to speak. I am one of the coding coordinators, meaning that I am partially responsible for organizing our scripters. As far as how I managed to get onto the team, /u/Anthrozil7 and myself go fairly far back; I simply asked to join the team, and here I am.

The bulk of my work is focused on making work easier for the other scripters. As someone who has worked with Ren'Py before, I ask myself the following questions to start off:

  • Would I have wanted to use this tool in the past?
  • When would I use this now?
  • Is it easy to write this tool without making the game use more of your computer's power?
  • Whose time is saved?
  • Would it be easy to modify this tool later?
  • Does the tool encourage inter-departmental work?


One of the first tools I ever wrote for Watercress Studios was mlib - in essence, it allows us to declare audio files simply by throwing a few lines into a text file. Then, when a scripter uses mlib, Ren'Py will know:

  • What channel to play the audio file in
  • Where the audio file is on the hard drive
  • Whether the file should loop or not
  • Whether the file should be unlocked, if it is a music file
  • Where to put the file in the Music Room (Plays unlocked music)

The best part of this is that our music composers can easily set this up by throwing the following into a text file:

    Natalie's Theme Draft - Mudu

Then, a scripter can just do:


This requires nearly no extra work on the composer's side, while saving our scripters and Ren'Py a great deal of it.

I would have wanted to use this tool in the past, since it would have made loading audio files a far simpler process. I would want to use this at any time audio is being used. This tool only really uses a little bit of extra power only when the game is launched. The scripter's time is saved. This tool has already been modified to allow for looping sound effects. This tool allows scripters and composers to, at least for a certain extent, work together.


It is also my job to pair writers with their scripters. Much of what I've learned from this process is:

  • People tend to get lost.

    Firstly, not everyone has the same skill set. Some people will script faster than others. Secondly, not everyone will understand whatever the hell I happen to be talking about - it is my job to bring them up to speed. Thirdly, some people will (invariably!) forget to communicate - it is my job to make sure that each scripter-writer pair is working smoothly.

  • People don't always know what they want.

    Team members want many things, but they aren't always sure of how to ask for it. For instance, writers didn't know that they wanted multiple characters to be able to talk at the same time until the possibility was mentioned. For this reason, the coding team also acts as backup designers.

  • Sometimes, the wheel "is hidden"

    For many game engines, there are features that are not documented. Long story short, Ren'Py is one of these engines. It is therefore in our best interests to go over the source code.

  • Standards often need to be forced

    One of the saddest things I've ever had to do was write the first draft of a style guide. Unfortunately, "good style" is an opinion, and easy to argue over. However, enforcing a style guide lets us keep track of each other's work, and remember how they are to be used.

    (Note, style basically has to do with how we "comment" our work - in other words, when we write a tool, we can leave little notes within that tool. Failing to do so, or doing so badly, often results in confusion later on.)


That's all from me for now. Feel free to message me individual questions, if you so desire.