HELLO FELLOW SICKOS IN THE CHAT. THIS IS YOUR ESTEEMED WRITER, THE HOG HOLE, GRACIOUSLY AND GENEROUSLY SHARING INFINITE WISDOM WITH YOU ON HOW YOU TOO CAN CREATE AN ABSOLUTE BANGER OF A GAME LIKE MYSELF AND MY AMAZING PARTNER IN CRIME, THE WONDERFUL DR. SEX. I AM ALSO JOINED BY THE WONDERFUL ILLUMINESCE, MABBEES AND RUNA WINTERS, THREE AMAZING GAME DEVELOPERS WHO HAVE ASSISTED ME IN THEIR AREAS OF EXPERTISE SUCH THAT WE MAY IMPART OUR COMBINED KNOWLEDGE UPON YOU ALL.

I am a merciful person and I will not write the post in all caps, but please imagine that you are hearing this post-mortem in a lecture hall where the professor is speaking in their loudest, most passionate voice with a board full of diagrams like so:

What do we even call this type of game?

A masterpiece, of course.

From a genre perspective, one can easily classify it as Interactive Fiction (abbreviated IF) as it is primarily conveyed through text with a few branching choices, as well as a few supplementary images. IF is quite a broad genre however, with subcategories including Hypertext, Choice-based, Paser-based, Visual Novel, and more which specify how interactivity is presented to the player and how one may control the direction of the story. I suppose then that one might call STFU a Choice-based IF, but is there a term for a style of IF or game that emulates the appearance of a device or software, often in the context of sending or receiving messages?

Allow me to introduce to you the Interface Drama, a relatively new genre term coined by the good developers of Terranova, illuminesce and mabbees. In a talk at Nerd Nite Tokyo 2022, they describe Interface Dramas as "an emerging genre of game which uses software and app interfaces to tell immersive stories." They additionally identify four common traits of Interface Dramas in their talk, which illustrates the unique way these games differ from other story-based games. You can find a masterlist of this style of games here.

Cool, I read their blog post(s)! Now how do I make an Interface Drama?

There are many such ways! Some engines or frameworks are easier than others while a few of the complex options allow for things like multiple simultaneous conversations in separate channels or real time messages sent at certain times of the day.

Twine (1 & 2)

Twine is a pretty common IF engine these days. Originally conceptualized as a branching story plotting tool, the community found that they liked using the output itself for games and created Story Formats that would pack up their files as attractive html files. These could then be embedded and played on the web or any device that could open up offline webpages.

Twine 1 & 2 largely serve the same purpose, though there are Story Formats and certain functions that only work in Twine 1. The community has recreated the majority of the popular Story Formats in Twine 2 however, and a trove of resources exist for both versions of the engine.

Trialogue

We made STFU in Twine 2, making use of the Trialogue Story Format by Philo van Kemenade, which is based off of Paloma (which itself is based on Snowman). Trialogue was specifically styled to emulate the user interface of a messenger app right out of the box, and with Twine's easy-to-read syntax, it's pretty simple to jump in and start writing your game!

Pros:

• Uses standard Twine syntax
• Default appearance looks great
• Customization via CSS is simple to apply
• Can handle images inside of messages

Cons:

