Variable anchor for status bars, orbs, etc.

Brainstorm ideas of possible additions to the game. Read this before posting!

Moderator: Forum Moderators

Forum rules
Before posting a new idea, you must read the following:
User avatar
doofus-01
Art Director
Posts: 4122
Joined: January 6th, 2008, 9:27 pm
Location: USA

Re: Variable anchor for status bars, orbs, etc.

Post by doofus-01 »

Getting rid of the bars, or redesigning the status decorations, is a bit off-topic (and I don't at all like the idea of changing the bars to yet more orb colors). This thread is just about being able to move the anchor points.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
User avatar
iceiceice
Posts: 1056
Joined: August 23rd, 2013, 2:10 am

Re: Variable anchor for status bars, orbs, etc.

Post by iceiceice »

Just an update:

This feature got reverted on master for the time being, because it was broken when you zoom in or out, and this obviously interferes with testing the sprite scaling feature (just now merged).

I hope that lipk recommits some version of it, however I want to suggest that instead of being a wml attribute of units, it should be a preference of the user.

I reach this conclusion after summarizing arguments made earlier in the thread as follows:
  • Fine, wesnoth can only handle sprites about the size of a hex, or it is bound to look bad in many situations. Suppose that I as an artist decide to do it anyway. You can still accommodate me by letting me move the health bar out of the way.
  • However, now for me as a player, I might see drawbacks in this. As minor as it may seem, it may really be a "huge step back in usability". In current wesnoth versions, every unit has a sprite, and one can always find a right angle of ellipse, health bar, at exactly a particular distance, with the sprite sitting nearly centered in the angle. The fact that it's always this solid right angle of a certain size means I can always very rapidly assess exactly
    - where are my units
    - how much health do they have
    - what types are they
    and I don't have scan around with my eye looking for these items.
  • Besides this, health bars are ultimately functional and not decorative. If there's a usability problem, that's much more important than decorative concerns.
  • Therefore if the user and artist disagree in some scenario about how they health bars should be, the user should win. A preference also means that if it only works poorly for a single scenario, or only a few hexes, or something, the user can swap around the preferences temporarily.
User avatar
Xudo
Posts: 563
Joined: April 3rd, 2009, 5:26 pm

Re: Variable anchor for status bars, orbs, etc.

Post by Xudo »

The problem with position of health bar is specific for unit, not for entire game. That's why there is no sense to make them global.

Why there is a problem to scale position (and size) of the bar like size of the units?
User avatar
iceiceice
Posts: 1056
Joined: August 23rd, 2013, 2:10 am

Re: Variable anchor for status bars, orbs, etc.

Post by iceiceice »

Xudo wrote: The problem with position of health bar is specific for unit, not for entire game. That's why there is no sense to make them global.
The policy of whether health bars should be laid out in a predictable way or depend on each unit *is* global. The whole controversy here is *whether* position of health bar should be specific per unit.

Good UI is supposed to just work without requiring people to hard code every single layout detail. If the policy is broken for some units that means that policy needs tweaking, not that every unit needs to be annotated.

There clearly needs to be some global setting so that in cases where usability is negatively impacted, the user can fix it.
User avatar
doofus-01
Art Director
Posts: 4122
Joined: January 6th, 2008, 9:27 pm
Location: USA

Re: Variable anchor for status bars, orbs, etc.

Post by doofus-01 »

iceiceice, if your comments were directed at me and the general proposal, I'd say the decorative artist vs functional player stuff is a strawman, and whether the player gets a toggle for 72px-lock or not is hardly a controversy here. The player toggle switch is a fine idea, as far as I'm concerned, whether it overrides specified coordinates in unit's WML or undoes lipk's modification.

I take issue with those (not just iceiceice) who frame this as "easy-to-read, functional status-quo" versus "proposed whimsical eyecandy". The fact that the status bar is in a sprite's face, or overlapping something parallel like a sword blade, makes it hard for me to read; I'd find it more useful (you could even say functional) if it could be moved.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
User avatar
iceiceice
Posts: 1056
Joined: August 23rd, 2013, 2:10 am

Re: Variable anchor for status bars, orbs, etc.

Post by iceiceice »

I don't take issue with the general idea but I take issue with the implementation. At least with the old way, there's never any possible confusion about (1) which hex a unit is on or (2) which hex a health bar is on. With this "anchor to sprite" implementation, fine the health bar never obscures the large sprites but you are just dumping your trash in your neighbor's backyard, and now I have health bars which are on top of some units but belong instead to their neighbor. It's clearly a detriment to usability. If you don't like seeing health bars over unit's faces, this commit didn't actually fix that.

In any case where this kind of change would make a big difference in placement, it seems it's always much worse than the current setting, once the units start to crowd. In cases where it makes only a very small difference in placement (i.e. move a few pixels off the sword, via manual WML offset), okay fine, it can't hurt, but still it seems like a lot of work for what seems to me also a "rare interface annoyance". And if you have a lot of these, frankly it may just look messy because all the health bars are ever so slightly out of alignment, with seemingly little gained.

I'm not opposed to the general idea but IMO it should be committed to master until it's a little better thought out, i.e. fine if there's space then move the health bar over, but don't get on top of the other units and health bars either, if it's crowded go back to your hex.
User avatar
doofus-01
Art Director
Posts: 4122
Joined: January 6th, 2008, 9:27 pm
Location: USA

Re: Variable anchor for status bars, orbs, etc.

Post by doofus-01 »

iceiceice wrote:I don't take issue with the general idea but I take issue with the implementation. At least with the old way, there's never any possible confusion about (1) which hex a unit is on or (2) which hex a health bar is on. With this "anchor to sprite" implementation, fine the health bar never obscures the large sprites but you are just dumping your trash in your neighbor's backyard, and now I have health bars which are on top of some units but belong instead to their neighbor. It's clearly a detriment to usability. If you don't like seeing health bars over unit's faces, this commit didn't actually fix that.
If stupid padding is used, like 200px for a little goblin thing, then yes, the status bars would be floating off somewhere, obscuring other sprites and causing confusion. But that's trivial to avoid, as are many unrelated things that could already be done to create broken content. If the status bars are overlapping neighbors, the sprites will be too. The sprite is presumably centered on the hex (or offset up a bit), and the status bars are part of an obvious bounding box. Honestly, this is not as confusing as it's being made out to be.

As for my dislike of bars on sprites faces, this did in fact fix it, or at least came closer: With the variable anchor, the bar is only in a face sometimes, just like many other instances with current sprite or terrain images overlapping.
iceiceice wrote:In any case where this kind of change would make a big difference in placement, it seems it's always much worse than the current setting, once the units start to crowd. In cases where it makes only a very small difference in placement (i.e. move a few pixels off the sword, via manual WML offset), okay fine, it can't hurt, but still it seems like a lot of work for what seems to me also a "rare interface annoyance". And if you have a lot of these, frankly it may just look messy because all the health bars are ever so slightly out of alignment, with seemingly little gained.
"Not worth the effort" is a fine argument, except that lipk managed pretty quickly. Most units are unaffected, and if you have a zillion oversized sprites cuddling, it's going to look like crap no matter where the status bars are.
iceiceice wrote:I'm not opposed to the general idea but IMO it should be committed to master until it's a little better thought out, i.e. fine if there's space then move the health bar over, but don't get on top of the other units and health bars either, if it's crowded go back to your hex.
I'm not saying that is a bad idea, but if you were confused about the bars not being locked in their current position, that would be a step in the wrong direction - I don't think the current naysayers, yourself included, would approve at all. I would think the preferences toggle you mentioned earlier might do the trick though.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
User avatar
Xudo
Posts: 563
Joined: April 3rd, 2009, 5:26 pm

Re: Variable anchor for status bars, orbs, etc.

Post by Xudo »

So we end up with:
  • Allow each unit type to define an optional x,y offset for the bars and orbs by WML. Defaults should look like they are implemented now.
  • Allow to hide bars and orbs by WML. Default is "always show".
  • Add preference option for toggle between modes: ignore custom bars and orbs placement, use custom bars and orbs placement.
User avatar
doofus-01
Art Director
Posts: 4122
Joined: January 6th, 2008, 9:27 pm
Location: USA

Re: Variable anchor for status bars, orbs, etc.

Post by doofus-01 »

Xudo wrote:So we end up with:
  • Allow each unit type to define an optional x,y offset for the bars and orbs by WML. Defaults should look like they are implemented now.
  • Allow to hide bars and orbs by WML. Default is "always show".
  • Add preference option for toggle between modes: ignore custom bars and orbs placement, use custom bars and orbs placement.
Well, maybe. For the first bullet point - is it better to have the WML coordinates or to use lipk's implementation? I think a case could be made for either, and since the unit image anchor point is already done, that may be the way to go.

In general though, I think what we have is: Enough people with authority have decided that this is yucky, so it is removed, and will be willfully forgotten, like any disturbing memory of something yucky and offensive. At least until someone else of authority sees it and decides it's worth reconsidering, but don't hold your breath. This was probably a bad time in the release cycle to bring it up anyways.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
User avatar
iceiceice
Posts: 1056
Joined: August 23rd, 2013, 2:10 am

Re: Variable anchor for status bars, orbs, etc.

Post by iceiceice »

That's not quite right.

This was not a coup to bury the idea. The fact is there were multiple problems with this commit, beyond what has been reported and mentioned in thread.

Apparently, after the initial commit, no one right now has both the time and interest to fix it up or develop it further, in the month and half since it appeared.

I don't care what project you work on, when something broken gets committed to master, and nobody fixes it, it gets reverted, before it gets buried under months of other development and other bugs and becomes a mess. Of course being controversial plays a role in this, but even if it wasn't, it still would have been right to revert it for now, and continue development on a topic branch until it matures.

Anyone is welcome to make a feature branch / pull request and continue to develop the idea.
User avatar
doofus-01
Art Director
Posts: 4122
Joined: January 6th, 2008, 9:27 pm
Location: USA

Re: Variable anchor for status bars, orbs, etc.

Post by doofus-01 »

Sure, there were good reasons for the reversion (even if I have no visibility to some of them). And now that that's done, that's it, since the idea didn't exactly get traction with those who could do something. No one should hold their breath for anything further. An old thread in Ideas Forum is not much better than buried, and the Gna! feature request is marked as fixed. That was my point, nothing more.

Well, I guess I was also unimpressed with the arguments against it, but that doesn't matter since I'm not issuing paychecks.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
User avatar
GunChleoc
Translator
Posts: 506
Joined: September 28th, 2012, 7:35 am
Contact:

Re: Variable anchor for status bars, orbs, etc.

Post by GunChleoc »

The Feature Request will have been marked fixed after the initial commit to master. If somebody is interested in developing the branch further, I'm sure the status can be changed again.
User avatar
lipk
Posts: 637
Joined: July 18th, 2011, 1:42 pm

Re: Variable anchor for status bars, orbs, etc.

Post by lipk »

Apologies for dropping out of the discussion. I have very limited free time these days in general, barely anything for Wesnoth. I'd like make it clear that the idea has not been dropped and it will be implemented whenever I can spare some hours for a proper implementation (most likely in late December). I marked the FR as postponed for now.
ying
Posts: 8
Joined: October 13th, 2014, 2:34 am

Re: Variable anchor for status bars, orbs, etc.

Post by ying »

A decent solution might be to make the bars transparent excluding the unit.
If I spoke the truth, they would put me in a straitjacket. So, I left the society.
User avatar
Xudo
Posts: 563
Joined: April 3rd, 2009, 5:26 pm

Re: Variable anchor for status bars, orbs, etc.

Post by Xudo »

It does not solve the problem of HP bar over sword of swordsman.
Post Reply