Building a text-based game

Exploring an old genre for new purposes

June 20, 2023 (updated May 1, 2024) · Felipe Vogel ·

UPDATE: To see the beginnings of the actual project that I envision here, see my follow-up post Building a text-based game in Ruby, part 1.

I’ve been mulling over ideas for my next hobby project, now that I’m almost done making my CSV reading log parser.

I’ve decided on (drumroll…) a text-based game!

What, seriously? Isn’t that the quintessential newbie project for first-time coders?

That’s what the critical voice in my head keeps saying. So in this post I’ll dive into the rich and intriguing world of text-based games to convince myself that making one is not, in fact, a dumb idea. In an appendix below I’ve more directly answered my inner critic and its suggestions of more “serious” projects.

What are text-based games?

For the sake of simplicity, under this one heading of “text-based games” I’m lumping together various overlapping sub-genres, including these:

Trying out the sub-genres

Until recently, I’d only ever tried a few IF titles, so now I’m making a renewed effort to explore IF and appreciate it as much as I can. Here are my impressions, along with some examples.

Parser-based IF feels more game-like on the whole, with its clear concept of spaces to be explored. It can be hard for a newcomer to learn, but that’s not a problem if a good tutorial is included (Blue Lacuna, The Dreamhold, Counterfeit Monkey) or if the commands are very intuitive based on context (FeedVid Live).

Hypertext and choice-based IF have a simpler UI (just links) but are extremely varied thematically, covering the spectrum from popular fiction (A Tale of Crowns) to avant-garde (many of Porpentine’s games), from comical (You Will Select a Decision) to touching Digital: A Love Story to heartbreaking (Hana Feels).

MUDs are… hard to get into. They seem to have evolved less over the decades than the other sub-genres I’m exploring. Which is great if you got into MUDs in the 1980s, but to me (a tired 30-something new parent in the 2020s) it’s too much of a time commitment to learn how to enjoy MUDs. So I’ll leave it at that.

Procedural text-based games are easier fun, being more like graphical games than IF is, and (classic roguelikes aside) being simpler than MUDs. Common settings include medieval fantasy (most roguelikes, Warsim) and space exploration (Seedship, Voyageur).

As an aside, commercial IF has seen an uptick in the past ten or fifteen years from studios such as A Sharp, Choice of Games, inkle, and Failbetter Games, as well as solo creators.

For the most part, I was able to better appreciate text-based games this time around. Still, I didn’t come across any that are quite like the game I want to make.

So what game do I want to make?

Essentially, a game with more world simulation than what is typical in contemporary interactive fiction.

I’ll start by pointing to a few inspiring games that I want mine to be like in spirit, even if some of these are more graphical than what I’m aiming for.

So, to put it more directly, I want to make a text-based game that is a detailed world simulation in which an authored story takes place (more on that below). I might borrow elements from other genres, such as real-time play like in MUDs, the gritty freedom of a survival sandbox RPG, and an alternative to parser-based input explored by Emily Short.

But the game’s essence is the setting: an open world that evolves over time, where pretty much anything can happen. Towns can be founded and wiped out by floods, animals can spread disease and be hunted to extinction, a drought can cause famine and malnutrition, the nobility can intermarry, discontented peasants can rise up in revolt.

What makes these world-simulating ambitions anything close to attainable in my (probably deluded) mind is what I’ve already said: there will be no graphics or other assets to worry about, just text. Also, certain things will be simpler because the world will be defined in physically low resolution, i.e. the world won’t exist as a grid of small spaces like in Dwarf Fortress, but instead will be composed of various large areas or regions. (For example, a town could be one area, the region surrounding the town another area, and the mountains to the east yet another area.) This means I won’t have to implement as much small-scale physics à la Dwarf Fortress. Even procedural generation will be limited, since it’ll be easy enough to handcraft a world map as a setting for a story. The game can fill in the gaps like wildlife and minor locations, so that only the world’s overall shape and important details need to be defined by a story’s author.

