Hello.
I'm considering creating a new open source text adventure engine, called XAE (XML Adventure Engine, this name may change), that run games specified in an XML language of my own design. I want to do this since I think that everyone, even people without any programming experience, should be able to create a text adventure game, and I also think that it could be a really fun project. However, since I actually want people to use this engine, I have a few questions to the community, to hear what people are actually looking for in a text adventure engine.

I'm thinking about dividing the game's specification into the specification of rooms. E.g. a room of a game could be specified as the following snippet of XML:

<room>
<descriptions>
<description state="0">It is a very dark room. You can just see a switch beside you.</description>
<description state="1">You can now see the features of the room. It has a sword in one corner, and a door to the north.</description>
</descriptions>
<items>
<item pickupable="true" description="A large, shiny sword">Sword</item>
</items>
<actions>
<action activateWord="push" resultStage="1">Switch</action>
</actions>
<paths>
<path position="n" description="An old looking wooden door.">Door</path>
</paths>
</room>
In this room the player will be able to do the following kinds of actions:

out>It is a very dark room. You can just see a switch beside you.
in>push switch
out>You can now see the features of the room. It has a sword in one corner, and a door to the north.
in>take sword
out>You take the sword.

and so on. I hope that from the above example it should be clear in what direction I want the engine to go in. I was just wondering, before I start seriously working on the project, if there are any features that you feel would be necessary, or just nice to have, in an engine designed to make text adventures, that you would like to see in XAE. Any miscellaneous comments about the concept are also very welcome, since I don't have that much experince with designing (or even that much playing) text adventure games, but I just find them fascinating.

And one last thing: Would you prefer such an engine to be written in something like C++ to give it a more integrated feel with the system, or would you prefer the slightly less integrated and more cumbersome feel of a Java application, which would of course also mean that it will be able to run on almost any system, and not just the ones that I, or yourself, want to compile it for?

I apologize for the long post, however I thought that I might as well ask all of my questions at once, and hopefully receive more meaningful responce. This is also my first post on this forum, so if this is not the place for this sort of question, I apologize.

I want to do this since I think that everyone, even people without any programming experience, should be able to create a text adventure game, and I also think that it could be a really fun project.

I hope the emphasis is on the latter (the fun project part) because people without any programming experience have been creating text adventures here using Quest for quite a while now (and there are others out there as well).

From what you expose of the file format, it looks very rudimentary. Do you have plans for conditional text output, where changes in the world state can be reflected in the text? That is a very common thing that people ask for.

Also, besides conditional text, you have things like: varying text; varying text/font styles; autonomous NPCs that move around and do things; robust conversation; room mapping; images associated with rooms, events and NPCs; etc.

I notice that you have actions in the room as well as items. Are there actions associated with items as well? It seems you would need that, as items can be picked up and carried around the map.

What you have shown is an XML file format. People with no programming experience are probably not going to be very comfortable editing XML files. So can we assume you will create a graphical front end, so people can easily edit their games?

The hardest part of a traditional IF game engine is the parser. The file format is fairly trivial, but getting input from the user and mapping it to the internal commands is a daunting task that people are still working to get right. If I were you, I'd play a number of highly rated IF games and read the IF literature to see what is expected from an IF game.

As far as how the engine is written, my preference would be an engine written in such a way that it can be deployed on all the current popular platforms, including mobile. That's no easy accomplishment, but if you can have that as a target, then it will take you far to where people want to be. I think it's less important how it's written than where it can be deployed.

A penultimate thought: if you really do want people to use this engine, then you're going to have to give it something that the other engines out there don't have. I don't know what that is or what that could be, but if this project is more than just something enjoyable for you to put together, and if you want users, then you're going to have to go beyond a file format. (If you haven't guessed from the tiny pieces I've put out there so far, this is a HUGE project!)

A final thought: a lot of what you want to do has already been done, in products that have been around for years (or even decades). Have you considered joining the development for an existing project like Quest, especially since it's open-sourced and already available for people to help out with?

