With my SVN/compiling skills, i'm really only able to test the most
recent version.
My testing has been all on prototype B.
My first response on seeing, the ghost left behind in the "real"
position was backwards, and a little confusing. Further testing
didn't dispel this. Intuitive the the real, actual, current location
of a unit is expected be solid, and the potential future location
should be ghosted.
On Jun 22, 2010, at 11:13 PM, Gabriel Morin wrote:
Secondary questions:
What works better, almost-transparent arrows that highlight on
mouseover like in prototype B, or clearly visible arrows (that also
highlight on mouseover) as in prototype A? Which kind of arrow is
best for which prototype's approach?
I'm not sure that highlighting arrows on mouse-over *of the arrows* is
the right approach. In a moderately close formation, there's the
potential of multiple arrows per hex, which means that mousing over
lots of hexes could highlight multiple arrow strands. Mousing over
the current position of the unit (and possible the future position)
would make it much easier to avoid confusing accidental highlighting
of too many arrow lines.
But that's probably not what you were asking. Semi-transparent arrows
that solidify under certain conditions are good since it helps to
distinguish the active from other arrows.
Incidentally, i think the arrows (at least when selected) should be
animated to show the direction of movement. This should help
differentiate the multiple arrows in the same hex. Though obviously
this isn't of immediate importance.
2 Is it necessary to allow defining several moves for the same unit?
Such as planning "move unit X, then move unit Y, then move unit X
again"? (It's essential if we want to allow planning in advance the
moves of 2 units that want to swap places.)
I wouldn't consider this "necessary" because at least in some
situations, i think any UI that tried to show exactly what was going
on would be an incomprehensible mess. I'd tag this "a nice idea
subject to it being able to do done well."
4 Once you plan a move for some unit W, you can schedule another
unit Z to take its place. This possibility is pretty essential for
manoeuvering in tight situations (example, when two units do the
three moves necessary to swap places). But this creates an overlap
between W's src unit and Z's dst unit. How to deal with that
visually, and what should be the mouseover behavior?
I would place them side by side in a hex, i.e. one moved to the right,
the other moved to the left. Yeah, i realize this only really works
for a limited number of moves per hex, but i can't think of a way to
show more moves that is comprehensible.
-jwb / eleazar
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
