There are two ways to look for creative innovation.
The conventional way is to look at recent efforts in a field (see, for example, Emily Short’s post Experimentation in the Parser Domain).
The paradoxical way is to look at older work. Many times a work’s innovation is lost because the work itself is obscure or the implementation of a promising concept was badly done. Often you can find the future in the past.
This seemed neat, but I had trouble making it work until I tried to ride a bus. The bus moves about the map at three stops travelling back and forth, and if you want to get on the bus it sometimes takes a long wait. Several times I accidentally waited past the bus arriving. I made a macro.
>X
=IF SEE THE BUS THEN RIDE BUS. I
Now every time I type “X”, the game will first check there is a bus. If so it will ride the bus (in needs to be in that exact syntax; for all the advanced tricks the parser can do it misses some obvious synonyms). If not then it takes inventory to wait a turn. (While WAIT is an actual command it causes a real-time delay.) The game still takes inventory when successfully getting on the bus, but it doesn’t cause an issue with timing.
Here’s the macro in action:
>X
>I
You are carrying the following:
Transit Pass>X
The roar of an engine and squealing tires can be heard up the street.
>I
You are carrying the following:
Transit Pass
You look in the distance and see a large bus approaching. The bus
pulls to a stop before you and its doors open with a loud hiss.>X
There is a large bus here that looks like it’s getting ready to leave.
>RIDE BUS
You wave your bus pass and the bus driver smiles as you climb aboard the bus.
Easy Street. (on bus)The bus door closes and you hear the grind of gears as it pulls away
from the stop.
The bus rattles somewhat as it carries you ahead.
Easy Street. (on bus)The bus rattles somewhat as it carries you ahead.
Easy Street. (on bus)
Now I can just rattle of Xs until the bus arrives and the player character hops on automatically as opposed to spamming just a wait command and missing the bus altogether.
ADD: I realized this would be a better way to write the macro:
IF NOT SEE THE BUS THEN I. IF SEE THE BUS THEN RIDE BUS.
This way there’s not the extra turn taken after riding the bus. This required a bit of a programmer’s sensibility; the player won’t see the “bus object” after getting on the bus, meaning if the statements are in reverse order the NOT SEE statement will still trigger after boarding the bus.
This is so convoluted it only seems thematically appropriate in a “robot character” game like Dan Shiovitz’s Bad Machine or Paul O’Brian’s LASH. I’m not convinced the “IF” command is that helpful in more standard text adventure games.
Convolution aside, I’m having trouble thinking of what gameplay value this brings besides macro/shortcut functionality.
It took me a long time before I even came up with the use in this post.
I could see a game where you can communicate with a robot in only set areas and they have to control themselves in other areas, so there’s a bit of a “programming game” to get them to do what they want.
Macros are useful in MUDs (a lot of the clients have them) because of the real-time aspect — it’s faster to attack mobs with a single key than type anything, and there’s a lot of repetition. Not as useful for single player turn-based games.
Pingback: Aldebaran III: Player as Conscience | Renga in Blue
Would you say you’ve given up on this one?
Nope. Kicked it up to 1980. It will return. (As mentioned in the first post, 1979 was very tentative.)
Cool. I checked, and it’s still there.
Pingback: Journey: The Deathtrap Legacy | Renga in Blue
Pingback: Warp: Endgame (part 2) | Renga in Blue