• Every text message is its own passage, leading to potentially large, unwieldy .twee files if you don't organize it properly
• The helper function <%story.showDelayed("idOrName");%> only delays the appearance of the next passage based on its length, which can lead to rapid-fire messages that can be difficult to keep up with (there is probably a way to create another function which allows for defined delay times but don't ask me how to do that)
• For some inexplicable reason, Trialogue did not want to link to a passage named "0065" at all. I ended up having to name that passage "gay" to have the game flow continue

Conclusion: Trialogue was, initially, attractive to us because it did exactly what we needed it to, and I found that the easiest way to write the story was to put it into a spreadsheet with columns dedicated to the passage name, speaker tag, passage text, helper function directing it to the next passage, and any potential choice branches. However, when it came time to import the story into Twine, the quirk with the singular passage per text message and the inability to control the delay time made it clear that Trialogue was extremely limited. I like to think that the latter contributed to the sheer chaos of the game though. I just wish Twine 2 had a way to bulk rename passages based on a naming scheme.

TL;DR: Easy to jump into, potentially tedious to implement based on the length of your game.

Botscripten

Botscripten is something I found while researching frameworks, and it's based on the above Trialogue. I've not used it but it claims to be ideal for turning your story into an executable file. I figure it's worth a mention if only for posterity's sake.

Ren'Py

Ren'Py is perhaps one of the most commonly used game engines dedicated to creating Visual Novels in the West. Designed to handle large quantities of text, it comes pre-loaded with expected quality-of-life features that most players expect to have in a VN, such as text history, auto-forward, a comprehensive save file system, and more that works out of the box on the developer end. As it's based on a modified version of Python/PyGame that already places emphasis on easy-to-read syntax, many beginning developers find it simple to pick up within a day or so. GUI customization takes a bit of intermediate familiarity with its Screen Language, but similar to Twine's community, many developers have released resources and tutorials to make it easier to use. With advanced knowledge, you can even replicate enough functions to emulate an entire OS! As an added bonus, you can literally click a few buttons to compile your game to run on Windows, Macintosh, Linux, Android, and even iOS with some wrestling.

There are tons of Ren'Py frameworks that have been released to imitate a messenger app that this section alone could be an entire blog post in of itself, so I'm only listing my favorite ones.

Nighten's Simple Messaging System or Yet Another Phone Framework

Nighten's messaging systems alter the built-in NVL (or Novel) format in Ren'Py, which refers to a way of displaying multiple text passages on the screen at a single time; this differs from the default ADV (or Adventure) format that displays a single textbox on the screen that most people associate with VNs these days.

Pros:

• Uses standard Ren'Py syntax for displaying messages
• Quick to work in
• Branches are easy to keep track of and can be kept in a single .rpy file, or spread across multiple ones, if desired
• Default appearance looks great
• Can handle images inside of messages
• Can be customized to emulate a desktop messaging app as well
• Easy to swap default assets (such as sound effects) for custom ones

Cons:

• Customizing the padding, width, or other sizing elements of the framework for your needs can become messy
• Can only hold a single conversation's worth of dialogue at a time, meaning that you'll need to clear the NVL log of messages if you want to show a conversation with a different set of characters
• You'll have to customize the GUI for the rest of the engine unless you specifically remove those screens

Conclusion: Ren'Py is so easy to work in that you could write directly in the .rpy files if you wanted to, but customizing Nighten's messaging systems takes a little more effort than Trialogue. It could be a more attractive option if you plan to include more than just a messaging conversation in your story-based game, or if it's significantly longer to warrant players saving at certain points. Of the two, I like the Yet Another Phone version.

TL;DR: Easy to jump into, needs more time to customize. Potentially better for longer games.

Chat Program

If you were wondering why there's been a sudden uptick in indie Interface Drama games in recent years, you can thank robobarbie for releasing the framework they used to create Blooming Panic. Simply called the Chat Program, this Ren'Py framework maintained by robobarbie and WindChimesGames is extremely comprehensive, customizable, and complex. That of course means that it's got a potentially higher learning curve.

Pros:

• Uses Ren'Py syntax for displaying messages with some extra defined functions if desired
• Allows for multiple conversation channels each with their own message history
• Allows for notifications in tabbed out channels
• Able to switch from the chat screen to ADV or NVL

Cons:

• Heavily relies on complex screen language to customize
• If you look at it funny it might explode

Conclusion: The Chat Program is much more advanced than Nighten's NVL solution, which allows it to do that much more. That said, be extremely careful when trying to poke at the framework holding the functions together unless you're very confident in what you're doing. To my knowledge, the Chat Program is being actively maintained and has become easier to use with time.

TL;DR: More advanced, more capable. Poke the guts with care. Great for longer, very complex games.

Web Development

Wow, the internet! Chances are that you're using a browser to read this, unless someone figured out how to put this post on their ebook reader or printed it out. At which point I'm a little intimidated.

When CJ and mabbees built Terranova, they used good ol' web programming. If you decide to build an interface drama using web programming too, you have a few options:

1. Hack a pre-existing system.
2. Download a template in the form of a code repository and make it your own.
3. Build it from scratch.

Anything can be an interface drama if you want it to be. You can start a LiveJournal, Tumblr, or any blog that takes images and links and write as a person in your story.

The interface drama Neurocracy uses a wiki called Omnipedia for critical parts of gameplay. There’s code you can download to build your own wiki to make an interface drama like this.

You could instead opt to build something from scratch, or use a template or UI component library to get started quickly. It's an overstatement to say building interfaces on the web is "easy", but it is at least a well-worn path. You can find tutorials, examples and Q&A forums online for how to build an interface in HTML, CSS and Javascript. Here’s some cool components for old-school Windows interfaces like Terrnaova.

• https://jdan.github.io/98.css/ (CSS)
• https://khang-nd.github.io/7.css/ (CSS)
• https://github.com/TeamChatt/window-manager (Typescript, React) - mabbees built this one specifically for Terranova

If you decide to use a framework (e.g. Vue, React, etc), one nice feature that most of them offer is "hot-reloading". This is where you run a server locally (on your own computer) that will update a preview of your site when you save changes to the source code. This is a major productivity booster and helps you code visually! 

One downside of using a framework is you take on extra complexity. Typically, the code you write isn't what gets run, because there's an extra "build" step in between. Debugging what went wrong with a build is no fun, and gets in the way of actually making your game.

Another concern is figuring out how to put the drama into your interface. That is – how will you author the story? Saying authoring the story is "hard" might not be an overstatement, but it's definitely NOT a well-worn path. It's hard because it's ambiguous. RenPy and Twine have already made decisions (and therefore limitations) around what a story script is. But if you’re building your own game without those tools, you have to make these decisions and define the limitations for yourself.

Making sure you have a smooth workflow is important, since writing the story is where you’ll likely spend most of your time on the game’s development. For Terranova, mabbees wrote a custom parser and runtime, so that writing chat scripts was easy and didn't require a lot of clumsy markup. CJ and mabbees also made use of the (now defunct) teletype plugin for Atom so they could collaborate in realtime on writing! 

In general, mabbees does not recommend writing your own parser, unless writing parsers is something you're into and you're confident in your skills. An alternative is to use an existing language like Ink, which can export JSON files that you can use in your project.

Pros:

• Good documentation and resources. If you can’t figure out something, Substack has a lot of Q&A’s you can look into and Codepen.io has some good examples to pull from
• You’ll find more people to help you. When we ran into an issue implementing something, we sent the GitHub repository owner a message. It helped us both connect to other edge cases and troubleshoot with the developer
• You can use component toolkits to save a lot of time
• Your game can be flexible – define your own limitations

Cons

• Depending on a person’s browser, some effects may run or not. Safari, Firefox, and Chrome, Edge and Opera all use similar, but slightly different ways of reading a webpage. Sometimes you’ll make something cool but it looks janky or doesn’t run at all in one browser (usually Safari…)
• If you’re not self-hosted, (ie using option 1) you’ll lose your game if the service shuts down. In the case of belbeeno’s Tachygram, it went down when cohost went down because it was initially built by linking cohost’s blog pages
• Using existing design systems and component toolkits can tend to make your game look very “cookie cutter” if you don’t spend the time to customize the
• You might need to build more of the “infrastructure” of your game (like script parsers) yourself

Conclusion: Browsers are pretty capable at doing a lot of things if you know how to work with JavaScript, CSS, HTML5, and whatever other languages interface with it these days. They are very well-supported and good to get started if you don’t want the constraints of Twine and Ren’Py but are intimidated by Unity/Godot/Unreal. Make sure to consider how you’ll archive your game in case it goes offline.

TL;DR: A well-traveled path for non-game programmers that takes a bit of wrangling to turn into a game. There's plenty of resources, but beware of forced obsolescence by browser and tech updates.

Unity

Everyone and their mom knows Unity, and also hopefully understands why I cannot in good conscience recommend delving into the engine at this point unless you are already familiar with it. It's still the industry standard you'll probably learn in some overpriced classroom, so I'd be remiss not to mention it.

Naninovel

Unity, being a general use game engine that can accomplish most anything if you're a true masochist, has a plethora of plugins and extensions that supposedly help handle text such as Fungus or Ink, but Naninovel is well-known in the Visual Novel development scene as it also comes pre-packaged with a few commonly-expected features such as text history, auto-forward, a comprehensive save file system just like Ren'Py does. I am not a personal fan of the spacebar being used to hide the textbox however, but a competent Unity programmer should be able to remap the button scheme to change it.

I can't really make a full list of pros and cons for Unity and Naninovel like I did for the other engines because I am not a competent Unity programmer. I think it's too complex and only worth paying into the system if you plan to mix other gameplay elements with your story-based game, or potentially bring your game to consoles without the aid of a third party publisher. You're gonna have to figure out how to wrangle Naninovel to work as an Interface Drama yourself because all the help forums assume you know what you're doing and just need a little nudge in the right direction.

Unreal

Listen, I know even less about how Unreal Engine works under the hood. I know it can handle a lot of simultaneous independent entities/NPC behavior, but that's about the end of my knowledge. It's also kind of overkill if you're only using Unreal to make a plain story-based game without some kind of overworld exploration or real-time mechanics, but you do you.

Visual Novel Machinery

Visual Novel Machinery is an Unreal Engine plugin made for Creators to allow them to focus on developing amazing stories without the need of coding.

I am definitely not the person to ask about Unreal Engine. It's just about as powerful as Unity, which also means its capabilities and barrier to entry is that much higher. Do these programmers understand that yes, I do need to be coddled and have my hand held while learning their language?

Godot

Godot Engine has become more popular in recent months thanks to the continuous implosion of Unity. Like Unity and Unreal, it's a general purpose game engine capable of creating any time of game, though at the moment it's better at handling 2D rendering. While it's a younger engine in active development, the main attraction of Godot Engine is that fact that it's open source and can be contributed to or forked by anyone at any time.

Godot also has robust UI tools and its 3D capabilities make it easier to do 3D scene staging, even if you aren't using 3D models or environments for your game. It's also got some very strong animation tools that allow people with less programming knowledge to use keyframes or tweens to create slick animations and effects that might take a lot more work or knowledge in other engines.

Dialogic

Of the narrative game plugins I'm aware of, Dialogic is the most fully-featured visual novel-type plugin that is tested by a growing community. It's also got a good amount of documentation to get you going.

Pros:

• Engine comes with neat built-in text effects
• 3D capabilities may be a plus for staging & environments, even in 2D games
• Plugin is in active development
• UI development is easy and adaptable
• Robust support for animations, including 2D skeletal animations

Cons:

• Definitely requires some programming knowledge to customize
• NVL Mode not included out of the box with Dialogic
• Growing community of developers, but still in early stages and far fewer assets available than some engines
• You'll have to decide if you let Dialogic handle Visuals, Audio, etc. and the less you leave to Dialogic, the more you have to code yourself.

Conclusion: If you want to incorporate other gameplay mechanics and aren't locked into the Unity or Unreal Engine ecosystem, Godot Engine is definitely worth a look. And if your game happens to be a banger, you don't have to split your revenue with any company! Well, besides storefront fees.

TL;DR: Potentially more powerful than Twine or Ren'Py, but you definitely need to learn how to program.

Wow, that's a lot of options! Which engine do I use?

Some diehard programmers will try very hard to convince you to use their favorite engine but I am a simple writer, therefore I will give you a simple answer: use the engine you're most familiar with. I have my biases and know that I have experience with certain programs, which will make me think something might be easier than it could be for someone else, so if you already know how to wrestle a language or engine into doing what you want it to do, I'm not going to try and convince you.

That said, if you're absolutely new to programming and get nervous around lines of code, I sincerely do believe that Twine is the most accessible option for the average layperson.

So I found the engine I want to use. Now how do I write a banger story with such authentic characters?

That is an excellent question and I will tell you my greatest secret to character-based storytelling: none of them are cis.

It's a known scientific fact that transgender people are extremely intelligent, charming, and sexy, so there's no need to focus on writing stories about anyone else. It's unnecessary and quite frankly a waste of your time to write about a majority cisgender group. Sources: dude trust me.

A doctor’s note from Dr. Sex

It was an honor getting to work with the HOG HOLE for my first LITHOBREAKERS jam. I created the icons and artwork, designing the virtual appearances of these characters based on their names and bursts of personality in their witty texts. I wanted to embody the chaos of participating in a very online group DM - but since the members all know each other in real life, they still have a certain level of authenticity to their profile pictures.

In a time where it’s difficult to be trans and almost all media about being trans is about how difficult it is to be trans, it was a great change of pace to be working on this project where there’s just unbridled trans fun. Valentino is a plus-size Latino trans man like myself, and I really enjoyed my part of bringing him and his antics to life.

Special thanks again to the esteemed HOG HOLE who suffered with the coding in order to expand the icons to a larger resolution, so they can be enjoyed for your viewing pleasure. Diagnosis: We need more trans fun! I’m prescribing the patient with STFU.