Planning system/Whiteboard feedback

[fog_of_gold]

You're probably right, but knowing how much time features take to implement, I'm a bit hesitant to rip out someone else's code like this. I'll discuss it with the author of the waypoints code.

Sure.

Not sure I understand what you're saying. Maybe you could make a quick commented screenshot?

It looks like you understood, looking at your following text but here it is:

[Scatha]

Hi,

I've been playing with the whiteboard and really enjoying it. Very useful, and a big improvement over 'delay shroud updates'. Hats off to those behind this! Some specific feedback follows.

Firstly, my most important bug report/feature request. This is the only thing I actually find annoying:
When using the whiteboard to plan attacks, the combat information screen shows combat odds based on the unit's current location, not on the location the unit will be attacking from. This affects:
- defence value of terrain
- light level, if caves / mages of light are around
- leadership bonuses
It would generally be much more useful to see the odds for after the move, and so far as terrain defence values are concerned I think this definitely counts as a bug. For other factors like light level and leadership, it should again use the hex the attacking unit is moving to, but there's a question about what the best behaviour for the system should be: should it count other units in their current locations, or in their planned locations? (I think counting them in their planned locations is probably best, as this lets you carefully plan attacks involving moving people up for leadership bonuses; this has possibilities for subtly doing things wrong when you rearrange the order of your planned moves, but that's always true)

Then two very minor feature requests (both pretty easy to play around, but they'd be in my ideal whiteboard system):
- When reordering planned moves or executing one out of order, perhaps it would be good to have a confirmation box if this will prevent (or alter?) other planned moves? The main time this would come up would be not accidentally moving your leader from the keep before you've recruited, but it could also stop you changing a move to later in the running order and thereby stopping some unit which was planned to move onto the vacated square. A more complicated interaction might come if you're taking away leadership bonuses from combat.
- To be able to plan more than one move for a given unit. e.g. leader to keep (using 2/5 moves), then recruit some units, *then* move the leader again with the remaining (3/5) moves, from their planned location of the keep. Even more useful perhaps with complicated combat situations where you're running a unit with leadership along a line of troops, and want to step one square, attack with a unit, step another square, etc.

Should I send in a proper bug report for the first thing?

Anyhow, thanks again for the whiteboard, I love it even with the problem.

[gabba]

Hi,

I've been playing with the whiteboard and really enjoying it. Very useful, and a big improvement over 'delay shroud updates'. Hats off to those behind this! Some specific feedback follows.

It's nice to hear some feedback from someone who actually used it and likes it!

Firstly, my most important bug report/feature request. This is the only thing I actually find annoying:
When using the whiteboard to plan attacks, the combat information screen shows combat odds based on the unit's current location, not on the location the unit will be attacking from. This affects:
- defence value of terrain
- light level, if caves / mages of light are around
- leadership bonuses
It would generally be much more useful to see the odds for after the move, and so far as terrain defence values are concerned I think this definitely counts as a bug. For other factors like light level and leadership, it should again use the hex the attacking unit is moving to, but there's a question about what the best behaviour for the system should be: should it count other units in their current locations, or in their planned locations? (I think counting them in their planned locations is probably best, as this lets you carefully plan attacks involving moving people up for leadership bonuses; this has possibilities for subtly doing things wrong when you rearrange the order of your planned moves, but that's always true)

This is definitely a bug: leadership and everything else should be taken into account. Looks like something broke at some point. Please submit a bug report (boucman did it) so I don't forget about it: it might take a while before I get to it.

