Implementing an IF interface in 3D

Most of today's graphical adventure games eschew text input and output for more streamlined, symbolic interfaces and visual feedback. The typical IF game is somewhat unique these days in that it relies entirely on text for both purposes. There are advantages and disadvantages to each interface type, but what I want to know is, could a hybrid IF-like interface work in a 3D graphical game?

Rather than going into the why, I thought I'd discuss the what, so at least you'll have an idea what I'm talking about and how it might work. Cue the screen shot.



This is a shot of the kitchen, which is still a work in progress. The cupboard is to the left, a table is straight ahead, and a locked hatch in the floor is in the back to the right. At the bottom of the screen is the text output window. Here's a close-up:



The box above the text output window is the command entry window. It pops up when you hit the SPACE bar. You can still move the camera around and click on objects while it's open, although all keypresses are sent to the entry window while it's open.

I wanted to design the interface so that people comfortable with IF could play the game almost entirely with text entry, if they so prefer, even though I don't expect that to be the case. The main exception is movement; there are no text commands directly related to movement, such as compass directions, IN/OUT, UP/DOWN, and so on. These are all performed via the typical FPS-style W-A-S-D setup, with the mouse used for camera panning. But aside from that, most other commands can be entered through the command entry window.

The parser was designed to be comparable to other common parsers, like those from Inform or TADS. It can handle things like actions on multiple objects ("Take the food and the keys"), disambiguation ("Which door did you mean, the bedroom door or the locutory door?"), and completion ("What do you want to unlock the hatch with?"), although I suspect the ability to select objects visually will eliminate much of the need for these. Common abbreviations are supported, such as X for examine, G for again, I for inventory, and so on, although these actions can also be performed by pressing the appropriate key, without having to bring up the command entry window. So "I" will bring up the inventory window, without having to hit SPACE-"I"-ENTER.

Speaking of the inventory, it is implemented graphically as well as through text. The common text presentation is preserved for those comfortable with it, but it is also presented as a separate window:



The items in the inventory are selectable with the mouse, which will then allow you to perform actions on them. So, if you click on the keys to select them (as above), and then hit the "X" key, that would be the equivalent of bringing up the command entry window and typing EXAMINE KEYS.

Despite the inclusion of (and emphasis on) a text input interface, point-and-click is provided and is very useful. Clicking on objects to select them results in the object becoming highlighted visually, as with the cupboard door below:



Once an object is selected, it can then be acted upon either through single-key commands (such as X for EXAMINE, or O for OPEN) or through the command entry window. In the case of the latter, the act of selecting an object allows the player to exclude the object from the text command -- it is automatically assumed to be the object acted upon. So in the example above, with the cupboard door selected, the player could just bring up the command window and enter OPEN, which would be interpreted as OPEN CUPBOARD DOOR.

The same applies for commands requiring two objects, such as unlocking the kitchen hatch:



By selecting the lock, the command can be abbreviated to just UNLOCK WITH KEY, and the parser will interpret the command as UNLOCK LOCK WITH KEY. Likewise, if the inventory screen was open and the key was selected, the player could type UNLOCK LOCK, and the parser would interpret that the same way.

As alluded to in the image above, there are other ways to simplify the performance of actions. The middle mouse button (usually a clickable mouse wheel) can be set to perform one of a list of common actions. Scrolling the mouse wheel flips between the different options, which right now are LOOK, TAKE, EXAMINE, and INVENTORY. Each rotation of the wheel is the equivalent of entering the command "SET MIDDLE MOUSE BUTTON TO < action >" in the entry window, so this could also be done directly via text. Then clicking the middle mouse button performs the action. I typically have it set to TAKE, so I just need to click on an object with the left mouse button to select it, followed by the middle mouse button to TAKE it.

The other customizable key is the TAB key. By default this is set to INVENTORY, but it can also be set to one of the commands above as well using the "SET TAB TO < action >" command.

Aside from the middle mouse button mentioned above, the mouse is reserved for selecting objects (left mouse button) and camera panning (right mouse button click and drag).

It's a lot to remember, no question. I think it will be perceived as a barrier by many people, particularly newcomers. But I do think the basics are fairly straightforward. Most of the shortcuts will probably take some time for players to remember and become comfortable with them, but once they do I think players will be surprised how streamlined most commands are, while still allowing for more advanced command input with the entry window -- which itself can be faster than in traditional IF.

Of course, this is still very much a work in progress, so it will undoubtedly change over time. I thought it would be useful to show how I've approached incorporating an IF-like interface into a 3D world, for future discussions as well as to solicit opinions and suggestions. Both are welcome and appreciated.