Expanding the Area Writer's Toolbox: A Case Study

[kaern]

The area I'm hoping to resume, Autumncrest, was originally halted due to technical challenges which I'll describe in part below. This thread was originally posed as a question in the God+ forum but I've since come up with a set of possible solutions that hopefully also serves as a good foundation for future areas to be more AWESOME.

This first post is about the problems I encountered + examples of what I am trying to do, and the second is about a set of possible solutions. Please help me improve on this!

The Problem

On the heels of the Mystic Wood I wanted to create another puzzle-based zone, but rapidly I discovered that the types of puzzles I wanted to make were probably too difficult to implement with the existing area writer's toolbox.

For example, in one room I have a book, a translator of sorts, where a player can look up words he/she finds in the area to make sense of them. This is not a complex idea, but how to implement it? What does a player type to "look up" a word? My existing solution was to create a set of rules on top of the area, which enabled players to create and combine keywords as they discovered more information. This however is unwieldy in practice, at least in its current form.

To be specific, here is what it looks like when you enter the room and look at the book:

This dog-eared book must have had its share of travels.  Its cover, along with
some pages off the beginning, is missing, and the upper right corner has been
singed--though thankfully not far enough into the pages to reach the words.  A
quick flip among the silky-thin leaflets reveals the words to be
extraordinarily tiny...and half of them unintelligible!

The words "Dolteo ve'Presa" stand at the top of every page: probably the
book's title.

Elsewhere, there are words in the common tongue, but phrases are brief and
intermittent, and always in quotes.  The rest of the language appears to be
composed of the same alphabet and organized under larger headings which the
scribe took extra effort to emphasize.

For example, under the heading "Pilo Jenefare Quis" you see:
"Aphorism.  The bearer of water never sits with her back towards the rising
sun."  Hene ve'Tornuca chardor pequin ore sit.  Te lorien fren, rewerd
io-nasce hintress ware binotene.  Fruti chena io-nasce ve'Tornuca yerte lor. 
Wi bibloporenta, per noloco fruti chena...

The next heading is "Pilorne" and the only understandable content is: "Deity. 
The goddess of four-winged flies, who lives in a magnificent boggy marsh in
the clouds."

Three pages later, "Pilorne Ater'o" has this to offer: "Book.  The fairy-tale
of the insane dwarven goddess, Yolanthil, who bred a kingdom full of frogs to
herald the fall of Pilorne."

It appears that the headings, though meaningless to you, are arranged in
alphabetical order.  It would therefore be possible to look up foreign words
in here for the relevant commentary in Common.

>translate{foreign term}

The weird line at the end beginning with ">" is part of my current "solution" of meta-area "notes", where I am telling the player how to interact with the area above and beyond the usual walking around, killing things, and collecting items. Here they can now look up words in an archaic language to see what they mean.

To illustrate, let's say the player encounters the word "Tessimus" somewhere else in the area (which in all probability will be given by an area note as well, e.g. ">Tessimus"). She can then come back to this room and type "look translatetessimus" and read what it has to say.

In all likelihood, this is far too complex for the average player to figure out. And the last thing I want is an unintuitive, cumbersome system. As I see it there are multiple barriers to understanding:

1. Recognition of "area notes", being able to see something like ">" and knowing what that means.
2. The syntax of area notes: learning that "translate" is part of a keyword, and that it can be combined with something else.
3. The semantics of area notes: the choice of the partial-keyword "translate" is very important because a meaningful connection must be established between the partial-keyword and what the player is actually doing, i.e. it must be intuitive to look at "translate{something}" and know that one is actually, inside the character that is, looking inside this book, searching it for a word, and reading out its dictionary entry.

To me #3 is the most difficult part to get right, even if the first two challenges are hard enough. I have tried to tackle #1 and #2 via HELP AUTUMNCREST, and by alerting players to the help file with this in the first room of the area:

Slipper Beach
[Exits: up south]
Outside once again, you and your trusty vessel wash up ashore onto a small bed
of coarse orange sand, enclosed on all sides by rock.  The rock, a deep, rich
maroon, includes an elegant arch curving from east to west, and further
invites wonder by appearing not only astoundingly smooth, but also as if the
entire affair is one single piece.  What must have taken millenia for wind and
water to carve is now the extraordinary shape of a graceful slipper, beach for
heel and cave for toes.  It is a somewhat gloomy gracefulness, however, due to
the wispy drape of fog blocking your view of anything up beyond the foot strap.

>Welcome to Autumncrest.  HELP AUTUMNCREST may aid your exploration.

But challenge #3 can lead to a pretty confusing system when keywords are very abundant and especially when I started adding abbreviation guidelines for the keywords when they become very long. Anyway, that is enough for now in service to the current solution, which we can probably agree is not viable. The question is what is possible?

