GUI authoring system to recreate Colossal Cave Adventure?

I’m looking for a GUI based authoring system to use to recreate Colossal Cave Adventure (most likely the 430 point version) and need some advice on which one would be most suitable for this.

AFAIK, the only low code options are ADRIFT, Quest and TAB, as Lantern is limited to 128 rooms/objects.

Off the top of my head, I can think of two potential issues…

Some locations with identical descriptions are actually different, so there would need to be a way to easily tell them apart during development.

Movement commands are not limited to the standard compass points. Words like “building” and “downstream” can be used to move, sometimes when the player is not in an adjacent location. Magic words can also transport the player long distances.

1 Like

I can only speak to the ADRIFT 5 side of things (and even there I don’t have much experience), but the two points you mention should not be significant challenges in that system.

ADRIFT will silently swallow up any unrecognized HTML formatting tags, so a common practice is to name your locations something like “Corridor<north>”, “Corridor<south>”, etc., and the player will just see “Corridor” for all of them. (While the editor will show the full name including the tags.)

Tasks can do more or less anything, including moving the player around. Unfortunately, you can’t set up entirely new directions, but you can sort of emulate them if you set up some tasks in the right way. It’s not exactly hard, but could get pretty annoying if those extra movement verbs apply to a large number of locations.

Inform is, by far, the most popular tool for developing games like this. It has a large community of folks here and elsewhere who can help you to learn it.

I dunno if you’d call Inform “low code,” but I think that “low code” may be less important than you’d think.

You’re definitely going to be exercising coding skill as you implement any interactive puzzle game, regardless of whether you’re typing code with your keyboard or clicking buttons in a GUI. And for IF in particular, you’ll have to type something just to articulate what happens in response to user behavior.

Overall, I recommend using Inform for this unless you have an extremely clear reason not to use it.

I noticed that feature when browsing the ADRIFT manual online. I would most likely include the location number in angled brackets to keep track more easily.

If I remember correctly, “building” can be used to travel to the brick building from almost anywhere above ground and there is a magic word to travel there when underground.

Again, from skimming the manual I’m guessing creating a flag for “outdoors” and another for “underground” would be the simplest way to check if those words were valid commands.

From what I’ve seen, Inform has extremely verbose code. Even if the syntax is closer to English than most languages it is still a (domain specific) programming language.

I’m currently looking for something that will allow me to build a text adventure from existing blocks of code rather than having to write them directly.

Once I feel I have a clear enough idea of how everything fits together, I plan to move on to using an authoring language such as ALAN, A-code or DAAD.

After that, I hope to be have learnt enough to code it again in a general programming language.

Finally, I would like to create a domain specific code library in a general programming language.

I’m unlikely to use Inform at any point because the code and the game text seem too interwoven for my tastes. I know many people like that, but I prefer to be able to easily differentiate the code from the game text if anything doesn’t work as expected.

1 Like

Remember that Inform 6 and Inform 7 are very different beasts. You may find that Inform 6 is a lot closer to what you would eventually be comfortable using.

You’ve outlined a very unique path to eventually progressing on to writing your own adventure system. I’m not sure why you would particularly need to start with a GUI interface as a stepping stone into something like ALAN or DAAD. Having to learn multiple adventure systems is a lot of work. That time could just be spent on learning one in detail.

I don’t think I’d choose Colossal Cave Adventure as an example to implement to learn a new adventure system. I’d always start with a very basic adventure, myself, and gradually add in new elements to expand and make things more complex.


I thought that a GUI interface would make the process simpler. I know it did when I first started to create web pages.

I’m also interested in whether a system like that does actually help or hinder the process, so I know whether adding one to my own system would be worth the extra effort.

It would also make for an in depth review, if I start a website.

I chose Colossal Cave Adventure as it is well documented and there are more than a few existing examples in multiple languages. I intend to create it in stages, probably starting with adding all the locations and exits.

1 Like

Let me assure you that the path you’re proposing is not the “easier” path. At the very least I recommend that you write your first game in Inform, to get a deeper understanding of the industry standard approach, before attempting to create a domain-specific code library for developing IF in a general-purpose language.

Indeed, it’s not uncommon for IF enthusiasts to present this forum with alternate IF authoring systems (libraries!) in which authors can develop IF with a “real” programming language, typically one of the top 20 languages on the TIOBE index, or at least a language that ranks highly on StackOverflow’s “most loved languages” list.

But these authoring systems never seem to gain traction. None of the most popular parser-IF systems require authors to use a “real” programming language. All of the most popular systems use a domain-specific language for IF.

