[PATCH] Improve UI notification for failing attempts to build

[historic_bruno]

There are now a number of restrictions on where a building can be placed and possible limitations on how many can be built, in addition to its cost. Currently we don't distinguish between all these cases, a failure is indicated by a red-colored placement preview or sometimes a UI notification. To make this clearer, the following are proposed:

• Add return values that indicate the failing restriction(s) to at least the following functions: BuildRestrictions.CheckPlacement, BuildLimits.AllowedToBuild, GuiInterface.SetBuildingPlacementPreview CCmpObstruction.CheckFoundation, CCmpPathfinder.CheckBuildingPlacement, CCmpPathfinder.CheckUnitPlacement. Some examples:
  • Building site obstructed
  • Building site on invalid terrain (must be placed on [land, shore])
  • Building site outside world boundaries
  • Building site not allowed in [fog of war, shroud of darkness]
  • Building site not allowed in this territory (must be placed on [own, neutral, enemy, ally] territory)
  • Dock must be built facing into water(?)
  • [Building name] too close to an existing [building name] (must be placed at least [X] units away).
• Show a tooltip like the trade setup tooltip that follows the cursor and gives a reason why the building can't be placed in the current location.
• Numeric build limits don't rely on placement, so the user should be prevented from selecting the building in the UI. Maybe the icon can be greyed out, but the user can still click on it to get the exact message ("Limit of X reached for this building") and/or it could be indicated in the tooltip.
• Similarly, if the user has insufficient resources, they shouldn't be able to try placing it. Instead we could change the icon tooltip to list in red the lacking resources (I've seen this in some RTS games and it's very clear), if they click the icon anyway it will tell them how much of each resource they need.
• I think we'll want a similar system for technologies, where buildings with unsatisfied prerequisites can't be selected in the UI.
• Of course all these restrictions must be checked not only by the UI (which is intended only to notify the user) but also within the simulation itself, to prevent cheats with modified UIs.
• Some restrictions may be best indicated visually on the terrain, like minimum distance between civ centres or docks being restricted to shores.

[Philip Taylor]

a user would only be notified of the reason for placement failure when they click to place the building (in spite of it being a red placement preview)

I prefer it when games show a kind of hovering tooltip by the mouse when you're placing the building (when it's red), telling you why you can't build there - instant feedback seems much less frustrating than thinking it's alright and then having to click before being told why you can't and then repeating dozens of times until it works.

Of course all these restrictions must be checked not only by the UI (which is intended only to notify the user) but also within the simulation itself, to prevent cheats with modified UIs.

Also it's possible that the placement will be fine when the player clicks, but invalid by the time the command gets processed some turns later; so it should be an adequately user-friendly error message, it shouldn't assume the player is cheating.

[michael]

Another enhancement to this would to include audio feedback. Something that sounds like "ANG!" See: Age of Mythology.

[B. Guns]

What about the use of colour as notification.

-Red: obstructed, invalid terrain, etc... -Yellow(ish): not enough resources

I think the yellow colour would be a useful addition (and not a difficult one to implement imho)

[historic_bruno]

Replying to rjulius:

Hi, not sure if there's been a public discussion about this yet, but the vague idea for solving this ticket is to have enums returned from the various pathfinding and obstruction checks, which might possibly get translated to strings by the component-script interface. I remember we discussed it would be somewhat messy if e.g. BuildRestrictions had to resolve numerical C++ enums to meaningful values.

What I mean:

• BuildRestrictions.CheckPlacement calls CheckFoundation on the test entity, to see if the building is over valid terrain, which calls CheckBuildingPlacement on the pathfinder,
• CheckBuildingPlacement finds that the given location is on invalid terrain, maybe water when it should be land,
• It returns something like BUILD_PLACEMENT_FAIL_TERRAIN_CLASS,
• CheckFoundation checks the return value of CheckBuildingPlacement and sees it failed (not BUILD_PLACEMENT_SUCCESS?), and returns the same value,
• CheckFoundation in ICmpObstruction.cpp translates BUILD_PLACEMENT_FAIL_TERRAIN_CLASS into a "BUILD_PLACEMENT_FAIL_TERRAIN_CLASS" string and passes it back to BuildRestrictions.CheckPlacement,
• One of the last steps is for BuildRestrictions.CheckPlacement to check the return value, find that it's "BUILD_PLACEMENT_FAIL_TERRAIN_CLASS" instead of "BUILD_PLACEMENT_SUCCESS", and then create an object with useful data which gets returned to the UI:
  • Fail value
  • Error message to display on the UI: why placement failed (e.g. placed on invalid terrain) and what is needed for placement to succeed (e.g. place on land tiles, away from the shoreline)

That's not the way it has to be, only what has been discussed so far, so better suggestions are certainly welcome :) A great place for this discussion is the dev forum and our IRC dev chatroom (#0ad-dev on Quakenet.org).

[Gyula Halmos]

Replying to Philip:

I prefer it when games show a kind of hovering tooltip by the mouse when you're placing the building (when it's red), telling you why you can't build there - instant feedback seems much less frustrating than thinking it's alright and then having to click before being told why you can't and then repeating dozens of times until it works.

I thought that so, but using notifications is hmm, not themsot elegant thing, cuz it floods those 3 allowed rows, if it is fine then no prob, easy to give real time feedback, it was harder to implement feedback when clicked to build. So i would need a last word, which one is preferred. :) And maybe some help how to limit notifications to one line.

Of course all these restrictions must be checked not only by the UI (which is intended only to notify the user) but also within the simulation itself, to prevent cheats with modified UIs.

Also it's possible that the placement will be fine when the player clicks, but invalid by the time the command gets processed some turns later; so it should be an adequately user-friendly error message, it shouldn't assume the player is cheating.

I dont exactly understand this part, where should it be "also within the simulation itself" ? I already added it to the javascript files. Where else?

[Gyula Halmos]

Replying to plumo:

What about the use of colour as notification.

-Red: obstructed, invalid terrain, etc... -Yellow(ish): not enough resources

I think the yellow colour would be a useful addition (and not a difficult one to implement imho)

I think this solution is not in harmony with the ticket, because:

"Similarly, if the user has insufficient resources, they shouldn't be able to try placing it. Instead we could change the icon tooltip to list in red the lacking resources (I've seen this in some RTS games and it's very clear), if they click the icon anyway it will tell them how much of each resource they need."

That means you wont see any Build Preview if you dont have enough resources. So this yellow thing is not needed as far as i am concerned.

[Gyula Halmos]

Replying to michael:

Another enhancement to this would to include audio feedback. Something that sounds like "ANG!" See: Age of Mythology.

Interesting but i think it would be more of an annoying than a useful improvement. But for example in other RTSs there is audio like : "Cannot build there." ... etc. So i dont know ? Shall i add it ?

[historic_bruno]

Replying to rjulius:

Replying to Philip:

I prefer it when games show a kind of hovering tooltip by the mouse when you're placing the building (when it's red), telling you why you can't build there - instant feedback seems much less frustrating than thinking it's alright and then having to click before being told why you can't and then repeating dozens of times until it works.

I thought that so, but using notifications is hmm, not themsot elegant thing, cuz it floods those 3 allowed rows, if it is fine then no prob, easy to give real time feedback, it was harder to implement feedback when clicked to build. So i would need a last word, which one is preferred. :) And maybe some help how to limit notifications to one line.

