Why this action game dev made a visual novel

I just add these pictures for prettyness

I got into gaming because of Sonic the Hedgehog for the Sega Megadrive and Gamegear, I love myself a fast-paced arcade racing game, with Trackmania, Extreme G and WipEout as some of my favourites and even in modern gaming I can have my adrenaline fix whilst racing in a GTA-like game or any faux retro arcade game. Imagine my surprise when I was staring at my own design for a scripting engine and thinking: "You know what? I should make a visual novel!"

What brought me to this wild conclusion? Let's back up a little. Even though I finished a computer sciences degree at university, I make my games in Unity. I could make my own game engine, but why re-do something that has been done better by others before? With Unity as an engine base, I can make even more awesome games than if I had to build the graphics part myself. Unity is very suitable for 3D action games and that's why it is my engine of choice. With standard assets and scripts you can build a prototype within the hour.

But, as with any existing engine, Unity can not be tailoring to every possible kind of game you might want to make with it. What I was missing was a decent way of scripting. Sure, Unity has a great object-oriented scripting system, which is great when you want to handle many pieces in a game environment, but a story script does not work that way. Many things working at a time makes a story confusing. What you want is something more monolithic, guiding the program and player in a certain direction. What you want is something called a structural scripting language, something like BASIC.

More pretty pictures!

"Whaaaat?! Surely you jest, claiming BASIC is better than C-sharp!" You might be right in most cases, but story-wise it's a different matter. Object oriented scripts have other problems when it comes to writing stories. First, if you slip up in its syntax, your script won't compile. This is devastating for your flow of writing! A structural language, on the other hand, has more room for errors, which benefits the writing of the story. Second, if you want to make your story even slightly non-linear, you want to jump around between lines. Sure, there is a 'goto' command in Unity, but suffice to say you'll go to coder-hell if you use the C command we shall not speak of.

Fortunately, Unity has an asset store that can get you any kind of asset, script or functionality you desire. Unfortunately, none of them felt right. There's a lua framework, that mostly focuses on moddability of games and there are several visual novel toolkits that do little else. However, none give me any tools to script events in a game field, which, as an action-fan, kind of saddens me. The final level on the spaceship in Sonic 2 would be less impressive if you just teleported there, the scenes in Tomb Raider with Miss Natla made the spelunking feel extra mysterious and anyone who played Final Fantasy 6 (or 3, maybe not an action title) will remember how awesome it was to see that asshole Kefka be blown apart bit by bit in the end. Also, yes, I am excluding over-scripted games, so I can make my point.

So, with all the existing systems being unsatisfactory, I set out to make my own scripting system. These were the requirements I had for the system:

• Portability to every platform Unity provides, so everything had to be built from scratch
• Modularity, it should be easy to expand and easy to use for multiple purposes
• Easy localization for text and speech
• Communication with the playing field, start animations etc. at given times in the script
• GUI handling, let the new script handle menus, because Unity's GUI handling is so atrocious, it needs a complete post of its own.

I call it: the Story Engine.

What could all these pretty pictures be for?

If you've done it once, building a scripting system is pretty easy, provided you consistently keep using modules and functions the way they are supposed to. To put it in proper English: I blatantly copied the insides of a computer: I made a C script to store values (memory), a C script to execute commands (processor), a C script to handle the GUI (monitor, mouse and keyboard), a C script to hold and interpret my custom scripts (HDD?) and connected them withing unity like you would with a real PC. Add to this that the scripting language I botched together was based on assembly and it's a surprise IBM did not come knocking on my door. Luckily, this design is older than computers have been around, so I was in the clear.

The scripting language was the main focus for the system. A script for the system consists of a CSV or "Comma Separated Value" file. For easy parsing, I interchanged the commas with whatever this vertical line character is called: "|". That way I did not have to worry about quotes and commas in text. Another benefit of CSV files is that you can edit them in Excel or any other alternative.

Basic design of the system

The first row in the CSV file tells the interpreter what every cell in every column does.The top line of a typical script would be:

label

cmd

arg0

arg1

arg2

arg3

txt_en

txt_es

txt_fr

spk_en

Every row in the Excel sheet holds 1 command. I won't go into too much detail, but these are the basics:

• There are several possible commands possible for the cmd column. All commands are eventually handled by the 'processor' module.
• Arguments for those commands can be put in the arg0-arg3 columns, if you want to use a command with more than 4 arguments, just add a column in Excel
• The label column depicts labels for the goto and gosub commands to jump to.
• The txt_xx column sets the text for any GUI element, like buttons, story-text or subtitles. A locale command can switch the txt column used for text with the language code used for xx.
• spk_xx, for when spoken text is needed, holds the name of a sound file. Also switchable with the locale command. In this case, the budget only allowed 1 spoken language :(.

A little girl with explosives.

It only took me 2 days to design, implement the bare basics and have the first prototype running. However, a prototype is barely the beginning. If I wanted to use it, I needed to test it with something bigger and that's where the idea for a visual novel sneaked into my mind.

I have not been kind to the dating sim, the sibling of the visual novel, comparing it to a screwdriver to my eye, but I have always had a certain respect for the visual novel format in a story-telling kind of way. Text based stories easily break the "show, don't tell" rule, while on the other hand visual stories need to have everything shown, even dull conversations, or it breaks immersion. A visual novel can show a lot without description, while still leaving room for the imagination of the reader.

Also, a visual novel is perfect to test your scripting system with. Even though I did not know much about visual novels, I was happy to dive into that world and I met a lot of nice people along the way. If those people are reading this: you know who you are, you're awesome!

So, I made the first prototype of a Chapter in 1 day (12 hours in 1 day, so technically one and a half work day), a proof of concept demo with actual artists in a month (released as a demo much later) and today, as of writing, we release the full product. Introducing:

The logo of Detective Hank and the Golden Sneeze

Detective Hank and the Golden Sneeze is an interactive whodunnit visual novel with a different culprit on each playthrough. It uses almost all capabilities of my scripting system. Localization and voice acting are pending. As for now, I will keep on polishing the engine, as after release a lot of people are bound to bump into fringe-bugs.

It's getting crowded in here.

The fun part is: everything can be added in a matter of seconds (if you don't count actually making the extra content) and the code I wrote for this system can also be used for other purposes. Every module is interchangeable due to use of inheritance in C-sharp and can be linked to different parts of a game field. In other words: the code that moves the pictures on screen can later be expanded to move 3D models through a field or do all kinds of things.

Building this visual novel was a fantastic test for my scripting system. I found out a lot of parts did not work as I intended them to and, because the system did not need much expansion, the bugs were easy to isolate and fix. As I wanted more functionality for the novel, I got to experiment with inheritance and see if expansion of the base-code worked. And it did!

For the sake of just making a visual novel why didn't I just go with Ren.py or TyranoBuilder? I could have, but the pieces of code I hold now are so modular, I might just use them for every game I am going to make for the next couple of years. It was fun to build a visual novel to test both my engine coding and story writing skills and it definitely made me a better game developer. That's why this action-loving dev made a visual novel... and it might not be his last.

As of writing, Detective Hank and the Golden Sneeze is still awaiting the Steam Greenlight process, but it is already available on itch.io over here. If you want to try it out first, we have a demo available here.