Why is the IF community so enamored of DSLs? This isn’t like other parts of the game industry. In the game industry in general, even if people do decide to implement their own engine from time to time, the most popular game engines use popular general-purpose programming languages, the same languages everybody else uses. The IF community must be full of weirdos, right?

Well, yes, but we’re not the only weird ones. Consider querying a database. You could do it in C or in JS, and some people do, but the industry has discovered that using a declarative query language is better, and SQL is by far the most popular language for doing it, despite the fact that SQL doesn’t have much in the way of step-wise debugging support. If you’re querying a database, trust me, you should just use SQL. (At a minimum, you should learn SQL before attempting to query a database in another language.)

Text adventures aren’t like other programs that run step by step from beginning to end; they’re programs to cooperatively generate text, incorporating commands from the player while subtly guiding the player how to use the correct commands to win. Coding a parser-based text adventure is mostly about declaring data (what are the rooms and objects in the game) and a rules engine of events that fire when certain conditions occur.

The rules in full-blown text adventures typically aren’t like onLook event handlers. They’re more like, “when the dragon is asleep and the player has brought the princess to the same room with the dragon and the princess has her wakizashi or one of the following five weapons…”

The general industry wisdom when it comes to rules engines is that they all kinda suck. It’s easy to get started rolling your own rules engine, but it’s hard to write a good one, so everybody just rolls their own. And this is another area where DSLs often do thrive. (The article I linked above is by Martin Fowler, who concludes, “there’s a lot to be said for avoiding rules engine products.”)

Then, when you add in the fact that most IF authors see themselves as writers first and coders second (if at all), you start to see why a community has formed around DSLs for text-adventure rule engines, and why good programmers keep writing their own IF-rules engines rather than use anybody else’s.

This is also why GUIs for IF development tend to suck. It’s hard enough to write sophisticated rules in code; it’s actually harder to use a sophisticated drag-and-drop “low-code” tool to define rules like these. (And what problem is the GUI even solving? Anyone who could use a “low-code” tool for developing the rules would need all of the sophistication you’d need to write code.)

I’m telling you all this not to be discouraging. I think the world could be a better place with a popular IF engine oriented around a general-purpose programming language, and especially if someone were to implement a rules engine for JS that people love, not just for IF, but for all sorts of rules-engine shaped problems.

The path up this mountain is littered with the frozen corpses of others who have tried and failed to reach the top, but I hope somebody manages to climb it, and I wish you the best of luck.


I intend to use at least two different systems before attempting to create anything new.

Neither of them will be Inform however, as it is completely unlike what I would be aiming for. Of the code-based systems I’ve looked at, I prefer the syntax of ALAN.

In that case, the system I have in mind would provide something different.

I have no idea how many prospective IF authors there are out there that already know an existing programming language, but there must be some and I’ve yet to find anything current out there that caters to them.

Another similar group that doesn’t seem to be catered for is those who wish to learn a general programming language by creating a text adventure. For them, learning to use Inform isn’t going to help much.

Most, but not all. I’m the complete opposite, which is why the most popular tools don’t fit my needs.

The problems of having to type the same code multiple times and knowing what code is expected. In systems like ADRIFT you can click on the “add new location” option and then fill in a form with only the parts unique to that location.

You can still add custom code where needed, but many of the repetitive parts are handled for you.

1 Like

And my advice is: don’t knock Inform until you’ve used it for a full-blown IF game. There are good reasons why the community overwhelmingly prefers Inform to ALAN or ADRIFT, even IF authors who already know an existing programming language.

What you’re proposing is akin to writing a library to query an RDBMS without even learning SQL first.

I dunno. This is a hobbyist group, and if you think you’d enjoy this, I’m certainly not going to stop you, but if you’re planning to reinvent the way people solve a problem—any problem—I just think you should deeply understand the way people solve the problem today. Solve the problem at least once the “conventional” way, then invent the better way.


I really don’t think this is true. There are several blogs and books on that very topic. I regularly see people writing about it… one of the big popular, daily coding challenges, a few years back culminated in a text adventure as the final project.

I mean, adventure author (from the 1980s) Huw Collingbourne alone has two books… one on coding adventures in Java and one on coding in C# (and other languages). Huw talks about using Delphi on his blog here… Bitwise Magazine: Writing a Retro Text Adventure in Delphi

There’s quite a few Python-specific resources, including at least one book (By Philip Johnson).

I really don’t think there’s a shortage of resources for people who want to code their own adventure in a variety of languages.


Right, I think this is the dynamic Dan is getting at – the authors in that first bucket are mostly already using Inform or TADS (I think we’re basically just talking about the parser side of things now, correct?), and the much smaller number of authors in the second bucket are mostly rolling their own system.

