intfiction.org

The Interactive Fiction Community Forum
It is currently Wed Dec 12, 2018 10:34 am

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Mon Jul 09, 2018 10:19 pm 
Offline

Joined: Mon Jul 09, 2018 10:10 pm
Posts: 2
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. http://www.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.

Image

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.

Image


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

http://textrealms.neocities.org

-T. Shawn Johnson (Whystler)


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Jul 10, 2018 7:47 am 
Offline
User avatar

Joined: Sat Jun 25, 2016 12:13 pm
Posts: 249
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 :-)

good luck with TR.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Jul 10, 2018 10:02 am 
Offline

Joined: Wed Feb 15, 2012 7:00 pm
Posts: 390
Reminiscent of the brief fad for text adventures programmed as batch files played in the OS command line!


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Jul 10, 2018 4:56 pm 
Offline

Joined: Mon Jul 09, 2018 10:10 pm
Posts: 2
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 :)

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!!!


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Jul 11, 2018 7:30 am 
Offline
User avatar

Joined: Sat Jun 25, 2016 12:13 pm
Posts: 249
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!


Top
 Profile Send private message  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group