The example I have presented above--namely how to make a translation service available in a particular room in a way for a player to know how to interact with it--is but one of many kinds of "info management" I am attempting to introduce with this area. Each kind possibly presents its own challenges, but I feel that if we could tackle this problem and make something very simple and very understandable for the user, it may open the door for me to be able to think about the other issues from a similar standpoint and come up with effective solutions.

My questions, then, are:

* Are area notes really necessary? If so, how best to present them, and how can it be intuitive for the player to see/use and even learn to combine keywords with them? If not, how would we inform the player of complex goings-on such as telling them they can translate foreign words with an in-room dictionary?

* How feasible are custom commands for rooms, such as where the player can type "translate tessimus" instead of "look translatetessimus", the latter requiring a much bigger mental jump? One challenge is merely informing the player that this is possible; another is coming up with a way to do this for other things too and making sure that we don't clash with any existing MUD commands, which may be impossible.

[kaern]

A Solution

Here is a draft for a set of changes to keep code minimal, not clash with the existing MUD interface, and make things comprehensible for players. It addresses the issues above head-on, while providing a foundation for other area writers to do unbelievably cool things.

1. New command: "room" or "/".

"/" is a synonym for "room", both of which allow for room-specific commands. This way an area can specify room-specific commands without worrying about interfering with global commands or any other room-specific commands, since all commands would need to be preceded by the word "room" or the "/" character. Also, typing "room" by itself might straight-up tell you: "There are no room-specific actions available here" if there are none available, with the same intent that moving in a direction (as a mortal without pass door) tells you if there is a door there or not. Maybe.

2. Room definitions in area files have optional "command blocks", like extra description blocks but for the purpose of defining room-specific commands and what they might do. A simple example would be the one I gave above, which is a glorified extra description triggered via "/translate xxx". A more complex example would be the player types, say, "/pull lever", and is translocated another room (e.g. the one below), or has a spell cast on them, or a door may open elsewhere. There are tons of possibilities here of course -- we'll leave brainstorming those and figuring out the command-block syntax for later.

Note that in the "/pull lever" example, the area writer could specify that "/pull" might echo "What do you wish to pull?"--in effect, the author has the ability to create more of an experience. In general, all room-specific commands will have a room-echo (recho) associated with it since there will always be a need to inform the player what is going on.

One useful thing, as well, would be if command blocks have the capability to check if a mob or object vnum is in the room or on the player.

Every possible functionality for a command block, whether it's a simple recho of text, or an item falling from the sky (item creation + recho), is obviously its own coding task, requiring thoughtful implementation and testing. The idea here is to start with a framework for command blocks, and then frills can be added in the future much the way specfuns are added to rooms themselves. The potential is limitless and brings unforeseen types of interactivity to the game.

3. Descriptions with a newline followed by the characters "> " (a greater than sign, and a space) have color tags inserted either A) for the whole line or B) just the greater-than symbol. Depending on aesthetics and practicality, the colors and choice of prefix chars ("> ") can be decided on later. Basically we want information that's not part of the usual description, visually stand out.

This serves two purposes. First, I believe it's important to have room metainfo be separate from actual descriptions. The only exception to this may be the New Player Entrance and the mud camp, but for everywhere else when you are looking around the world, you don't want "Type HELP AUTUMNCREST" popping up at the end...it's out of place. For the original example, I'd need to be able to tell the player: "'translate xxx' will allow you to look up words in the book." There is no in-game way of saying this; it must be directed at the person sitting at the computer.

Most importantly, a color change signals new context. Namely that this room is not exactly the same kind of room you've been seeing for the last 12 years.

Note that this applies to all descriptions, such as mob and object and room extra descriptions as well. Code-wise these are probably handled in different places but perhaps a function could be written to pass in descriptions right before they are echoed so that they can be parsed for the special char combo, e.g. "newline> ". All we're doing is adding color tags.


In summary, it seems these three new features would address the challenge of adding interactivity to zones while keeping the player informed of what's going on in a simple way.

[Tokugawa]

I'm a little confused.

Your solution is also posted here. in The Next Great Idea forum from September of this year. I have no idea how feasible this might be. But what would really be nice is to have a framework in which we can modify room, object and mob programs easily. Right now they have to be hard coded for each case I believe.

To address your proposed solution. The problem is coding resources and the viability of your proposal. Schwartz, Tynian or Natilena would have to comment if this was viable, and then see if they had the time to implement it.

-Tokugawa

[kaern]

Sorry for the confusion. I've cross-posted because the thread in Ideas is incomplete (not having illustrated the problem, which was posted in the God+ thread). Here they are finally together, in a forum dedicated to area writing.