(I could go on and get into even greater depth, but I'll leave it at that for now.)

One more thought: I would strongly recommend you try some IF creation tools out there and see what features they support. In particular, Quest has its own XML-based file format which you can examine and even edit by hand. You could probably glean quite a bit by working through the tutorial and seeing what ends up in the final file.

Hi jaynabonne, thanks for the very quick reply!
The emphasis of this project is definately on me having some fun in my spare time. I'm a computer science student, nearly done with my bachelor and looking to starting my masters degree the coming summer, so the thing that interests me most about this project is definately the technical implementation, and therefore the parser is also one of the things that I'll probably be spending quite some time on.

You're right that the format looks rudimentary, but that was to make it easy for new users of both XML and XAE to use, so I was going for a somewhat simple format. Your comment about people not being comfortabel with XML is probably correct, and I am also considering creating a GUI interface for creating the games, however I think that I'll wait with that until I have a working engine.

I'm not quite sure what you mean by conditional text? If you mean changes in room descriptions etc. based on for instance actions performed by the user or items carried in the user's inventory, then I was planing to implement that as a state number associated with every room, so that a given room's state could be changed, and it's description altered based on that. About the actions associated with items, as I showed, perhaps a bit implicitly, in my short example, items can be marked with a pickupable attribute, which allows the user to pickup and carry things in their inventory. A nice addition to this system might be to also add weight attributes and simillar to the different items. Are there any actions that you were specifically thinking of?

About your thought on platform availability, I'm definately planning on making this available on as many platforms as possible. I hadn't considered mobile platforms, since I personally hate typing for very long on the on screen keyboards most modern smartphones has, but this might certainly be something that I'll consider.

I have considered contributing to existing projects, however that would keep me locked in to their software architecture and design, and one of the big goals for me for this project is definately to build a larger, complete program myself, and actually publish it, so people can use it. During my studies I've of course built a lot of small applications and programs, but for me this is mostly a chance to put what I've learnt into practical use, and hopefully make something people can benefit from.

If you have any more feedback, now that I've hopefully clarified my idea a bit, I'd be eager to hear it.

By "conditional text", I mean sort of what you have but more. You have the condition happening at the room level, where you replace an entire piece of text with another, depending on state. I'm referring more to being able to have text with parts of it conditional *within* the text. Take a look at the Quest "text processor" for an idea:

http://docs.textadventures.co.uk/quest/ ... essor.html

Regarding the "pickable" attribute, I think you're going to find that that approach is either going to be a dead end or lead to incredible headaches as you try to expand things. A key part of the parser is the notion of "verbs". These are things you can do. And no matter how many you have, people will want to do more, especially as part of creating their own puzzles. For example, in a small test game I wrote, I wanted to be able to tie various things together, lower a package to another balcony, rappel, grab hold of a railing, etc. You would not want to have "tieable" (which takes an object for one thing), "lowerable", "grabbable", etc. That way leads to madness. So you'll want to call out your verbs and commands separately and make them easily created as opposed to being hard-coded in the engine, as a "takeable" attribute implies.

As an example, check out this walkthrough for a game by Emily Short called "Savoir Faire". (Randomly picked.)

ftp://ftp.ifarchive.org/if-archive/solu ... avoir.html

You will see many common commands (e.g. "x" to look at something, "take", etc), but you'll also see a good amount of game-specific commands (meaning, not every game will have them). Things like "search", "look under bed", "open mead with corkscrew", "break case with stick", "empty cup in basin", "squeeze hanky in cup", "kick rat", "pray". Game authors will want the flexibility to create and code for all these sorts of commands and more And how to do that in a way that is easy for a neophyte user to handle is no small task, especially if you want to avoid scripting. The approaches most IF engines take is to try to *simplify* the scripting as much as possible (Inform even has an English-like source language), but you can't do without it and still be able to create flexible games.

I don't want to sound discouraging. Actually, I feel the opposite - it's great that someone wants to create a project, especially something substantial. I myself have been working on my own IF tool of sorts for a while now. But I'm doing it for me, because there is certain IF I want to write. So what I would say is:

1) Write something *you* want to use. Create something that is of interest to you and which will still be satisfying even if the rest of the world never touches it. As far as I know, all the current popular IF tools out there (including Quest) were written by someone for themselves initially, because they wanted to create their own IF. Once the software gained momentum, they unleashed it on the world.

2) The follow on to 1: don't have high expectations of lots of people using it.

I hope you actually wish to create interactive fiction yourself. If not, then I think this path may end up frustrating for you. You really need to have a project that *you* feel strongly enough about to take on, regardless of the rest of the world. Just my two cents. (And I'm a programmer myself, for more than years than I care to admit at this point, so I can understand your excitement and drive!)

Here is a thread I was reading lately on intfiction.org:

http://www.intfiction.org/forum/viewtop ... 33&t=10860

This might give you some insight into how people feel about new tools. It's not that people are adverse to them. There just has to be a compelling reason to use one over the other. It could be as simple as ease of use or speed to get from idea to realization in code.

It also shows how things work best when the tool creator is actually a writer of IF himself.

Also, here is a thread here on the Quest forums where I posted my work-in-progress Response Library. I'm not saying you should have anything to do with it other than that the thread lists the sort of features I was looking for and finding lacking. That probably lists a good deal of what I would find important in an IF tool.

viewtopic.php?f=18&t=3909

One more bit of food for thought (and then I'll stop). This lists the highlights of a recent Oxford Tools Meetup. It includes discussion about "what do you want in a tool" after some presentations of new features for current tools. This should give you an idea both of the state of the art and what is lacking but desired:

http://emshort.wordpress.com/2014/03/30 ... ls-meetup/

Wow, thanks for all of the links, I really appreciate it (guess I chose the correct forum to post my idea ) Unfortunately I don't have the time to read it all tonight, but I'll definately be checking out the links tomorrow or one of the following days. Again, thank you for the time that you've obviously put into this.