Verb-full vs. verb-minimal

 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  
Author Message
ide



Joined: 21 Feb 2006
Posts: 105
Location: Seattle

PostPosted: Wed Jul 25, 2007 5:42 am    Post subject: Verb-full vs. verb-minimal Reply with quote

You hear different arguments in game design land about how you define a player's ability to affect the game world. In most cases a player affects things by doing verbs, i.e. 'kill', 'cast'.

This got me to post a topic tonight after looking at this site,

http://www.faeriemud.org/

This mud design seems to follow the lead of most ROM [uh, I meant DIKU - ed.] deriviatives, as it's fairly common to start with a very basic set of verbs, and then add interactivity by adding more and more verbs, often a separate one for each special skill and/or system.

Then you have guys like Chris Crawford over at Storytron who advocate (I think, paraphrasing from memory) at least a thousand, if not thousands, of verbs for an expressive/interactive play experience.

On the other hand, there's the idea that the fewer verbs you have the better, as you always can combine these verbs to make more expressive actions. GW2 and its system inspired by Spellcaster is probably the best mud example to date, though it may not be quite fair to describe that system as 'verb-minimal', perhaps 'verb-unified' is a better term.

While I have I think an intrinsic aesthetic preference for 'verb-minimal', one potential advantage of 'verb-full' is it can make it much more obvious that a game world is rich and interactive -- if a player sees pages and pages of command help files, they may assume there's much more 'to do', compared to a verb-minimal approach that may still accomplish the same (or more).

Does anyone think that the verb-full approach can lead to a cluttered, and in the end non-user friendly human-computer interaction design?


Last edited by ide on Thu Jul 26, 2007 10:17 pm; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Thu Jul 26, 2007 6:48 pm    Post subject: Reply with quote

Whenever I think of "verb-full" it always brings to mind Diku, where you drink from a cup but quaff a potion, zap with a wand but brandish a staff, wield a sword but hold a stone and wear a shirt, etc.

Technically you could combine all of those options into a single use command - use a cup or potion to drink from it, use a wand to zap someone, use a sword to put it into your hand, etc. However while that would certainly make the interface easier for the player, I think it would also remove a lot of flavour.

Of course as the game starts becoming more complex, you're going to need to expand anyway - if you can both wear and wield a sword, then you'll need to support both commands. Then there's situations where you want to ensure the player knows what functionality they get from the item, so that they don't accidently kill themselves by typing "use" on a ritual suicide dagger.

As with most things, a lot of it comes down to personal taste. I would rather have separate "eat" and "drink" commands than a generic "consume" command, but I'm not sure I'd want "eat" broken down into "nibble", "devour", "gobble", etc - although no doubt there are RP-types who would love that sort of thing. Perhaps it's something that could be configured.
Back to top
View user's profile Send private message Visit poster's website
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Fri Jul 27, 2007 6:44 am    Post subject: Reply with quote

KaVir wrote:
but I'm not sure I'd want "eat" broken down into "nibble", "devour", "gobble", etc - although no doubt there are RP-types who would love that sort of thing. Perhaps it's something that could be configured.

There'd be a lot to be said for having the ability to "taste" food rather than eating it, or "sip" potions rather than drinking them.
Back to top
View user's profile Send private message
Author Message
jmurph



Joined: 19 Oct 2006
Posts: 21
Location: Texas

PostPosted: Fri Jul 27, 2007 1:31 pm    Post subject: Reply with quote

Versatility is a good thing. Having to wield a sword but wearing armor and holding a lightsource is annoying. The parser should recognize a player trying to hold, wear, wield, etc. that sword. Likewise, quaffing a potion while returning "huh?" when a player tries to drink it is just laziness. Quaff, drink, etc. should all work. Making players hunt for commands is usually a bad thing, since the parser is attempting to recognize more or less plain English commands. OTOH, a generic "use" command is a good idea for a handy default, but shouldn't be exclusive.

Allowing players to emote or otherwise customize certain output messages should address RP concerns. You could also manage output messages by condition. For example, a full person may nibble food, while a voraciously hungry one would likely devour it, manners notwithstanding. Tasting food is a clever idea, though, especially if consumables may be poisoned, contaminated, expired, etc.
Back to top
View user's profile Send private message
Author Message
ide



Joined: 21 Feb 2006
Posts: 105
Location: Seattle

PostPosted: Fri Jul 27, 2007 9:09 pm    Post subject: Reply with quote

shasarak wrote:
KaVir wrote:
but I'm not sure I'd want "eat" broken down into "nibble", "devour", "gobble", etc - although no doubt there are RP-types who would love that sort of thing. Perhaps it's something that could be configured.