He wasn't referring to the current notifications system but instead adding a floating tooltip that follows the mouse. It should only be a short, one line message really, so I think a tooltip works fine. It's a bit of a technical challenge to get a floating tooltip, but fcxSanya has added this to his trade patch (see #30), so you can use a slightly less appealing alternative for now, then once #30 is committed (should be in time for Alpha 9) we can add the floating tooltips to this ticket as well.

Of course all these restrictions must be checked not only by the UI (which is intended only to notify the user) but also within the simulation itself, to prevent cheats with modified UIs.

Also it's possible that the placement will be fine when the player clicks, but invalid by the time the command gets processed some turns later; so it should be an adequately user-friendly error message, it shouldn't assume the player is cheating.

I dont exactly understand this part, where should it be "also within the simulation itself" ? I already added it to the javascript files. Where else?

The UI has its own checks for building placement, that's how e.g. the building preview turns red. UI scripts can't directly access the simulation, because then networked games wouldn't be in sync. To actually do something, the UI posts a command which gets handled by the simulation (Commands.js and any components it uses).

Currently the simulation should already be checking build placement restrictions, but the errors aren't very nice if something fails at that level (either because of modded UI, a bug, or as Philip pointed out, there was a lag between command posting and processing). So we should make sure we have suitable messages in all cases, but the simulation doesn't have direct access to the player's UI, only the GUIInterface component - which could be extended if necessary, just remember that GUIInterface shouldn't do anything to affect the simulation, there's a big comment about that in GUIInterface.js.

Of course the UI is still the preferred method of notifying the user :)

[historic_bruno]

Are you "jules" on IRC by chance? If so, we are trying to respond to you, but it seems you're having some troubles with your IRC client (you don't respond and then ping timeout). If you didn't see our replies, you might use a different chat client and also check out the ​logs :)

[historic_bruno]

Replying to rjulius:

An update: "independent" tooltips were added in [11279], you can use them in your patch now :)

[historic_bruno]

Any updates, maybe a work-in-progress patch?

[Gyula Halmos]

Hi, sorry, i just had to finish the university era of my life :D Now i wil lfocus again, sorry for the disappearence. The solution is ready to be tested, there were some issues about the proper colour using, saturation editin... etc. Patch will be available in the upcoming week. :) Tooltip's introduction is a huge asset :)

[historic_bruno]

Replying to rjulius:

Hi, sorry, i just had to finish the university era of my life :D Now i wil lfocus again, sorry for the disappearence. The solution is ready to be tested, there were some issues about the proper colour using, saturation editin... etc. Patch will be available in the upcoming week. :) Tooltip's introduction is a huge asset :)

Wondering how it's going, any luck with the patch?

[historic_bruno]

Points 3-5 are already implemented.

[Gyula Halmos]

I have been merely inactive, btw my solution was ready all the time, it just needed soem modification with the red's saturation level, i am moving abroad where i will work and live alone for a while so probably in my freetime i can turn my attention back to this project full time. Sorry for that this year was decisive with my career. I refresh the repository and examine my solution and perform the changes.

[historic_bruno]

Replying to rjulius:

I have been merely inactive, btw my solution was ready all the time, it just needed soem modification with the red's saturation level, i am moving abroad where i will work and live alone for a while so probably in my freetime i can turn my attention back to this project full time. Sorry for that this year was decisive with my career. I refresh the repository and examine my solution and perform the changes.

Thanks for the update and I'm glad that you can still work on this! :) It would be great if you could attach a work in progress patch so we have something to think about/discuss and then someone else won't have to start working on this.

[historic_bruno]

I've gone ahead and worked on this task, rather than waiting for more updates.

Here are some screenshots showing how it looks: ​http://imgur.com/a/CmPlG

I'm fairly happy with how it works. The implementation is described in my above comment. I was going to make the messages red but they were not very legible on a dark background, so I've left them white.

TODOs:

• Possibly get more feedback from the pathfinder about why invalid terrain is invalid (seems hard), or parse the passability class into a somewhat friendly message
• Implement for wall placement previews :(
• Clean up comments/documentation

[historic_bruno]

Replying to historic_bruno:

I'm fairly happy with how it works. The implementation is described in my above comment. I was going to make the messages red but they were not very legible on a dark background, so I've left them white.

The solution is to make the tooltip border red. I added a white border and additional padding to the other floating tooltips to make them easier to read.

[ben]

In 13191:

Adds notification tooltips for building placement, fixes #921.
Tweaks info tooltip borders and padding to improve readability.