Show all user interactable hotspots to user

[anthonyirwin82]

Many modern point and click adventure games have a feature that allows the user to press a button and have either a static image or an animation display showing all the interactable hotspots. An example from Deponia is below where they have a bolt for interactable objects in the game and an arrow for the exits.

Desktop games could show all hotspots when pressing the space bar key. Touch games could show all hotspots with two finger tap and hold or by single finger tap and hold on the player character.

It may be nice to have a global default hotspot image/animation and then allow it to be overridden on an individual hotspot, prop, character, etc.

There are several ways this could be done such as displaying the image/animation in the center of the hotspot or having a marker2d for where the image/animation will display.

Other people in the discord chat also mentioned having a shader to highlight the interactable hotspots in the game.

[mapedorr]

I like the idea of using a Marker2D node because that allows devs to define by themselves where the image should appear. By default it could be placed at the center of each PopochiuClickable (Prop, Hotspot, Character) scene. For Props and Characters we could add in the future a shader that also highlights the object's texture with an outline.

About the way to show them, we could use what you propose by default, and each GUI template could expose a button or command to achieve the same. I guess it will be good to also have some properties exposed in the ProjectSettings (under Popochiu's section) so devs can customize how the "Show clickable objects" should work.

[stickgrinder]

Since the player's need is pretty clear, I want to deviate this discussion away from the solution for a moment and try to depict the need from the (my?) developer's point of view. I'll list some points that come to mind.

Feature flagging

• This feature seems something that needs to be exposed via a narrow set of engine functions, like show_markers(), hide_markers(), etc. The GUI implementation should be controlling how this is triggered, not the engine itself. This will give control to the developer on a per-game basis.
• An engine-level status variable may be available to enable or disable this feature, so the GUI can expose this as an option to the player.
• The current GUI templates should be updated to support this feature.

Configurability

In a perfect world, a dev should be able to configure:

1. a default marker (generic use of the word here) for every clickable
2. a per-clickable-type override marker (one for props, one for hotspots, one for characters, etc)
3. a specific marker for each single object

This means we would need to register a collection of markers (say, in the main tab of the dock) and reference them in various context.

This model makes it a bit difficult to conveniently address the "exit" feature: exits are hotspots with nothing special to qualify them as exits. In the Deponia example specified in the issue, we also have directions for the exits, that makes a possible "general" solution even more convoluted.

This may not even be a problem, since the single exits may have manual overrides, so let's take this with a grain of salt.

Another aspect of the configuration is related to choosing between different implementations (like marker2d vs shaders), if we want to support different strategies (don't actually know if it makes sense).

One last thing we want to configure globally is the color and alpha of an overlay that we can render between the scene and the markers (with markers in foreground, the overlay under them and finally the game scene). The deponia example is not that readable in my opinion, and having an overlay may make the markers more accessible and evident. Of course it can be transparent.

Other aspects (brainstorming)

• Should markers be animated? In this case, extending the aseprite importer to markers can be a nice addition.
• If we end up with too much stuff to be implemented in a single pass we may iterate over this feature, but having an idea of the final goal can help orientating the solution.
• Placing the hotspot can be done by calculating the center of the interaction polygon. We can't rely on the origin of the clickable for various reasons: characters can have the origins between their feet, props created by the importer are all positioned in the center of the scene, etc. No matter what's the default, we'll need a gizmo like the walk_to_point one to give control to the player.
• This makes me think that previewing the marker in the scene preview editor may be a bit messy. We may solve this by placing a toggle icon on the toolbar maybe?

[mapedorr]

I agree with you in various points:

• Having an overlay so markers are more readable should be something devs can configure (in fact, the idea was also in my mind).
• We should expose to devs different options for defining how the markers will look like and how the GUI will show them (e.g., clicking a button, a keyboard shortcut, clicking and holding the PC (or anywhere in the room), and so on).
• We'll need the gizmo (that was my point about using a Marker2D node).
• There should be an option in the Editor (toolbar), or the Room tab, that allows devs to preview how markers will be rendered in-game.

About the shader

I think giving the option to use a Marker2D or a shader for Props and Characters makes sense. With a shader you can draw an outline of the object's Sprite (no matter if it is animated or if it moves through the room), and unlike an overlaid image, the outline doesn't obstruct the object's texture, as could happen when using an image (e.g., a dot or an arrow), or text. Additionally, it might not be an outline, but rather a glow or another visually striking effect.

Finally

We'll need to break down this task because it is not trivial. One task will be to code the logic to make the markers work (this will probably be an easy one), another one will be to expose the configuration options to devs.

[stickgrinder]

@mapedorr thanks for giving me an idea on how shaders can serve the purpose. I need to think a bit about giving the user a set of possible interactions to turn the markers on (compared to giving them a code API and leaving it to them if they don't use one of the provided GUIs), but I will put my head on it.

As for splitting the card, I would always slice the cake vertically, so that with every split story, we give users a smaller but complete functionality. Here is a possible proposal:

1. The first version of this feature will include a single configurable marker, the overlay, the game option to turn markers on and off in a game, and markers support in all of the custom GUI templates.
2. A second version introduces variations for each type of marker (per-object-type down to single object overrides) and the ability to create many different markers in a catalog, plus the scene preview function (because at that point, things can go very bad :D )
3. A last version can add shaders support as an option, plus every possible cozy feature that we learned about by experience.

Something like that. The first one is still pretty dense, but it's the bulk of the feature and, if nothing else, will allow users to define their marker + overlay to make things readable in their games. Building on that in iterations should be simpler, and we'll learn from feedback.

@anthonyirwin82 how does this sound?

[anthonyirwin82]

Sounds good

[mapedorr]

I like what you propose @stickgrinder . I would like to include at least one outline shader in the first version, but we could have it as a nice-to-have, or discuss it a bit more when creating the corresponding tasks for that milestone.

[anthonyirwin82]

I like the idea of a minimum working feature set that incrementally improves. If you look at Escorial for example it was released in 2016 then rewritten in 2020 and it is still in alpha for godot 3 only not 4 and not really useable for average users.

better to have a product people can use then one that is in constant development.

[anthonyirwin82]

Here is another example of show all hotspots from the Return to Monkey Island which is probably the biggest adventure release in recent times and they just used a simple circle to show hotspots.

[mapedorr]

Great example. With the Marker2D node as a helper of where the image should be shown, making something like this seems easy.

[stickgrinder]

The remastered Android edition of Broken Sword used to have bright blue dots for that.

In the very first version, we can focus on making a single symbol or shader configurable. This already marks a huge difference. I would say 80% of the benefit is covered by such a feature. More options are icing on the cake.

[stickgrinder]

I labeled this as an epic. Later this week I'll save some time to break it down to smaller, manageable issues with a decent requirements list so that this can be planned for release and taken up by someone.

@anthonyirwin82 not sure about that: are you willing to take this in charge?

[anthonyirwin82]

I can certainly look at working on it. I will look at the list when it’s released and if needed discuss it further in the dev chat.