Messages

[Today's Theme: Draw a character with the theme "Lycanthrope"]

Today's Theme: Draw a character with the theme "Lycanthrope"
morganw:
[imgzoom]https://www.dropbox.com/s/rwqacthgf932hl6/ww.png?raw=1[/imgzoom]

Babar:


CassieBSG:


Creamy:

or you can make the verb coin appear, and have the use command pick it up so you can use it, thus annoying the hell out of you since you always have to click twice to use an item.

But every single interaction with the verbcoin is already like this- you always have to click twice to use do anything at all. Why would it being in the inventory bother someone more?
This is the solution I was using for my system, along with an inventory that pops down when the player moves the mouse to the top of the screen (since one of the advantages of verbcoin is that it doesn't take permanent screen space, I assumed that was important, so I didn't have a permanently onscreen inventory). Is there something wrong with it?

Ah, ok, so why can't you do the same with a radial or arc menu? Just offset all of it when you're near the edges.

I could do that, yes. Would that make it better, though? I thought the point and advantage of radial menus was that you could reach every action with an equal mouse distance? If the mouse is not centred in the menu, that would no longer be the case, then.

Can't you just reconfigure the keybindings in the game's settings? Or is it one of those rubbish console ports that don't even have that option?

Context sensitive verbs wouldn't be exclusive, no. It's just the only way I can see a verb coin being useful. The game I was wanting to use such a system in had one character with fingerprinting, using a taser, and taking pictures as interactions.

Isn't that all doable (and in fact more intuitive) through inventory items?

Exactly the opposite. Because it's dynamic, you can just have a "look" for the windows if you want to, whereas with the static verb-coin you HAVE to have filler actions for interact and talk even if you have no meaningful action to provide (or do the annoying "can't do that" default action).

But then you face the problem I mentioned before the "or"- If your only options when you click the piano is LOOK and MOVE, it becomes a bit spoilery, no? I realise two-click systems have the same issue, but it somehow seems worse with context sensitive verbs, because it actually lists it all out.

Hmmm, maybe, but how would it work in practice, though?

I had just imagined 4 (or so) empty verb slots at the bottom of the screen, and when you mouse over something, they fill up with the possible actions you can take. Clicking on an interactable on screen would solidify those options, so then you can click one of them.

I meant that there will not be a radial menu, that the menu will always be in arc form and auto adjust based on the number of verbs and placement. And yeah, it won't be consistent, especially near the edges, but I think it can work regardless. Is it consistent around the edges in your current design?

The positions of the buttons relative to each other is always the same, but the position of all of them together relative to where the user clicked is not. As I said, currently it's just a fixed GUI, not a radial/arc menu.
eg:

vs:

Hahah...that would be sad solution. But is it a reasonable expectation from someone making a game? I know that you have all those implicit assumptions with other UIs as well (game dev can't utilise a fullscreen background in the classic LucasArts system, or game dev can't place stuff to close to the top in Sierra's Iconbar system, and game dev can't shouldn't have items/people so near the edge of the screen that it'd trigger them walking to the neighbouring room), but this limitation seems particularly egregious, no?

But then again, is having a radial/pie menu, or having a menu that consistently pops up in the same place relative to your click more important UX-wise, than having a menu that readjusts its position or placement of buttons depending where you click?

Also, VampireWombat, I'm still not seeing why context sensitive verbs would be something exclusive to verbcoins? I mean, aside from two-click systems (the ultimate in context-sensitive interaction ), any UI system could be context sensitive.
It's just that the more verbs you have, the more cumbersome it would become- but for most cases, I feel it would be an incredibly rare situation that any interactable would have more than 4 interactions. You'd usually have a look for most things, maybe another talk/use for people/items. Maybe some rare people would have look, talk and use/push, or some items would have look, use, pick up, and the very rare item could have something like look, push, open, pick up (for something like a box?).

Is the verbcoin a useless or substandard UI if it doesn't have context-sensitive verbs?

I'm not sure I'd be a fan of dynamic context lists of verbs (potential to either spoil solutions or be required to provide loads of filler outlandish actions), but is that really something exclusive to verbcoins? You could have a LucasArts style verblist that fills up with context sensitive verbs (up to 15 if you go by Maniac Mansion).

Also, reading up on radial menus in an attempt to get something good gave me a LOT of research about how non-radial context menus (like what pops up when right-clicking) are really inefficient, user-performance-wise.
The only other option would be, as you mentioned, to have a large but set list of actions with corresponding icons, some of which (to a set maximum) show up depending on context when the player clicks on something.
Cassie's system in her BSG game does something similar, although it only draws from a pool of 4 actions (shoot, look, use, talk), the unnecessary ones for each interactable on screen are hidden away when that interactable is clicked. In the spirit of generalisation, I suppose it is something I could implement, but I'm still not sure about the general consensus on this: Are varying lists of context-relevant actions for each interactable something that people want, and would be good?

Finally, your point about using arcs, I'm not sure I understand, could you please explain? The way I looked at it, lets say for simplicity, we have a total of 3 interactions (LOOK, USE, TALK), clicking something on screen would pop up a radial menu around that point, with those actions. If there's something near the upper right corner to interact with, however, those 3 actions would have to be either squeezed together in the lower left (and even for just 3 buttons on a radial menu, of half the size I have them now (16px instead of 32), that's a tight squeeze depending on how far in the corner the item is- and probably not work for 320x200. Or the buttons would have to be moved further away from the interactable, again making behaviour inconsistent.

Thank you both for your suggestions! I'm implementing what I can right now.
I'll keep the verbcoin closing system as it is right now, with the addition of the right mouse button to close it.

I currently had the whole verbcoin, as 4 buttons, each a circle and symbol on the circle as a single button. I suppose I could separate it, to make them transparent/smaller, but I'd like to be clear as to the isssue I'm solving. Are the buttons too big? Is it bothersome to not be able to see behind them? I think I made the mouse pointer too big as well .

You are right about the inventory not being openable if there are no interactables on screen, so I guess I should move it. Maybe I'll do it as a pop-up modal like the Sierra iconbar, along with the settings. So I'm down one button in the verbcoin. You sure I shouldn't put an X there? Or maybe I can have the inventory openable from there as well as from moving the mouse up? That probably wouldn't make sense. Or just leave it at 3 icons right now?

Hey all!
I've never seen a well implemented verbcoin, but people keep telling me that there's this hypothetical verbcoin that is really the best UI ever. Since I can't find it (side note: if you've made one, please share, the verbcoin template that comes with AGS counts as one of those horrible ones, and I've seen people complain about the template available on these forums as well), I decided to make it myself. And for that, I need your help!

Some design points I gleaned from these forums on what is the best kind of verb coin:

• Left-clicking where there's no interactable makes you walk there
• Left-clicking where there's an interactable opens up the verb coin around the point you clicked
• If you click in a corner, the verbcoin opens such that it would fit on screen
• Interactions are LOOK, USE, TALK and OPEN INVENTORY
• Right-clicking does nothing (although I don't think I'd ever want to make a generalised UI for both PC and mobile, apparently it's important)
• Clicking outside the verbcoin closes it
• Moving the mouse around without clicking shows whatever is under the mouse (not relevant to mobile, though)
• The eventual game would have keyboard shortcuts, but I've not currently implemented them, as I wanted to get a feel specifically for the verbcoininess of this system

So what I came up with (I can share the entire game if you like, but I'm not sure it's necessary just at this moment):

(don't be bothered too much by those things in the corners, those were just to test the literal edge cases)

Code: ags

// main global script file
int verbCoinX, verbCoinY;//stored coordinates of whatever the user clicks to have the verbcoin pop up


function repeatedly_execute() 
{
  if ((gVerbCoin.Visible==false) && (tLabel.Text!=Game.GetLocationName(mouse.x, mouse.y))) tLabel.Text=Game.GetLocationName(mouse.x, mouse.y);
  // gVerbCoin is the Verbcoin GUI, tLabel is the label showing what interactable is under the mouse
}

function on_mouse_click(MouseButton button) // called when a mouse button is clicked. button is either LEFT or RIGHT
{
  if (IsGamePaused() == 1)
  {
    if (gVerbCoin.Visible==true)
    {
      if (GUI.GetAtScreenXY(mouse.x, mouse.y)==null)
      {
        gVerbCoin.Visible=false;
      }
    }
  }
  else if (button == eMouseLeft) 
  {
    if (GetLocationType(mouse.x, mouse.y)==eLocationNothing) cCharacter.Walk(GetViewportX()+ mouse.x, mouse.y, eNoBlock, eWalkableAreas);
    else
    {
      verbCoinX=mouse.x;
      verbCoinY=mouse.y;
      if (verbCoinX<gVerbCoin.Width/2)gVerbCoin.X=0;
      else if (verbCoinX>System.ViewportWidth-gVerbCoin.Width/2) gVerbCoin.X=System.ViewportWidth-gVerbCoin.Width;
      else gVerbCoin.X=verbCoinX-gVerbCoin.Width/2;
      
      if (verbCoinY<gVerbCoin.Height/2) gVerbCoin.Y=0;
      else if (verbCoinY>System.ViewportHeight-gVerbCoin.Height/2) gVerbCoin.Y=System.ViewportHeight-gVerbCoin.Height;
      else gVerbCoin.Y=verbCoinY-gVerbCoin.Height/2;
      gVerbCoin.Visible=true;
      
    }
    
  }
  else //Right-click, which does nothing right now
  {   
    //Room.ProcessClick(mouse.x, mouse.y, eModeLookat);
  }
}

//If the player clicks the LOOK icon on the verbcoin
function bLook_OnClick(GUIControl *control, MouseButton button)
{
  gVerbCoin.Visible=false;
  Room.ProcessClick(verbCoinX, verbCoinY, eModeLookat);
}

//If the player clicks the USE icon on the verbcoin
function bUse_OnClick(GUIControl *control, MouseButton button)
{
  gVerbCoin.Visible=false;
  Room.ProcessClick(verbCoinX, verbCoinY, eModeInteract);
}

//If the player clicks the TALK icon on the verbcoin
function bTalk_OnClick(GUIControl *control, MouseButton button)
{
  gVerbCoin.Visible=false;
  Room.ProcessClick(verbCoinX, verbCoinY, eModeTalkto);
}

So what I'm asking help for is to make this system as user-friendly as possible, and to have the code as generalised as possible (so it can be made a template for any game), and if there are any potential bugs or improvements. I don't really need help with the art, but if you're willing to provide something I can use better than what I'm using now (thanks, cat! ), then I'd be more than grateful to use it.

Specific things I'm currently unsure about:

• I had initially thought to use radial menus, because apparently they're the best, but ran into issues with screen edges. Along the edge, I'd have to rearrange the button positions, and depending on the number and size of the buttons, and whether the click is near the corner, the buttons would not fit. So currently, it's just a GUI with 4 buttons in fixed positions relative to each other. Does someone have a suggestion that would make radial menus viable, or is it fine as is?
  
• I'm assuming there's an optimal size of Verbcoin/buttons/mouse to screen ratio. If someone can point to a better one, I'd appreciate it. Currently the resolution is 320x200, the verbcoin buttons are 32px large, and spaced 70px away from each other (corner to corner, not centre).
• CrimsonWizard in another thread suggested a system where once the verbcoin is opened, the mouse pointer would disappear, and one of the buttons would be highlighted to be clicked, moving the mouse in another direction would highlight another button. This system would have the issue of requiring another button to close the verbcoin, and would require a rethinking of the button placements. Is it worth it? Would it be better?
• Verbcoin currently closes when you move the mouse out of the verbcoin range. Should an X button be added to be able to explicitly close it? Or some other system to close it?
• I just randomly set the current buttons and their placement. Do you feel something else would be better? Should inventory be there, or be opened through something else? Disadvantage of having inventory only through the verbcoin is that you may want to check your inventory without wanting to interact with something on screen. What about a settings menu? Where would these go if they weren't in the verbcoin?

Sorry for the long post (hope that doesn't translate to a lack of responses), and thanks in advance for all your help!

You realise you're going to have trouble if you try and release this game, right?

---

Grim Fandango was simply inspired by the same thing that Coco was. It would make sense that the two would share imagery.

Picking up objects whenever you want has the advantage of



• letting the player play at their own pace
• not running the risk of a situation where the player knows what to do, but can't do it yet
• having no confusion as to whether an object is pickuppable or not

Picking up objects only when needed has the advantage of



• avoiding situations where the player is just picking up everything to try on everything
• giving the designer a greater control and awareness of where the player is at any point in the game
• seems more "sensible"

Personally, I feel that the advantages provided by only allowing players to pick up items when needed are outweighed by the advantages of allowing them to pick them up whenever they want, so I usually go with the first method. If you go with the second, make sure right from the start that the player is aware of it (maybe in the first room have an obviously pick-uppable item like a gun lying on the desk, and when the player tries picking it up, say "I may need it later, but I don't want to lug it around right now").

Solutions that avoid needing to make this decision include:



• the player wouldn't come across objects they can pick up before they need them
• create an inventory management system so that the player has limited inventory slots, and there are more objects in the world to pick up than are needed
• create an inventory system where whenever the player looks at an item, it gets stored in their "inventory memory" (which can perhaps double as dialogue topics), and when the player wants to use the inventory item with something, they select it from their inventory memory, and the screen fades out to show the player going back to get the item, and fades back in with the item in hand to use there

...lists are fun!

I'm not sure I understand what you mean about buttons being infinitely wide in SCUMM / Sierra interfaces? Surely distance is a factor too? In those interfaces the mouse has to sweep all the way across the screen, whereas the verb-coin puts the buttons right next to the thing you wanted to interact with.

Fitts's Law involves width of the click target, and distance to the click target. If one assumes that a mouse is being used (rather than it being a touchscreen), then for buttons that are along the edge of the screen, their width would be "infinite" along the direction of motion, because you can't go beyond the edge of the screen.

I'd say there are a lot more factors than the ones you listed, cat, but just wanted to point out that "Covers screen space" should probably more accurately be divided into "Uses up screen space that could be used otherwise" (eg. verbcoins in earlier LucasArts adventures, inventory in first Kyrandia, I think, etc.) and "Covers the playable screen" (eg. verbcoins, Sierra's VGA games, partially).
And technically, the number of interactions in all of them (except the last two) could be as many as the dev chooses (or can fit on screen)

Also, I'd say a more scientific use of ergonomic might be better. I think I remember the last thread about verb coins brought up Fitts's Law, which is quite useful here. So something like the LucasArts or Sierra verblist, with the buttons along the edges of the screen is actually MORE ergonomic, because the size is infinitely wide (in the case of Sierra; In LucasArts verblist, the lower buttons are infinitely wide, but the buttons themselves are quite large as well, so I'd say they are still ergonomic- and all this is talking about mouse, not touchscreen or mobile). Verbcoins, however, tend to be fairly small (otherwise they cover up too much of the screen, which is bad), so that can make them unergonomic.

Judging from my preliminary investigations, at least in terms of Fitt's law, verbcoin vs Sierra/LucasArts could be almost equal, but if we're talking about the hypothetical "perfect" solution, well done verblists could probably still win out (again, the limitation that verbcoins can't be too large comes in).
I'm trying to find a game screenshot to be able to approximate the values, but I'm tired and this seems complicated (the way players would use the two systems aren't really the same, so I'm being sure how to make them comparable). Someone else do the hard work? You might prove that verbcoin is even better (at least insofar as Fitts's Law goes) !
As a side note, talking about Fitts's Law, I started wondering why LucasArts didn't put the more common interactions (I'd say maybe Use/Talk/Look, or something other than Look if people figured out the right-click shortcut) right at the bottom...

PS: I just tried BaSS right now because I didn't really remember it, and I think it gives a very interesting solution for the "People don't even realise they can click the other mouse button" problem. With the right click to interact, left click to walk/look, as a casual player, you would begin by left-clicking stuff, which gives very obvious "Look" responses, but there's no way to continue without interacting with stuff, so you'd end up right-clicking (people might not think to click and hold the mouse, but they would eventually right-click, I think).

You'll want to include the AGI SQ0

I doubt most people outside of AGS even know what a verbcoin is, so you're not going to find people complaining about "verbcoins". And if this is their only experience with the game, they probably wouldn't be able to even pin down exactly what is bothering them about it (unless they're game devs, perhaps, and look at it through that lens).
For the Day of the Tentacle Remaster, however, going through the reviews, especially of people who played it back in the day, nobody is comparing the new interface favourably to the old, in fact, I am seeing complaints about the context sensitive wheel giving spoilers, and that you can't walk and interact with stuff.
EDIT: at the thread title

What about "ability wheel" kind of UI, where regular cursor gets locked and/or hidden, and verb highlighted depending on the direction of mouse move? This prevents from misclicking outside.
This may still need to complement with touchscreen somehow.

That seems like a cool effect, but will probably make the other kind of misclick even worse: when the player clicked the wrong object on the screen in the first place, there would have to be a "CANCEL" option among the other verbs (or right-clicking to cancel?)

I just find the verbcoin to be a compromise UI system that takes the worst of both worlds and adds some extra problems of its own. I honestly can't think how a game would be better served with it rather than something else on either side. Obviously I can't say without seeing something like that in action, but even Snarky's example, which I'm imagining would be something like Lure of the Temptress seems it would be either too complex with too many possibilities (and spoilers or jokes- "Oh, I can squish the knife inside of the cake? Great, so THAT's how I am able to get it to the guy in prison! And here I was just planning on cutting a slice"), or too simple and thus unnecessary.
The verbcoin as it was used, had 2 advantages that I could see, either of which could be done better with another system, but the combination of both being what seemed to necessitate it:
- Verbcoin clears up screen real-estate (except two-click, one-click, or even Sierra iconbar pop-up systems do that better)
- Verbcoin allows greater choice of action (except the verblist does that better)

To list down the most perfect possible implementation of the verbcoin (culled from comments here):

Left-clicking where there's no interactable makes you walk there
Left-clicking where there's an interactable opens up the verb coin
What does right-clicking do? Is it unnecessary? A shortcut for the most common/obvious interaction?

The verbcoin opens in such a way so as to not block what you want to work on.
It makes a frame around the object (could be distracting), or it opens offset
Near the edges of the screen, the verbcoin that pops up will have to be displaced differently, making where the player has to move the mouse after be an unfixed thing.

The verbcoin has to be designed so as not to be so big as to cover too much of the screen, but not so small so that there isn't constant misclicking. What is this size in proportion to the size of the screen?

Will the verbcoin pause the gameplay when it is opened? This seems to be the more traditional behaviour, but it causes things on screen to be covered if there are lots of moving bits, not to mention how the verbcoin itself is covering stuff. If the verbcoin was not paused, however, we'd have it worse, with things happen that we can't see clearly, and if we made a mistake with what we clicked, we could be in trouble.

Speaking of making mistakes, how would the verbcoin handle a misclick?
Simply moving the mouse out of the UI space can cause it to close, but this could lead to problems where the UI is constantly unintentionally closed (goes back to the issue of the perfect sweet-spot size of the verbcoin),
The other option is to have the player click outside the UI region, and click again what they actually meant to click.

That screenshot reminds me of another thing I dislike about verbcoins specifically used by Windows: Placement isn't always consistent, so you can't automatically move your mouse to the option you want. As an example, if I want to select a bunch of files one at at a time to rename them, once I get to the end of the screen, rightclicking pop up the menu in a different place than usual, so your flow is disturbed.

So yeah, verbcoins are a horrible interface, and anyone who uses them should be locked up in a room with a slider puzzle lock that's broken.
Except Zor, of course, who made his game in the ancient days of 2006 when people didn't know any better .