Hello,
I think that which prototype is best depends of the usage.
Prototype A ("dst ghost prototype" / "show future position") is better to
show a plan.
Prototype B ("dst real prototype" / "pretend the unit is already there") is
better to create a plan.
IMO prototype B is the only clear way to plan complex moves like the switch
position case. It allows the user to move its units as usual and see how
hard-to-predict stats evolve (ZoC, enemy blocking, correct damage
predictions). The arrows showing origin and followed path are only reminders
and are almost useless, because the user is currently planning his actions
and only cares about what will be situation before choosing his next move.
It also looks better with the animation movement (which I think is important
to clue the brain about the position's change), because it moves the 'real'
unit to its future position, instead of staying there and sending a ghost.
It also better shows the importance of actions order, by modifying things
instead of adding things. In fact, instead of a whiteboard with arrows, it
would be more like generals moving pawns on a map before a battle.
Now, the problem is that prototype B will not work well when we need to both
see the current true game state *and* the planned moves. The main case is
when starting to execute actions. You will need to show real units move and
fight, because using ghosts will be ugly and will not mix well with
not-ghost enemy units. But you still need to show WB plans, mainly to allow
the user to decide if he wish to interrupt these plans (for example after a
bad fight, or when the new reality logically conflict with your planned
actions). BTW, usual cases like fights or ambush are already a problem here,
not even need to consider WML events.
Another problem with B already visible by using test-scenario is with the
Dark Adept 'darkens' ability (even ignoring the double halo problem). If I
plan several moves and the last one being with the Dark Adept, when I start
to execute them, each time deciding to continue or not, using B will look
like the dark aura has already moved (see ToD image and ToD bonus info).
This is not simply a temporary UI bug, if we always show units as if they
were really at their future positions, then the UI should follow (to help us
see stats change when we planed the move). But then there is sequence
inconsistency problem when executing. And if we always use A, that is
consider that the adept only move when we execute its action, then we can't
see its possible future bonus to following actions.
That was my analysis of the main problems needing to be considered for your
choice.
But now I wish to suggest to support both modes. A possible implementation
is to always display past and future WB actions with arrows and ghosts, and
use real units for a certain point of time of the WB history. This point
will always advance to the queue's tail when you add a new WB action (as in
B), and with the head when executing one.
Conceptually, it would be like a virtual undo/redo system where the
undo/redo stacks are partially visible. Starting to execute WB actions would
simply consist to replay the WB virtual undo stack in reality (FYI it's
already what we do to update delayed shroud, which is a similar problem).
Such system support both modes (using same code) and open new UI
possibilities. For example, for solving action's order issues: prototypes A
and B don't allow to check what is the situation after the 5th move of a
10-moves history. Allowing the user to forward/rewind WB history (perhaps
with undo/redo keys) would be easy to support and handy to check the
action's order (for example, this solves the previous dark adept problem and
helps when using the darkens bonus several times).
I hope that this a way to solve the dilemma, and not a third prototype to
consider :p
Alink
On Wed, Jun 23, 2010 at 6:13 AM, Gabriel Morin <[email protected]>wrote:
> Hi all,
>
> The interface for whiteboard planned moves definition is at an early
> prototype stage, and I need help determining which of the two UI approaches
> explained below is best. I'd rather avoid wasting time on refining an
> interface that proves to be less-than-optimal.
>
> As a reminder or for those who never read it, here's the project
> page<http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba>;
> a few UI and technical details have evolved since it was updated, but the
> overall concept is the same.
>
> *Please do not reply if you haven't built and tested both prototypes !!!*As
> much as your opinion is appreciated, throwing advice around without a
> common basis won't help at all.
>
> - *To start the whiteboard* for either prototype, type :debug and
> :whiteboard (or :wb).
> - For a real quick test, launch "wesnoth --test --debug" and type ":wb"
> once you're in the test scenario.
> - There are several known crash bugs and visual glitches. No need to
> report these.
> - Don't be too impatient with the interface (i.e. don't stress test
> it), some things like selecting a unit while another's move is animated
> causes problems.
>
> *Prototype A ("dst ghost prototype" / "show future position"**)*:
> destination unit shown as ghost, and source/origin as regular unit. [The
> mockups<http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba#Mockups_for_various_interface_elements>on
> my project page are based on this solution.]
> SVN rev. 43513
>
> - To execute moves in prototype A, define the same move twice. There
> are no hotkeys since they were implemented in a later revision.
>
> *Prototype B ("dst real prototype" / "pretend the unit is already there"**
> )*: destination unit shown as regular unit, and source/origin as ghost
> SVN rev. 43605
>
> - To execute moves in prototype B, use the 'y' key. You can erase moves
> with 'h'.
>
> *
> The main question* that needs answering is whether the approach of
> prototype A or prototype B is better: is it preferable to show the dest.
> unit as a ghost, or with the appearance of the real unit. Factors to
> consider:
>
> - With prototype B, dealing with the potential intrusions of WML events
> is difficult. Units are perceived by the player to be at the new position
> he
> planned for them. However if any of those units is affected by the WML
> event, this happen at its current, real location in the unit map. Therefore
> the unit needs to visually jump back to its original position, to be
> affected by whatever the event does. This is a challenge to represent
> visually.
> - Again with prototype B, "select" events are problematic since I'm
> told they can show custom menus; but whatever effect the commands in the
> menu have they probably assume the unit is at its src location. The only
> solution I found is disabling "select" events for any unit that has at
> least
> one planned action.
>
>
> *Secondary questions*:
>
> 1. 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?
> 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.)
> 3. Assuming we want the whiteboard to be usable exclusively with the
> mouse, what kind of interface could we use for that? Example solution:
> double-clicking the destination could execute a move, and deleting moves or
> executing all in sequence would be done with context menus. Drag-and-drop
> of
> the dst unit could also be useful, but it's much harder to implement.
> 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?
>
> Thanks in advance for your testing and advice. And double thanks for the
> generous among you who can provide binaries for the technically-challenged
> testers.
>
> Gabriel aka gabba
>
> _______________________________________________
> Wesnoth-dev mailing list
> [email protected]
> https://mail.gna.org/listinfo/wesnoth-dev
>
>
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