Returning to the other half of the equation, how can an authored story happen in an open-world sandbox? Wouldn’t a story grind to a halt if one of its key people or places were destroyed? Well, yes… remember, anything can happen! So stories will have to provide some minimum of contingency plans in case of mishap, so that the authored story has some level of interplay with the emergent narratives coming from the world simulation. Still, getting stuck through bad luck will always be a possibility. But maybe that’s OK. The unofficial motto of Dwarf Fortress, “losing is fun”, reminds us that chaotic failures are not always a bad thing.

Appendix A: writing text-based games in Ruby

If I were going to write traditional text-based games, there are many commonly-used authoring tools I could choose from. But I love Ruby, so I might have chosen one of these instead:

Appendix B: Answering my inner critic

🤨 “A game? Seriously? It’s been ten years since you’ve done any gaming. Now you’ve just had your first baby. Isn’t it time to move on?”

It’s true, I used to be a gamer but then in college, life got busy with other things, and it’s been that way ever since. It was a good change, and I wish it had come sooner.

And yes, I’ve just welcomed my first baby into the world 👶 He’ll be his own person, of course, but I’ll encourage him to cultivate other interests besides gaming (like I wish I’d done sooner).

Still, making a game has been my dream since middle school. I never did get around to it, first because of my teenage lack of discipline, and then by my choice in college to study the humanities rather than software development. Now that I’ve ended up as a developer after all, why not go back to that dream?

Don’t get the wrong idea—all this about “my dream” sounds more grandiose and ambitious than it is. The reason I’m contemplating a text-based game is precisely because I’ve just had a baby, and whatever project I start next has to be lightweight and easy to dip into while the baby is asleep on my lap and (tip for new parents!) my hands are free thanks to the incredibly useful Boppy pillow.

A text-based game sounds like the simple, restful project that I need right now.

💼 “You should really be making a Rails app, or a website, or some other useful thing. That would be best for your resume.”

I already do Rails at my job, so a hobby Rails app would feel too much like work.

I really like Bridgetown (which I used to make this site), and Scarpe looks intriguing for desktop apps, but right now I don’t have a compelling reason to make another site, or a desktop app.

🤖 “How about robotics? If you’re set on doing something frivolous, that would be way cooler.”

True, I could get a Raspberry Pi plus this robot car kit. Its actions are written in Python, but I could write new actions in Ruby using the Artoo Ruby robotics framework, or (at a lower level) a Ruby port of the RPi.GPIO Python module. (I’m a big fan of Ruby, in case you haven’t noticed.)

These robot shenanigans could be fun, and they might be inspiring to my kid when he’s a bit older. But right now I’ll pass, because it’s not a baby-friendly project. My lack of robotics experience means it would be a big time investment, and the troubleshooting would be stressful. Plus, all the (literally) moving parts aren’t conducive to being immobilized with a baby sleeping in my lap.

🎮 “Then at least make a game that’s less lame than a text adventure! You’ve been wanting to try DragonRuby Game Toolkit, right?”

Indeed I have, not least because DragonRuby has a great community around it.

The problem with me making a graphical game is sprites and other assets: making them (or even mixing-and-matching premade assets) would be tedious. I could make a game that uses geometrical shapes instead of sprites, maybe something along the lines of my childhood favorite Gravity Well, or the perennially fascinating sand games (e.g. Sandboxels, Powder Game), or simply a platformer that uses only rectangles (Thomas Was Alone is the best-known among many). But any of these may involve fairly complex geometry and physics, which are also high on my “don’t want to deal with it” list.

In a text-based game, these headaches would be out of the picture (because there is no picture, heh). And later on if I choose to add graphical features and/or I want to distribute the game more widely, I can easily move it into DragonRuby. In the meantime I’ll simply output text to the terminal, just like it was done in the early days.

👉 Newer: My plain-text reading list 👈 Older: Parsing text in Ruby, part 2 🚀 Back to top