On implementation: I am just hoping one of the area gods will just read it through! And I would be so thrilled even if we could just create room-specific commands that recho'ed text. It would provide so much of a richer experience and platform for interactive storytelling.

[Ylang]

I love the idea, in principle.

I've written half an area, and have a number of places where I can only approximate what I actually have in mind, but where I could do a lot more with such room-specific commands. For example, I have challenges set in rooms, which are supposed to be magically placed there, but the correct action is rather more basic and intuitive (within the current options) than I'd like. True, it's probably 'good enough'. There's a narrative attached to each solution, and some cute intertextual references. However, the implementation remains less than satisfying.

It would indeed make things a lot easier if mob-progs and the like could more easily be created, by the (non-coding) area writer, right along with the mobs, objects and rooms themselves. If that is a feasible project, it would probably be a better investment of time and effort than just implementing area-writer-specified room commands.

All that waffling, just too avoid a one-line I agree note *grin*

[Tynian]

Making mob progs and such more customizable and usable by area writers is something I'd like to do. Anything that gives areas a more interactive feel is a change to the good. It's a large undertaking, which is why I haven't gotten far with it, myself.

[kaern]

Perhaps we can look at the big picture and see how it would be divided into bite-sized coding tasks, then assess how feasible they are.

Room progs: this thread is basically an outline for how room progs could be implemented (I called them room-specific commands).
Mob progs: seems this could also be implemented through an extra block, attached to where the mob is defined in the area file.
Object progs: likewise they could be defined in where objects reside in the area file.

Maybe we can move a step forward to making all of these possible by separating the ACTION taken by a player from the REACTION from the game. That way, the action could be triggered by a room/mob/object prog, should we choose to implement any, leading to a reaction from the game that could be triggered by anything. This warrants a REACTIONS block with its own vnums, like so:

#REACTIONS
#20000
...
#20001
...

Reactions could then be triggered via room/mob/object records. They could be specified much the same way extra descriptions are, but instead of E we could use A (short for ACTION):

#ROOMS
#20000
Ylang's Apartment~
With nowhere to go, you are sitting in the branches of a baobab tree.  You see a red button.
~
200 1 3
A
20001
'push button' 'push red'~
You depress the red button.
~
A
0
push~
What do you want to push?
~
S

The A subsections specify links to the REACTIONS block. They include at least a number specifying which reaction to trigger, the command(s) that trigger it, and a recho. The second instance above, having a 0 for the reaction reference, does not trigger anything beyond the recho. Additional parameters could include vnums of objects which must exist on the player, or mobs that must be in a certain room, and so on: we could leave space for possibilities without implementing them yet.

Possibly the larger task is to figure out what REACTIONS records look like. I think the most flexible way, even though it is the most dangerous, is to allow them to execute god(+) level commands directly, much like a sudo in Unix does, so that a reaction could basically do "at [player] cast 'immunity' [player]" or "transfer [player] 20099". Let's update our example:

#REACTIONS
#20000
at 20066 cast 'sanctuary' 20066~
#20001
transfer [player] 20099~
at [player] recho The air shimmers.~

I know the syntax is inaccurate. But here's what we're going for: Reaction 20000 casts sanct on mob 20066. Reaction 20001 transfers the player to room 20099 then room-echoes "The air shimmers." "[player]" is just shorthand for code that will allow the game to recognize and act upon the player triggering the reaction (the syntax would definitely be different).

There are advantages to implementing progs this way.

* Having their own block, Reactions are easily identifiable and can be evaluated for appropriateness/gameplay balance. Much the same way Objects are looked at to make sure we aren't putting avg50 weapons in the game.
* Separating actions from reactions (say, as opposed to existing mob progs which specifically tie consequences to what triggered them) allows for fantastic flexibility: a player's actions in a room can affect mobs elsewhere, something done to an object can open doors, etc.

Thoughts?

[kaern]

An error recurring throughout the ideas proposed above: most of the time I mention room-echo, or recho, I should have said text directed at the player (which isn't a recho). More accurately, we will probably want to be able to specify two separate chunks of text, much like the way socials are defined, so there is personal text and text for the room.

[Cordir]

Kaern:

I don't know if this is an overly simplistic means of achieving a small smidge of what you're talking about, but...

What about a #help file as part of the area? I know Thaygar had #help EBON TIME and I think Nyx/Jahiliya had some #helps written as well... if they could figure out the word to use, and do a HELP query, they'd get the text...

Just a thought,

-C

[kaern]

Thanks Cordir...Good suggestion, but there are two big problems with this:

1. All HELPs are listed under the 'index' command. Thus none of the help keywords could actually be secret.
2. Even with a better information delivery system we still have no way of having anything else happen (aside from delivering information).