Then two very minor feature requests (both pretty easy to play around, but they'd be in my ideal whiteboard system):
- When reordering planned moves or executing one out of order, perhaps it would be good to have a confirmation box if this will prevent (or alter?) other planned moves? The main time this would come up would be not accidentally moving your leader from the keep before you've recruited, but it could also stop you changing a move to later in the running order and thereby stopping some unit which was planned to move onto the vacated square. A more complicated interaction might come if you're taking away leadership bonuses from combat.

Good catch, looks like I need to prevent you from executing a leader's move out-of-order if any planned recruits depend on the leader's current position. I already have similar checks in place for the leaders, so it shouldn't be too difficult. No dialog box if I can avoid it.
This would be worth a second bug report (I consider it a bug), if you have time to submit it. (boucman did it)

- To be able to plan more than one move for a given unit. e.g. leader to keep (using 2/5 moves), then recruit some units, *then* move the leader again with the remaining (3/5) moves, from their planned location of the keep.

You can already do exactly what you described . If you plan a move, then click the planned position of a unit, you can queue additional moves.

Anyhow, thanks again for the whiteboard, I love it even with the problem.

Again, that's really nice to hear .

[tiboloid]

Impressive job ! I tested it today and got really amazed, well done !
A quick suggestion although I suppose not easy to implement: would it be possible to share the planning one has made with teamates when playing MP games ?
Something like a 'Post to teamates' button ?

Thanks for the good job

tibs

[gabba]

Impressive job ! I tested it today and got really amazed, well done !
A quick suggestion although I suppose not easy to implement: would it be possible to share the planning one has made with teamates when playing MP games ?

That's the whole idea (or at least and important part of the project). When the network part is finished plans will be shared automatically to allies (you'll be able to hide allies' plans if they clutter your screen).

By the way we're looking for a Google Summer of Code student to implement the networked part of the Whiteboard, it would allow the project to be completed much faster.

[Scatha]

Hello again. It has been a while, but I think I can provide some further useful feedback/suggestions on the whiteboard. I should say that I am still very fond of this feature.

On the Visuals:
Playing some multiplayer with people who were less familiar with it, they were also quite positive, but some of them did complain about some aspects compared to delay shroud. The main objection is that the visuals don't make the most pertinent information clear. I think this is a valid criticism, and I'll try to make it more precise.

When planning unit moves one of the things you care most about is how the whole formation will look at the end. While it's very obvious what's happening in the current implementation if just one unit is being moved, or you're moving into a previously empty area, it can be quite confusing and hard to take in at a glance if you're planning moves for several units and some of them are moving to spaces vacated by others.

To help with this, I'd suggest:
(1) adding a stronger visual marker to the actual locations of units which have planned moves
(2) if a hex contains an actual unit and a planned move for another unit, show the planned move on top (rather than underneath, as in current behaviour)

For (1), my preferred visual marker would probably be a form of transparency, and I'd suggest quite transparent is appropriate. This would help to distinguish units with planned moves from those without (which can get quite hard to see in a block of units), which helps you to know which ones you can still move, as well as meaning that it's harder to confuse the (current, actual) position of a unit which plans to move away with something which you can think of as part of your formation.


Interaction with shroud / multi-turn moves
Just a few comments about how I'd ideally like to see the interface here.

Current behaviour: if you have a move planned, and execute ('y') it, is that if it sights an enemy (or depending on your settings, an ally) mid-move, it halts the move there and asks you to press 't' to continue the move. If you have a lot of moves planned, and execute all (ctrl-y), but the first one interrupts on sighting an enemy, there is a narrow window of opportunity for you to press 't', else it continues with the other planned moves (which is problematic, since you might want to change those in light of the new information).

Proposed behaviour: upon sighting an enemy, it halts the execution queue (this move and later ones if you used ctrl-y), and adds the rest of the planned move for this unit as a new planned move at the very top of the queue. So now pressing 'y' will have effectively the same behaviour as 't' used to. This should happen whether or not the current move was made using the whiteboard or just a standard move -- the planning system perfectly obsoletes the 't' behaviour here (obviously it should change the message to "press 'y' to continue".

Similarly the whiteboard system would give a better implementation of multi-turn moves than the current one. If one tells a unit to move further than it can this turn (whether via planning or just as a direct command), it should, as currently, move as far as it can manage this turn. Then rather than move immediately at the beginning of next turn, your next turn should begin with those moves already planned; all you need to do is execute them. This would dodge all sorts of issues with the current behaviour, some of which were the subject of a recent discussion in the ideas forum.

---

Anyhow I hope that made sense and was somewhat helpful. I'm very happy to discuss these things -- I may well be ignorant of reasons some of them would be hard, or it may be you are already planning others.

Thanks again for making this feature!

[gabba]

First the good news: tschmitz was accepted in GSoC to work on the multiplayer part of the whiteboard, so if all goes well that'll be done by the end of summer.

Hello again. It has been a while, but I think I can provide some further useful feedback/suggestions on the whiteboard. I should say that I am still very fond of this feature.

On the Visuals:
Playing some multiplayer with people who were less familiar with it, they were also quite positive, but some of them did complain about some aspects compared to delay shroud. The main objection is that the visuals don't make the most pertinent information clear. I think this is a valid criticism, and I'll try to make it more precise.

When planning unit moves one of the things you care most about is how the whole formation will look at the end. While it's very obvious what's happening in the current implementation if just one unit is being moved, or you're moving into a previously empty area, it can be quite confusing and hard to take in at a glance if you're planning moves for several units and some of them are moving to spaces vacated by others.

To help with this, I'd suggest:
(1) adding a stronger visual marker to the actual locations of units which have planned moves
(2) if a hex contains an actual unit and a planned move for another unit, show the planned move on top (rather than underneath, as in current behaviour)

For (1), my preferred visual marker would probably be a form of transparency, and I'd suggest quite transparent is appropriate. This would help to distinguish units with planned moves from those without (which can get quite hard to see in a block of units), which helps you to know which ones you can still move, as well as meaning that it's harder to confuse the (current, actual) position of a unit which plans to move away with something which you can think of as part of your formation.

Your comments confirm my feeling that the emphasis needs to be on how the formation will look at the end.
For (1), one of the problems I encountered is how things should look once you execute the move. With your suggestion the unit whose move(s) you're about to execute is transparent, so do we just switch it back to solid and proceed?
I also considered making the unit look solid at it's destination (e.g. in the hex where it'll end up after its several planned moves), which makes the above more complicated to figure out: I don't want things to look jarring.

As of (2), the actual unit does take priority presently unless you mouseover the hex, I guess we could reverse it.

Interaction with shroud / multi-turn moves
Just a few comments about how I'd ideally like to see the interface here.

Current behaviour: if you have a move planned, and execute ('y') it, is that if it sights an enemy (or depending on your settings, an ally) mid-move, it halts the move there and asks you to press 't' to continue the move. If you have a lot of moves planned, and execute all (ctrl-y), but the first one interrupts on sighting an enemy, there is a narrow window of opportunity for you to press 't', else it continues with the other planned moves (which is problematic, since you might want to change those in light of the new information).

Sounds like a bug, it should obviously halt instead of requiring you to quickly press 't' . Or maybe I can just decide it's a feature and call it a Quick Time Event .

Proposed behaviour: upon sighting an enemy, it halts the execution queue (this move and later ones if you used ctrl-y), and adds the rest of the planned move for this unit as a new planned move at the very top of the queue. So now pressing 'y' will have effectively the same behaviour as 't' used to. This should happen whether or not the current move was made using the whiteboard or just a standard move -- the planning system perfectly obsoletes the 't' behaviour here (obviously it should change the message to "press 'y' to continue".

Similarly the whiteboard system would give a better implementation of multi-turn moves than the current one. If one tells a unit to move further than it can this turn (whether via planning or just as a direct command), it should, as currently, move as far as it can manage this turn. Then rather than move immediately at the beginning of next turn, your next turn should begin with those moves already planned; all you need to do is execute them. This would dodge all sorts of issues with the current behaviour, some of which were the subject of a recent discussion in the ideas forum.

Again I was thinking more or less in the same lines. Thing is, up to now I was trying not to antagonize people by giving the option to turn off any novelty from the whiteboard entirely. But these two mechanisms look like they would benefit from being simply replaced. Not sure what happen to the whole turning the planning mode on/off then, though. Any ideas?

[Zaroth]

Proposed behaviour: upon sighting an enemy, it halts the execution queue (this move and later ones if you used ctrl-y), and adds the rest of the planned move for this unit as a new planned move at the very top of the queue. So now pressing 'y' will have effectively the same behaviour as 't' used to. This should happen whether or not the current move was made using the whiteboard or just a standard move -- the planning system perfectly obsoletes the 't' behaviour here (obviously it should change the message to "press 'y' to continue".

Similarly the whiteboard system would give a better implementation of multi-turn moves than the current one. If one tells a unit to move further than it can this turn (whether via planning or just as a direct command), it should, as currently, move as far as it can manage this turn. Then rather than move immediately at the beginning of next turn, your next turn should begin with those moves already planned; all you need to do is execute them. This would dodge all sorts of issues with the current behaviour, some of which were the subject of a recent discussion in the ideas forum.

Again I was thinking more or less in the same lines. Thing is, up to now I was trying not to antagonize people by giving the option to turn off any novelty from the whiteboard entirely. But these two mechanisms look like they would benefit from being simply replaced. Not sure what happen to the whole turning the planning mode on/off then, though. Any ideas?

You could merge the planning mode with the normal mode - and the option would become "Plan every move" instead of "Enable planning mode". And we'd have 3 scenarios during normal mode:
1. Normal move/attack, nothing interesting happens. Executed as in current Wesnoth, immediately.
2. Enemy/ally unit sighted. Part of the move is executed immediately, the rest goes into planning mode.
3. Multi-turn move. The part of the move until MP runs out is executed, the rest goes into the planning mode. The arrows for reach of different turns should be numbered, so we don't lose a current feature.

If "Plan every move" is enabled, there is not much to say - it'd go as in current planning mode. You should also provide a hotkey for planning a single move even when "plan every move" is disabled - for example holding Alt when issuing order (I don't think Alt is used currently).

[Scatha]

First the good news: tschmitz was accepted in GSoC to work on the multiplayer part of the whiteboard, so if all goes well that'll be done by the end of summer.

I'm delighted to hear that!

Your comments confirm my feeling that the emphasis needs to be on how the formation will look at the end.
For (1), one of the problems I encountered is how things should look once you execute the move. With your suggestion the unit whose move(s) you're about to execute is transparent, so do we just switch it back to solid and proceed?
I also considered making the unit look solid at it's destination (e.g. in the hex where it'll end up after its several planned moves), which makes the above more complicated to figure out: I don't want things to look jarring.

I agree that delicacy is required to keep things looking smooth. In my proposal (1), yes, I had imagined you switch the unit back to solid to execute the move. Regarding making it look solid at its destination (by which I assume you mean coloured -- it's already solid, but greyed), I think this might be helpful in terms of helping players see the final formation, but it's possible that some sort of visual marker to distinguish it from an actual unit would be helpful to avoid confusion, particularly after the multiplayer aspects are implemented (it might actually be fine; I'm not sure without testing). I also wonder whether the orb that normally shows whether a unit has moved would be useful on the images of planned positions, regardless of whether they're coloured.

As of (2), the actual unit does take priority presently unless you mouseover the hex, I guess we could reverse it.

Reversing has the minor problem that it's a little weird if you move the mouse there because you want to plan another move for the planned unit there, and only then see the unit you're not issuing a command for. I think this would be made up for by the clarity of viewing final formation, though. However, it's possible that if the actual unit were quite transparent and the planned unit solid underneath, that that would solve the issue here without any reversal (being able to see the planned formation while still able to discern which unit actually occupies the spot).

You could merge the planning mode with the normal mode - and the option would become "Plan every move" instead of "Enable planning mode".

I think this is a good idea in principle, but it might then be necessary to provide on screen buttons for execute and delete command, to cater for players who use the mouse exclusively. So long as these were reasonably discreet (and potentially appearing only when some moves are planned) I think this might be a good idea in any case.

An alternative, if you want a binary planning mode on/off, is to leave the current behaviour when the planning mode is off and implement the corrected version when planning mode is on. This is a hack, though, particularly given there's extra complexity with the 't' button currently which ideally should be replaced rather than added to. In fact the only thing I can say in favour of keeping the current behaviour is that you can happily just ignore the 't' button entirely and issue direct commands anew; it's not clear to me if that simplicity could somehow be kept with the whiteboard implementation.

If "Plan every move" is enabled, there is not much to say - it'd go as in current planning mode. You should also provide a hotkey for planning a single move even when "plan every move" is disabled - for example holding Alt when issuing order (I don't think Alt is used currently).

It turns out there already is such a hotkey -- Tab.

[battlestar]

I would love to see multi-turn planning:

It could be a helpful tool for scenario coders to plan complicated cut scenes if the planning mode could be made to plan for multiple turns. The number of positions would still be displayed on upper right corner while number of turn it would take to reach that position is displayed on lower right corner. Double positive if a table could be generated listing the coordinates of each stop for units with plans.

[gabba]

You guys should go check out version 1.9.9 which was just released: it includes all the work tschmitz did for gsoc this summer, including:
* see your allies' plans over the network
* multi-turn planning (still missing a proper display of turn numbers on the arrows)
* several bugs fixed

Of course there are some quirks, new bugs, etc, but the results achieved are pretty cool. I'm still fixing bugs as we speak for the next version.
I'm looking forward for your feedback!

@Zaroth and Scatha, I'm not answering in detail for now for lack of time, but I like your ideas. Try the new version and eventually adjust your proposals to the current state of the wb, and we'll discuss further.

[Often]

I am currently away from regular computer/internet (and hence no BFW) but I have been looking forward to this feature for a while. Hopefully it will be part of the stable branch soon, but I may just play a game or two with the girlfriend in the development version of the game to see what we think. Very exciting and useful feature I am expecting!

[Kolbur]

After playing around with this for a bit I can give some feedback now:
It seems that this feature covers almost everything one could do with the old delay shroud updates and more. I agree that more emphasis should be put on the resulting positions, right now it looks very crowded with many units and the important resulting formation is a bit hard to make out. Ctrl-v seems to work correctly in respect to the final formation. It takes some time to get used to it (why is the shortcut for removing a planned move h and not u like it was with undo btw?), but I would definitely appreciate a execute all planned moves option. The step by step execution of a plan is not very interesting for me. The break from spotting "new" units can be quite annoying too since I probably either know about them already due to prior scouting and they just were under shroud again or don't care for them when making my formation. It can be useful though so I guess the execute all option could have this break from spotting a new unit disabled. This way I have the option to play slow and safe or to execute the whole damn plan already.

There is one thing that the planning system doesn't manage though: When planning an attack and checking the possible damage the calculation doesn't take abilities like backstab, leadership and illuminate into account. This is unfortunate because checking the possible damage outcomes without actually commiting to the attack was a major feature of the old delay shroud updates for me. (Scatha mentioned it already up there)

Edit: just read that there is a shortcut to excute all planned moves, it should probably be a bit more obvious in the interface

[gabba]

Hey Kolbur, thanks for the feedback! Just answering on a few points:
- The keys are not set in stone and I'm still testing various configurations and trying to see what works best. Undo still works as usual so for now I left it on a separate key, but I tend to want to use 'u' as well to delete moves. So maybe 'u' should just start by deleting planned actions, and once there are none undo regular ones.
- You can disable the stopping when new unit is spotted in the options, and all keys except tab are rebindable.
- Leadership, illuminate and backstab are now fixed in svn trunk, it was a bug.
- About execute all, I already have a plan to make it more obvious.

I've discussed the interface quite a bit with Ivanovic and Boucman and I think we've found a way to reduce clutter and make the whole thing more intuitive. More on this soonish.

[beetlenaut]

Apparently, you removed the waypoints feature to fix a problem with the interaction with the whiteboard. You doubted it would be missed, but I do miss it. It was my favorite new feature. You can do the same thing with the whiteboard, but it is arguably more work than just moving the unit each turn, and using waypoints was much less. I used them like this: Click on the bat, hover over villages hitting "w" on each, then click on the last village and forget about him for a while. With the whiteboard, I have to select each move of the unit one at a time, then remember to execute those moves on each turn after that. (Since I don't, I also have to deal with the popups.)

If you didn't allow waypoints to be selected while you were in planning mode or with a ghost unit, that would be perfectly acceptable, and seems like it would also take care of the bug.