What tools are we missing?

It's a truism nowadays that the Cambrian Explosion of games we're living in was only possible thanks to a plethora of easy-to-use tools. A virtuous cycle: people wanted to make more games like those they loved, but without starting from scratch every time. So they made tools anyone could use, and people used them. In turn, that created a market for more such tools.

And what a fascinating market it is. Right from the start, we've had commercial game building tools, internal tools later released as products, modding tools released for free as a promotional stunt and, yes, open source tools created by skilled hobbyists. One might expect the latter to cover the low end, but look at Godot Engine directly competing with Unity, or Superpowers with Construct 2. And the premier tool for making visual novels is Ren'Py — so far ahead all competition it's not even funny. Only the JRPG tool market is dominated by one vendor with expensive products, but that's a tough nut to crack, as more than one hobbyist developer learned from bitter experience. Conversely, interactive fiction authoring tools are all gratis if not open source. Perhaps because there was no money to be made in the genre for a quarter of a century, and by the time the wheel turned again, existing free tools were already too powerful and polished.

Maturity has its perks. On the downside, things settle down in overly familiar routines. When you spent most of your time swinging a hammer, problems that aren't nails get overlooked.

Tools for making text adventures have been around since the 1980s. Some were even popular, being used to make hundreds of games. None however broke out of their own closed communities until Inform allowed people to make games that not only imitated the look and feel of Infocom classics — TADS could do it too — but were in the exact same formats, playable with now-standard interpreters. Which in turn enabled an entire ecosystem. The genre, declared dead just three years before the first IFComp, sprung back to life and never again faltered. One can even make a living at it, just like in the old days!

Trouble is, this new crop was firmly cast in the Infocom mold, and almost faded back into obscurity for failing to break out of those rigid confines. Even latter-day innovations in user interface were ignored in favor of a purism that left many authors chafing. It took Twine to show people how much more could in fact be done, at the cost of throwing out the simulation baby with the parser bathwater. Because, you see, Twine (like Texture) focuses on the manipulation of text itself, as if a clock was only a pretty sculpture, and not the complex movement inside...

Similarly, Ren'Py made it very easy to create visual novels in the traditional format... and much harder to do anything else. You get one textbox by default, for all dialogue; if you want more, you have to pop the hood open. Character portraits parade on the stage emoting, but you can't make the game react to players clicking on them — not without peeking under the hood again. Ironically, other open source engines are more flexible out of the box, at the cost of a little more setup work upfront. But they're nowhere near as capable.

You're going to say both are highly formulaic genres, which is a big part of their appeal on the one hand, and why so many good tools can exist. But sooner or later audiences grow tired of a formula that fails to change with the times. It happened to graphical adventures. It happened to RPGs. And tools carefully shaped over many years to yield a very specific kind of work make it hard to even imagine the tiniest variation.

Which begs the question: if we can't easily imagine new kinds of games, how are we going to envision the new tools we'd need to make them?

One way is to think of what you'd like to see more of in games that isn't already there. What good parts of your favorite genres seem to get the short end of the stick? In my case it's exploration, and it took me a shamefully long time to realize that, even after playing over a hundred text adventures and a few RPGs, making my own and experimenting with tool creation. After all, bringing strange new worlds to life is why I got into programming, and later into writing. And to be honest, plenty of games do provide that sense of wonder, of "let's see what's over the next hill". Even some games with procedural generation, usually of the 4X variety. Which says a lot.

But it's not what authoring tools usually emphasize. Even when a diversity of real-world objects are accurately simulated, it's to support puzzles, combat or both. The more intricate the better.

Not that I mind either! Puzzles and combat alike are good means for pacing and structuring a game's narrative. They can ensure players visit some locations before others, for instance, or stop and take in their environment at key junctures. That's the very reason they were added in the original Adventure at all! But soon they became the whole point... and ever since tools have made that abundantly clear.

So this is what I was really missing: an authoring tool focused on creating rich worlds to explore and discover, with puzzles and combat in a support role as opposed to front and center. Ironically, my first steps in that direction were taken unwittingly in the form of Adventure Prompt, an experimental authoring system inspired by MUSHes and MUCKs. Which in turn evolved from combat-oriented MUDs into social playgrounds people could build up to their heart's desire. And if you haven't tried, let me tell you that yields veritable wonderlands full of old forgotten corners you can lose yourself in for weeks of real time.

It also yields worlds that very much want to be persistent, as opposed to having a definite ending like stories do. I solved that problem in a separate experiment, for better or worse, though it was arguably not a big deal: plenty of RPGs allow you to go right on playing after the main storyline has ended. Not so much adventures, which always have definite ending conditions — an odd trait for works pretending not to be games, but when all you can do in them is solve puzzles, what's left when all of them are unraveled? The closest Adventure Prompt comes is having a room you can reach, or an item you can pick up, designated as "ending". It's shoehorned in, but then from a programming standpoint all game endings are: a simulation just wants to go on and on, even after there's nothing else left to happen.

I can do even better. One other thing to add would be a proper magic system, because in most text adventures spells are just extra verbs you unlock at some point (exceptional cases like Suveh Nux only make it more obvious). Last but not least, a combat system, to add a layer of strategy — to let players gradually work their way towards a solution, instead of being stuck at one point flailing for the single precise action that will further the plot. And it just so happens that I recently perfected one of each for a roguelike I'm working on. A rather different type of game, but the core rules don't care.

Speaking of strategy, my long-time dream is finding a way to easily introduce such a component in adventure games, as the two genres blend together very well indeed, and text-based strategy is a niche as popular as it is underserved. But though I wrote about it extensively years ago, a way to do it in practice proved elusive. Perhaps because as of this writing I have little practice actually designing and implementing strategy games, despite being a fan of the genre.

In fact, most of my recent work has been in roguelikes, and those make the very notion of an authoring tool rather more complicated. There are ways to make your own without starting from scratch, but since roguelikes are mostly made of systems, and systems have to be programmed, it doesn't work quite the same as in games where most or all content is handcrafted. But perhaps some lessons from them could be applied to other kinds of games. Mostly about getting by with highly abstracted graphics or even just plain text.

Clearly more research is in order.