kaern
September 10th, 2008, 03:30 PM
Here is a draft for a set of changes that might work to keep code minimal, not clash with the existing MUD interface, and make things comprehensible for players.
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 [in the God+ thread], 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 to the room 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 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.
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. Then there is no need for command blocks for mobs and objects, so we don't worry about getting into a tangled mess trying to prioritize conflicting command blocks. Creating new interactions with mobs/objects are outside the scope of this proposal and would still fall under specially-coded mobprogs, etc.
Every possible functionality for a command block, whether it's a simple echo of a description or a item falling from the sky, 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 could bring unforeseen types of interactivity to the game. The possibility of room-specific commands would be a good first move.
3. Descriptions with a newline followed by the characters "> " (a greater than sign, and a space) have color tags inserted either for the whole line or just the greater-than symbol. Depending on aesthetics and practicality, the colors and choice of prefix chars ("> ") can be decided on later. The gist of this is to have information stand out to the player that is not part of the usual description.
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.
Second, the subtext of a color change is that the context is no longer the same (i.e., this room is not exactly the same kind of room you've been seeing for the last 12 years). A small color highlight would go a long way in communicating that there is something new happening.
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> ". And 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. Improve on these ideas and let's expand the toolbox so we can make some rockin' areas!
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 [in the God+ thread], 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 to the room 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 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.
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. Then there is no need for command blocks for mobs and objects, so we don't worry about getting into a tangled mess trying to prioritize conflicting command blocks. Creating new interactions with mobs/objects are outside the scope of this proposal and would still fall under specially-coded mobprogs, etc.
Every possible functionality for a command block, whether it's a simple echo of a description or a item falling from the sky, 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 could bring unforeseen types of interactivity to the game. The possibility of room-specific commands would be a good first move.
3. Descriptions with a newline followed by the characters "> " (a greater than sign, and a space) have color tags inserted either for the whole line or just the greater-than symbol. Depending on aesthetics and practicality, the colors and choice of prefix chars ("> ") can be decided on later. The gist of this is to have information stand out to the player that is not part of the usual description.
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.
Second, the subtext of a color change is that the context is no longer the same (i.e., this room is not exactly the same kind of room you've been seeing for the last 12 years). A small color highlight would go a long way in communicating that there is something new happening.
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> ". And 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. Improve on these ideas and let's expand the toolbox so we can make some rockin' areas!