If you want to work up a domain-specific library in a general programming language since that sounds like a fun project – and even as a non-coder, I can see how it would be cool – awesome! But if you’re doing it because you want other folks to eventually use it, the challenge is to figure out how to meet these two sets of folks where they’re at, and examining their revealed preferences seems like a good way to start.

Like, it sounds like you’re thinking of the audience as largely people who already know a general programming language, or are excited to learn one, so at least figuring out what you can offer them that they wouldn’t get by just implementing their games directly in the language seems like an important first step, and I’m not sure I see how the large amount of work you’re proposing to take on here gets you any answers to that.

Apologies if this comes off negative – like I said, I can see how this would be a fun challenge to dig into for its own sake!

1 Like

Yes, I do highly recommend that anyone who’s really interested in the internals of parser IF try to write their own system from scratch at least once. It’s a fun project, figuring out how parsing should work and how to represent a world model. (Turns out text processing on a TI83+ graphing calculator is a huge pain in the ass…)

It’s just also important to think about who your intended audience is, and what they’re interested in.


Most of the blogs I found on the subject were incomplete and/or for choice-based games.

Huw Collingbourne is the only author I know of that has written books on creating text adventures in popular languages in this century. The Philip Johnson one explains how to create a strange grid-based RPG hybrid with single letter commands.

Most of the others are either reprints or updates of earlier books, or cover less common languages.

Huw Collingbourne also has a video course on Udemy called “Adventures in C# Programming” which I found interesting, even though I don’t use C#.

In any case, what I actually meant was that existing text adventure skeletons, libraries or systems written to be modified and reused are thin on the ground.

It would be similar to any other game development library or framework, but specifically for text adventures. If I made the source code available, anyone creating a text adventure in that language could use as much or as little as they liked.

Modifying and replacing existing code can be a good way to learn a language, plus you get to see results sooner rather than later.

When I first became interested in programming (back in the mists of time) I used to stop BASIC programs, change a bit of code then continue it to see what difference it made.

I also used to type in program listings from magazines, even though they weren’t for my machine. Kids of today don’t know they’re born! :wink:

1 Like

fully concur and agree.

back in the mid-90s, in r.a.i.f (now this forum) and gmd-de/if-archive (now was published many "authoring system guide/FAQ, and all those guides put the presence, or lack of, examples and source code as a major factor in evaluating and weighting the IF languages of the time.

whose now should raise a major point: now is nearby a quarter century after those guides and FAQs, and, this being not the first time IF languages as whole are debated, I strongly think that it’s due time for a new set of guides/FAQs for the 2nd quarter of the XXIth Century.

Best regards from Italy,
dott. Piergiorgio.

If writing your first IF, Colossal Cave Adventure is NOT where you want to begin. May I recommend Cloak of Darkness!

The “Cloak of Darkness” specification

There are just three rooms and three objects.

  • The Foyer of the Opera House is where the game begins. This empty room has doors to the south and west, also an unusable exit to the north. There is nobody else around.
  • The Bar lies south of the Foyer, and is initially unlit. Trying to do anything other than return northwards results in a warning message about disturbing things in the dark.
  • On the wall of the Cloakroom, to the west of the Foyer, is fixed a small brass hook.
  • Taking an inventory of possessions reveals that the player is wearing a black velvet cloak which, upon examination, is found to be light-absorbent. The player can drop the cloak on the floor of the Cloakroom or, better, put it on the hook.
  • Returning to the Bar without the cloak reveals that the room is now lit. A message is scratched in the sawdust on the floor.
  • The message reads either “You have won” or “You have lost”, depending on how much it was disturbed by the player while the room was dark.
  • The act of reading the message ends the game.
  • And that’s all there is to it…

It is simple enough and you can write it in a few languages, including your own, in a short period of time. This starting point helps me see the bigger picture.

BTW, it is also an industry standard.

Cloak of Darkness - IFWiki


> drop cloak. S

Wins no?

1 Like

A dropped cloak in the cloak room can win, providing you read the message and it says you win.
Some ports give you one point for such a win, while giving 2 points if you have the cloak hanging on the hook, when you win.

1 Like

But can you not just drop the cloak in the foyer and go south?

1 Like

See this spec - The player can drop the cloak on the floor of the Cloakroom or, better, put it on the hook.

There is no guidance to drop it anywhere else. So the short answer is NO

1 Like

I can imagine dropping your cloak anywhere else would be disallowed for reasons: maybe there is a sign no littering allowed. If you really need a reason. I mean IRL you also probably would not drop your coat on the floor when visiting an opera house :D.

1 Like