So for the past year or so I've been (on and off, of course) working on a new roguelike. It's not my first foray into designing one: I've attempted to make them in the form of books (semi-successful: It's a good adventure-riddle but not roguelike beyond having a randomized labyrinth layout), board games (close. But better as a traditional board game co-op experience), text-adventure video games (that's more like it - but alas, I didn't do the coding) and low-resolution retro-games (not the roguest of roguelikes but also close - also a collaborative effort with my friend Niels). Now this time I've done everything myself, using the only platform I can do some coding in - Twine. Twine 1, that is.
Can one make a roguelike in Twine? With some limitations: Yes. I did it. It's pretty much finished, all I need to do is publish it on my Itch-site, which I plan on doing this weekend. Let's do a little post-mortem on the project.
Making a roguelike in Twine
Twine wasn't made for creating roguelikes, obviously. The main strength of the platform is that a layman such as myself, more interested in writing than in coding, can make a functioning piece of interactive fiction without much foreknowledge. Starting from relatively humble beginnings I learned to use more and more of the coding language features until I was able to make first a text-based survival-horror-game and then an hommage to Resident Evil. But creating my roguelike was a totall different beast. It started with a random maze, then I added parts of the combat- and inventory-system from Zombie Mansion, then I made a system for placing random monsters, loot and room features.
Technically, you do the same floor over and over again: There are only 25 'rooms', wich get different walls/passages, features, treasure-items and monsters every time you descend to the next floor. The rules for filling the rooms change when you go deeper though - as do the stats of your character when you level up. The whole thing has a high level of complexity. Here are some stats of the Twine project:
- 160 Passages
- 424 Variables
- 21 Types of Monster
- 7 Character Classes
- 50+ Types of Item
- 12 Spells
- 6 Potions
- 25 Floors total
- 5 Curated floors with boss fights
- 4 Floors where there is a trader to do trade with
In the editor, the whole thing looks like this:
The character classes (on the left) all actually play very differently: You have fighty characters like the Squire, who just stabs enemys with his spear. You have casters like the Apprentice, who can learn spells from scrolls to use them many times. You have utility-classes like the Scholar who will fill her journal with lore about the dungeon when you go deeper - and can later scrounge for scrolls (which kind of makes her a caster class as well). Many items have multiple uses: You can use a thighbone you find for combat or sacrifice it at a firepit for a health-boon. Potions can be drank, hurled at enemies or poured onto things. The seven classes each have a specialty:
- Squire: Offense in combat
- Tribal: Defense in combat
- Apprentice: Magical spells
- Alchaemist: Potions
- Scholar: Lore and nerdery and some spells
- Sacrifice: None, this is the difficult class
- Huntsman: Crafting and cooking
The project started out as a generic dungeon in a medieval world. When I made more characters and enemies, the world started taking a more unique shape. The Swine Pit, the dungeon of the game, became a hellish hole in the ground filled with demon-posessed swine-creatures and their retainers. My fandom of Darkest Dungeon definetly shows in a lot of the descriptions.
I'm also quite proud that the majority of monsters have special moves that go beyond direct attacks: Some may beat your weapon out of your hands, some can destroy armour, some displace themselves, steal your mana or HP or regenerate or steal food from your pack. Same goes for bosses: At the very least they have special attacks and two of the boss fights can be outright avoided if you have the right tactics or items. Speaking of items: Some of them are incredibly powerful and once you master the game these are the ones you want to keep for specific situations such as boss fights. Even the final boss can be two-shotted with the right spell.
What doesn't work?
Twine is, as I said, not made for making a game like this. Besides the total lack of a visualized map (draw your own - the game does provide grid-coordinates in every room), monsters are mostly immobile. There are some exceptions:
- The second boss enemy moves about in a specific area, a trick that I learned making Zombie Mansion. The process is too complex and unreliable to be used at scale with regular enemies though - especially when considering that the boss level is curated and walls and passages are always the same, unlike on regular floors that are totally randomized.
- The enemy types of Madman and Infected Madman sometimes just "run off into the darkness". I stayed vague on purpose: The game doesn't know how to respect walls in this instance and just places the creature and its HP in a random different room. Works for a creature that is insane and incoherent, but not for other enemies. It can also lower the total number of enemies on the floor because it will overwrite the monster in its target room - so I had to use this ability sparingly.
- There are some mobile monsters on the floor of the third boss but they are rather buggy and sometimes do not move at all.
Twine is also not the best for testing your software. I did make a test-character who can jump to the next level at will and has all possible items in his inventory but even then it's a chore to test, say the final boss fight on floor 25 multiple times. That means that the later stages tend to have more issues with them. As I wanted the boss fights to be special, it was difficult to do QA there.
You can't go back up to a floor you've finished. This is because the floors are randomized during transition. Story-wise I made it so that you actually jump down into the darkness every time and there is no way to climb back up. That takes away some of the tactical options a roguelike might have, such as going back to a trader. But it can't be helped.
There is no way to save the game. I am aware that other versions of Twine have features for that but to be honest, I can't be bothered to learn another programming language after putting all that work into regular vanilla Twine 1. I'm still angry with the makers of Twine 2 going "well, we made it and most of the codes work like programming language X so whatever go figure it out" when the target audience for Twinery is people who specifically cannot code. I got my start with a blog post by Anna Enthropy and learned from there but please, people, don't assume that you make this tool for other coders.
I have another Twine game in the works - a sequel to Zombie Mansion. As the platform is what I've become proficient with, I will likely keep using it as a creative outlet. Also, I'll keep making (more professionally coded) games with Niels. We do totally need an artist though - our pixel art doesn't cut it in the long run.