There'd be a lot to be said for having the ability to "taste" food rather than eating it, or "sip" potions rather than drinking them.


I think at some point you need to decide what is up to the player and what is up to the character. While I agree that 'use' is too generic, you easily could have 'eat' result in either gobbling down the food or carefully tasting it based on the character's skill or class. In my opinion it seems overdone to have both, for example, eat and taste as verbs.
Back to top
View user's profile Send private message Send e-mail
Author Message
Vopisk



Joined: 22 Aug 2005
Posts: 99
Location: Golden Valley, Arizona, USA

PostPosted: Sat Jul 28, 2007 1:22 am    Post subject: Reply with quote

One "use" command to rule them all:

Since my current project is an LP, and that's just a little bit different... I would advocate giving all objects use() syntax. Then customizing behavior on the object level, and of course for some things, this is taken care of at an inheritance level, so one doesn't necessarily need to be re-done every time you add a new item.

Then, it's easy enough to add as many or as few verbs as you like, just telling them to call the object in question's use function. If the item has a pretty easy interface, where there will only ever be one use for it, then you don't need to ever worry about it. However, if you want to specialize it, say, tasting versus sipping, you can just pass the verb that was used to call the use function and make a conditional check that way.

I can't say that I particularly like it when I use a word which (in the english language) means that I should do X action to Y object, but get a "Huh?" response. This causes a logic error for me, and then I have to hunt through all the possible commands in the game to try and figure the correct syntax to try and do what I'm trying to do.

-Vopisk
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
ide



Joined: 21 Feb 2006
Posts: 105
Location: Seattle

PostPosted: Sun Jul 29, 2007 6:40 pm    Post subject: Reply with quote

I'm not sure if Vopisk is talking specifically about command inheritance rather than object (i.e. room, object, mob) inheritance here, but an interesting related page I found randomly is:

http://www.mud.co.uk/richard/commpars.htm

Bartle there talks a little about commands-as-objects, and the benefits of command inheritance that way.
Back to top
View user's profile Send private message Send e-mail
Author Message
caius



Joined: 12 Dec 2006
Posts: 13

PostPosted: Mon Jul 30, 2007 6:07 am    Post subject: Reply with quote

Since Bartle's ideas on parsing based on inheritance and commands as objects has been brought up, here's a series of articles where he explains it more in detail:

Introduction to Parsing
The Stages of Parsing
Lexical Analysis
Grammar
Parsing
Algorithms for Parsing
Backtracking
Backtracking that Works
Token Stream Management
The Parse Tree
The Binder
Binding Noun Phrases
Lightening the Load
A Complete Example
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Mon Jul 30, 2007 9:45 am    Post subject: Reply with quote

jmurph wrote:
Versatility is a good thing. Having to wield a sword but wearing armor and holding a lightsource is annoying.


Unless, of course, the commands actually do different things and can be applied to all three types - for example perhaps you can wield an item you want to use in combat, hold an item you want to discard should you be attacked, and wear an item you want to wear on your body.

Thus you might initially wear your sword (strapping it to your belt or back) so that it can be drawn when needed, or simply wield it to have it immediately ready for combat - but if you were just examining it you might instead hold it, so that if someone were to attack you you'd automatically discard it and draw your real weapon.

Equally you'd normally just wear your helmet, but to repair it you might need to have it in your hand, so you'd hold it - but in theory you could also wield it and use it as an improvised weapon. And of course the same would hold true of the light source, which could be thrust through (or hung from) your belt, held in your hand, or even used as an improvised weapon if necessary.
Back to top
View user's profile Send private message Visit poster's website
Author Message
jmurph



Joined: 19 Oct 2006
Posts: 21
Location: Texas

PostPosted: Wed Aug 01, 2007 3:15 pm    Post subject: Reply with quote

Very true. Most muds do not distinguish the three, however, except sometimes, oddly in commands!

I still wonder about the hold vs. wield distinction, though. By definition, one wields whatever is held in hand in combat- even if it is not the most efficient choice (your helmet example speaks to this)! Unless hold is taken more generically, of course to just mean stuff you carry around. Then, I guess, it would just move it to inventory or something. These questions are a bit beyond the scope of the OP, I think.

Regardless, the point was that having to muddle through unintuitive command structures is a bad thing.
Back to top
View user's profile Send private message
Author Message
Skol



Joined: 07 Jun 2006
Posts: 4
Location: Oregon

PostPosted: Mon Aug 06, 2007 4:46 pm    Post subject: Reply with quote

James, I did one like that for ROM quite a bit back, in my 'Taking the Duh out of Diku' phase which pops up now and then. (Basically if it seems like a 'wth?' moment, I evaluate and try to go for normal human useage).

