Do we need a walk interaction?

Started by Babar, Mon 30/03/2020 17:21:16

Previous topic - Next topic

TheManInBoots

#40
Quote from: Cassiebsg on Mon 30/03/2020 20:19:15
Yes, agree that it's annoying when the character is blocking the hotspot you want to click on. Some devs take great care to avoid the character being placed in a spot where he'll be blocking the hotspot
Throwing this in about that point that has been made in the beginning, that is not an actual problem though. You don't have to go to such lengths to avoid characters walking in front of hotspots, because you can simply turn characters unclickable whenever the mouse is over a hotspot:
in repeatedly execute you write:

Code: ags

function repeatedly_execute_always()
{
if(Hotspot.GetAtRoomXY(mouse.x,mouse.y)!=hotspot[0])
character[N].Clickable=false;

else
character[N].Clickable=true;
}


This way the character of your choice is not clickable whenever the mouse is hoovering over a hotspot.
And you can loop through all background characters if you want.

Edit: Did your reply to that just dissappear, Crimson Wizard?

Crimson Wizard

#41
EDIT: realized this is not a tech thread, so removed the script example, as this is not scriptlystrictly bound to AGS.

I just wanted to mention that there are multiple solutions for characters blocking hotspots. One of which, I've seen in several games, is making player character non-clickable and translucent when mouse is above them in any case. Of course that means that player character cannot be interacted. If you wish character to be still interactable at all times, there may be other means to accomplish this, like hinting that something is behind. This is mostly a question of visual design, something that has to be thought through when you plan your gameplay.


TheManInBoots

#42
Oh ok. I thought my script part made clearer what I meant.
Babar, if you mind my script part in your thread, let me know, I can remove it.


Yeah, for example having the outlines of the object/hotspot drawn on top of the character can be great when a character stands in front of the object/hotspot or when the mouse is over the object/hspt. at the same time. Or the object/hotspot shines through translucently, without that the character changes transparency.
Or have all objects etc. behind shine through characters in front when pressing a key.

The benefit of checking every game loop is that you can also change the label name appropriately in the status line when you display what the mouse is hoovering above, as opposed to you programming it to respond when the mouse is clicked.

Those screen hints you're talking about, how would you imagine them to look like?
A tiny message that appears?

Lol did you actually write "scriptly bound" to begin with, that's funny (laugh)

Crimson Wizard

Quote from: TheManInBoots on Mon 13/04/2020 14:52:00
Lol did you actually write "scriptly bound" to begin with, that's funny (laugh)

Yes, this was a typo, then I fixed it and then realized it's a nice pun, so put it back :p

Babar

I have no issue with the code being in this thread, but I feel it is answering the wrong question. If the character is clickable/interactable in the game, that would be for a reason (at some points(s) the player would have to interact with them), and then having code that makes the player uninteractable in those situations wouldn't be helpful. The only way around this situation (other than having very weird and unintuitive, situation-dependant interactability of the player character) would be to always check if the walkto location is in front of a hotspot, and then move the player nearby where they wouldn't be in front of a hotspot. In this situation you'd always have to make sure your BGs don't have clusters of hotspots that would result in the player having to walkto a point too far away.
The ultimate Professional Amateur

Now, with his very own game: Alien Time Zone

TheManInBoots

#45
It depends on the scenario obviously.
I was referring to a situation where background characters walk around and occasionally pass by a hotspot.
Which in many cases are smaller than the character, or cover only a part of the character, so the character will remain constantly clickable anyways.
I feel like you are referring to a very specific situation, where there are plenty of hotspots spread around the room, and Characters are covered by them.
Even then, simply adding one more bool to the function I proposed for when the situation rises that the characters need  to be clickable is , how is that not intuitive?
Or generally making background elements clickable on keypress.
And if the hotspots are bigger than the character, the characters can stay clickable anyways, because they'll never cover the entire hotspot.
It all works totally fine. I see no problem with it.
Can you give an example of where there would be a big problem with this?

Crimson Wizard

#46
Quote from: TheManInBoots on Mon 13/04/2020 19:22:25
I feel like you are referring to a very specific situation, where there are plenty of hotspots spread around the room, and Characters are covered by them.
Even then, simply adding one more bool to the function I proposed for when the situation rises that the characters need  to be clickable is , how is that not intuitive?
Or generally making background elements clickable on keypress.
And if the hotspots are bigger than the character, the characters can stay clickable anyways, because they'll never cover the entire hotspot.
It all works totally fine. I see no problem with it.

It's a question of UI design, and whether that would be convenient for players, whether they will have a fluid game experience. Things like this are difficult to predict by using solely imagination, especially if you don't have larger experience with released games. Developer's eyes do not match player's eyes, players don't know all specifics about your game, and developers often subconsciously play in certain way because they guess about  potential issues within their games. Implementing your idea in game and giving out to people to try out is the best, if not only, way to find if the solution is good or not.

Usually there has to be a "proof of concept", like a game that demonstrates certain UI solution. Abstract proposals are only good for ideas generation, but they have to be tried in practice, then people can see how it actually works, it's good side and flaws.

Crimson Wizard

#47
Quote from: TheManInBoots on Mon 13/04/2020 19:22:25
Can you give an example of where there would be a big problem with this?

To ammend the above, if we are discussing the idea where character is either clickable or not depending on where it stands, this is without doubt will be causing annoyance to players, because they have to realize and remember this rule.
Say there's currently the problem that character may cover the hotspot and not letting players click on hotspot when they want to. With the above suggestion, won't there be an opposite situation, when players won't be able to click on character when they want to?
I believe, this is what Babar meant by "weird and unintuitive, situation-dependant interactability of the player character" (not the code).

Even if you will have some kind of an indication, like a glow, or tooltip, showing when you may or may not interact with character, players would have to be paying attention to that, and remember to move the character away from the "bad place" in order to click on character. Such things may seem like a triffle problem, but in reality they quickly make players irritated.

Making background elements clickable with a keypress is a better solution, in my opinion, but only because it's consistent. But it's also not ideal, because it's forcing player to use particular control device, which is not always justified with P&C games.

Babar

Indeed, as CrimsonWizard said, I have nothing against the code, I was more referring to the very concept of situationally changing the interactivity of a character being problematic, and not really a good solution to the problem quoted from Cassiebsg.
The ultimate Professional Amateur

Now, with his very own game: Alien Time Zone

Snarky

I tend to think the best way to solve this is to design the game so that it will not be a problem in the first place (make the player character unclickable if possible; and if they must be clickable, make sure that walk-to points are positioned so that they don't cover up any "hotspots"; and don't have NPCs walking around covering up other clickable elements).

Because if you have various elements that cover each other, and all of them are things you may want/need to click on, I don't see how you can elegantly accommodate that in a 2D UI, whatever you do.

… Which suggests that another solution is to go beyond 2D. What if, for example, you design the game with parallax, and give players an option to move the camera left/right or up/down in order to uncover things that may be hidden behind other objects? (I'm also reminded of The World Is Weird, where you can drag-and-drop pretty much every interactive element, rearranging the background to your heart's content.) Or use the scroll wheel to control the z-depth of the cursor?

SMF spam blocked by CleanTalk