Text Realms IF-VR Browser

Hey all,

I made a little program. It is quite literally little; currently at 250 K , and consisting of a single executable file.

It’s a browser for text adventures. This means you host your files on web directories that you control throughout the internet, and the little browser navigates to them, reading out your room descriptions, and using the commands you’ve defined to read out the descriptions that result from these commands.

A room that you make consists of a web directory (ie. someplace.com/somedirectory) , which hosts a number of text (.txt) files, written in windows notepad or other similar programs. Your main room description is called room.txt. And all of the other text files you make to describe any of the features of the room that are accessed by commands are called whatever you like. The command centre file is a simple .ini file, called room.ini, that you can also make in windows notepad and saved with that extension instead of .txt. It consists of a list of commands, each command followed by an equal sign, which is followed by the name of the text file that your custom command summons into the browser. A command can, instead, be followed by an equal sign and the url of a web directory as a portal to another room.

It’s extremely simple and accessible, and allows people to stash their creatively written virtual worlds across the internet and link them.

I would GREATLY appreciate your feedback if you would have a look at the program. As I say, it’s a tiny thing, and will be a fast download of one file.

The browser, in its current form, also has a simple adventure I created with the goal of finding a way out of the space. And the goal provides you with a password at the end. No one has yet beat the room, but the first person who can comment (here, or on one of my facebook posts) with the password will get a special mystery gift mailed to them that I picked up in a local hand craft shop.

Thank you! :slight_smile: You can find the deets here:


-T. Shawn Johnson (Whystler)

1 Like

Hi There!

I tried out “Text Realms” and have some ideas.

The idea of storing the “plot” (as TR calls it), in separate files and directories is a powerful concept.

Many years ago i worked on a multi user text adventure system, like a MUD, that used a similar principle of text files in directories to great effect. Sadly, it was never finished. It worked like this;

Each location is a directory. Players are also directories. Objects are text files. The behaviour of each object is INSIDE its text file. This is in contrast to your “room.ini”, instead “look at billiards table” would be INSIDE table.txt. I strongly urge you to change to this model, so that;

Getting objects simply moves a text file from its directory to the player directory. Drop is the opposite.

Moving about, moves the player directory to a different location directory.

Listing objects in a room is simply finding the files in the “current directory”. Finding directories there also are OTHER players.

Things you can do with objects are commands listed INSIDE their text file, eg “eat cake” inside cake.txt. There would have to be some built in verbs such as “eat”, “go” etc.

For verbs, the way we tried it back then, was each verb was an EXE. eg “get.exe” “go.exe”, “eat.exe” etc. Those verbs knew how to interpret the text files appropriately by linking with a common library.

The upshot of this was a fully multi-user game that used the operating system to do the real (multi-user) work - for example if two player both ran “get cake” (ie get.exe “cake”) at the same time, only one (ie the first) would successfully move the cake.txt object into their directory and the other “file not found” would be reported by “get.exe” as “you don’t see a cake here”.

IIRC, the “objects” were text files, but we had “cake” not “cake.txt” so that that game commands (eg “get cake”) were actually typed on the real command line! Also the verbs weren’t EXEs, since it was Linux (but you get the idea).

That way we could work and play a game at the same time :slight_smile:

good luck with TR.

Reminiscent of the brief fad for text adventures programmed as batch files played in the OS command line!

Hey JKJ:

Great suggestions! I love the concept you described.

The only problem I see, is the inability for files in a web directory to be rewritten by anyone other than the owner of that webspace. The security measures, and possibility for abuse are an issue, as well as the creator/author’s control over their work.

The concept of TR , is such that the writer has full control over the content, and also that the content doesn’t require maintenance of any kind (ie. no need for a server or live-database that needs to be kept alive or maintained). Right now, it’s a set of unchanging files that sit in one place that needs no watering, fertilizing or weeding :slight_smile:

That said, you’ve made me think. Because there is an element of this project I wanted to add one day down the road. And that is a multiplayer aspect which DOES require a server, or servers to be maintained, but in such a way that the servers aren’t required. They are just a bonus. And it could go something like this:

-TR could become a client, that can access a server … any server … or not. And if this were the case, then you would fill out a setting with the address of the server you would like to connect to.

-In this way, you could interact and chat with people if their client was connected to the same server. And if you didn’t love that server or that community, then you could change to another server. Or if the server you loved disappeared, then you could hopefully find another.

-And then, the server would essentially save a copy of the text files when they are visited, and hence be able to then read the text files, and write to them, as the game changed. When it came time to reset, the room would simply be purged from the server’s database, so that when it was accessed/downloaded again from the author’s webspace, it would be back to factory settings, if you will.

But for now, the implementation of such a thing is a long term goal. There is so much authors can do with a low maintenance system as it stands. I would love to see what they can come up with, before progressing.

Thanks for taking the time to explain the concept you mentioned. It’s really interesting and thought provoking!!!

You’re right that the web version without a server cannot change files.

But that means the server, and therefore the game itself, cannot accommodate ANY changes in state whatsoever. Perhaps in this single user mode, your TR program should actually download the game files from the server so that those local copies can be modified through play.

I like your idea of having a web server for multi user. This would not be as complicated as it sounds. Providing all game state were actually in files, the server would be something that supported file access and modification. So it would be something generic and not specific. Webdav?

Anyhow, the idea of using plain text files to make a game is very powerful yet simple. Can i suggest one thing for the short/medium term;

Right now you have all your behaviour in “room.ini”. Instead consider putting the behaviour (can be the same foo=bar syntax) in the object.txt files. Keep the directories for each location, but have a file of the same name inside to contain the room behaviour (description etc.)

I suggest this because the behaviour depends on the objects and not the room. Right now, it only works (in “room.ini”) because you can’t move objects about. When this is the case, you need to “move behaviour”, and that’s why it needs to be inside the object files not the room files.

Good luck with the project!


First, getting this out there:

So here’s the easy strategy. Run PennMUSH on a Linux box (or one of the others). Connect up to the PennMUSH demo instance, and talk to the folks there if you need help getting started, they were fantastic back in the day.

Once you get it installed and do your initial setup, install Node.js and there’s a standard WebSocket proxy that can connect right up to it, and then that’ll pull the content straight into a webpage if you need to. And that gets you all of the PennMUSH features, you can find script libraries for it, etc. and get going real fast with that model.

However, assuming I didn’t have interest in using one of the engines in a browser - I’d start with a wiki engine, any of them. Wiki lets you create a start page - just like Twine or Informix - and then you can create links, and click them - and that takes to new pages. The wiki software already has security features to control who can edit what, and storage things - and so really, you’re just talking about adding an extension with what additional features you need.

And so generally - you have a player record of some sort, and that’s got an ID tied to the user ID. That’s easy enough to implement. And so you just shove that in the database of your choice, pop some indexing in to let you find the things you need, and it’s just an extension in whatever wiki software to add your stuff in.

The reason I’d start with wiki, again, is it doesn’t require any tool past a web browser and it already has basically the same feature set as Twine, minus the state tracking. And so all you really have to do is design and add the state tracking, not the whole thing.

However, I’d really consider using one of the standard MUD engines and just using websockets to connect to it, because there is a ton of security stuff involved that the folks writing those engines have already solved, involving item management, etc. And I’d recommend, particularly, Penn or Tiny - might be new ones that are better, it’s been a while- because they have really good in engine security after, you know, three decades of development or so.