Code:
void
do_use (CHAR_DATA * ch, char *argument)
{
   char arg1[MIL];
   char arg2[MIL];
   char buf[MSL];
   OBJ_DATA *obj;

   argument = one_argument (argument, arg1);
   argument = one_argument (argument, arg2);

   if (arg1[0] == '\0')
   {
      send_to_char ("Use what?\n\r", ch);
      return;
   }

  if ((obj = get_obj_here (ch, NULL, arg1)) != NULL)
    {
      switch (obj->item_type)
      {
// blah, tons of item types in here, evaluation based on type and conditions

/*The fun one is keys though, it checks for open/closed/locked/unlocked etc, on containers/exits/portals then will 'close/lock' if open, 'lock' if closed but unlocked, unlock/open if closed and locked. Of course you can still use 'lock north' and the usual commands as well.*/

         case ITEM_KEY:
            { // Object? (or door)
            OBJ_DATA *obj2;
            if ((obj2 = get_obj_here (ch, NULL, arg2)) != NULL)
            {
               if (obj2->item_type == ITEM_PORTAL)
               {// Portal close/lock
                  if (IS_SET(obj2->value[1], EX_ISDOOR))
                  {
                     if (IS_SET(obj2->value[1], EX_CLOSED)) // close exit
                     {
                        if (IS_SET(obj2->value[1], EX_LOCKED)) // locked
                           do_function (ch, &do_unlock, arg2);
                        else // unlocked
                           do_function (ch, &do_lock, arg2);
                        break;
                     }
                     else // open exit
                     {
                        do_function (ch, &do_close, arg2);
                        do_function (ch, &do_lock, arg2);
                        break;
                     }

                  }// End Is Door (if not it just tells you you cant)
               break;
               }// End Portal
               else if (obj2->item_type == ITEM_CONTAINER)
               {// Container Code close/open lock/unlock
                  if (!IS_SET (obj2->value[1], CONT_CLOSED))// It's open already
                  {
                     do_function (ch, &do_close, arg2);
                     do_function (ch, &do_lock, arg2);
                     break;
                  }// end open
                  else // the container is closed
                  {
                     if (IS_SET(obj2->value[1], CONT_LOCKED))
                     {
                        do_function (ch, &do_unlock, arg2);
                        do_function (ch, &do_open, arg2);
                     }
                     else // It's not locked
                        do_function (ch, &do_lock, arg2);
                  }// end closed check
               }// End Container Check
            }// End portal/container check
            else // Its an exit
            {
               extern int find_door args ((CHAR_DATA * ch, char *arg));
               int door = find_door (ch, arg2);
               EXIT_DATA *pexit;
               pexit = ch->in_room->exit[door];
            
               if (!IS_SET (pexit->exit_info, EX_ISDOOR))
               {
                  send_to_char ("That isn't something lockable.\n\r", ch);
                  break;
               }
               else
               {
                  if (!IS_SET(pexit->exit_info, EX_CLOSED)) // open door
                  {
                     do_function (ch, &do_close, arg2);
                     do_function (ch, &do_lock, arg2);
                     break;
                  } // end open door
                  else // closed door
                  {
                     if (!IS_SET(pexit->exit_info, EX_LOCKED)) // unlocked
                        do_function (ch, &do_lock, arg2);
                     else // It's locked and closed, unlock/open it
                     {
                        do_function (ch, &do_unlock, arg2);
                        do_function (ch, &do_open, arg2);
                     }
                     break;
                  }
               break;
               }
               // And just in case we missed anything.
               sprintf (buf, "%s", arg2);
               do_function (ch, &do_unlock, buf);
               do_function (ch, &do_open, buf);
            }// End door check
            }
            break;


Another fun one is whetstones with weapons, you 'use <stone> <weapon>' and it holds stone, sharpens weapon (attempts). Use cork potion will put the cork in the potion assuming it isn't already corked etc.

I find it simply allows people to get past the 'You must QUAF potions'... if the code realizes I want to imbibe the thing, suck it down and stop telling me in codenazispeak that I need to enter a different command. A simple call within say 'do_drink' that does quaf if it's a potion, and it's all good.

I do see a use for things like KaVir's though, if you want to hold vs wield etc (assuming your code has that). So use would do the most obvious useage, but perhaps other commands still would be there to do things such as 'hold' rather than 'equip' etc.

(btw, sorry on the use key code, it looks kind of long )

Ps. Use potion will check for, and remove corks or stoppers as well. As the game should be smart enough to realize you probably don't want to eat the brass stopper. Though, it will kid you some saying 'The brass stopper might taste funny.' You remove a brass stopper from a potion of invisibility. You quaf a potion... etc.

Just because we make it more intuitive, doesn't mean we can't make fun too Smile
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign