Share undoable moves with allies

[gabba]

Heh, I knew bumping this up would cause some confusion. So to clarify things a bit:

The latest version of this idea is here, it's my GSoC proposal actually. Right now I'm mainly using this thread as an image repository. Your comments are welcome, but I don't expect having a lot of time to answer them. I'll try to take into account constructive criticism though!

--

When sharing undoable moves, some mild confusion might happen when you ally undoes a move: if you're not paying attention (after all the unit just changed from "red" movement status to "yellow" or "green" orb), you might think you're witnessing a move instead of an undo. This is why extra visual clues would be needed in that mode, possibly just a red UNDO text that floats up from the unit, or alternate red footsteps symbols that the unit gobbles up backwards as it goes back to its previous location.

i don't see why you would want to add any additional visual information - nobody would ever have complained about seeing all moves if it had been implemented this way from the very beginning.

is there a reason why this shouldn't just be the default (for allies and enemies)? - maybe network traffic/performance?

This issue is obsolete, since the proposal has changed so much since I started this thread.

For the true "over the shoulder" experience, I think this option should show you everything, down to the attack dialogue your ally gets when he attacks an enemy.

nice, but sounds quite complicated - don't forget that right now you're free to do stuff in the ui (e.g. show unit information) during enemy/ally turns...

Quite complicated as you say. The idea would have been to show the dialogs you ally sees in a non-interactive way, and hide them or make them transparent when they get in the way of your mouse. You would've kept interface access, of course. But again this is not relevent anymore.

What I will try to do if I have time is to let you examine the combat odds for any attack you or your ally has planned. (cf. the text of my GSoC proposal to get some context for this.)

[em3]

A quick note after reading the GSoC proposal:
What do you think about preserving the current behavior of left click and make shift-left click as the trigger for creating a planned action. This would make it more consistent with interface in other strategy games (both RTS and turn based) and would be less confusing for regular wesnoth players.
Alternatively the effect of shift (plan or perform) could be made configurable in options...

[gabba]

A quick note after reading the GSoC proposal:
What do you think about preserving the current behavior of left click and make shift-left click as the trigger for creating a planned action. This would make it more consistent with interface in other strategy games (both RTS and turn based) and would be less confusing for regular wesnoth players.
Alternatively the effect of shift (plan or perform) could be made configurable in options...

I thought of that too. I'm rather leaning toward the solution to make the planned action a default, because players are used to be able to undo most of their moves: my plan is to extend that further. However having an option to reverse the shift-click behavior is a reasonable request, and I'll probably do that so players can adjust the interface to their playing style: "plan a lot, do regular moves sometimes", or "do regular moves a lot, plan sometimes".

[chains]

First, let me say CONGRATULATIONS. This project is very exciting and stands to fix some of my major hangups in the wesnoth interface encountered by new players.

Error questions:
What happens when a user builds a plan and then hits end turn instead of commit? Will they end turn without moving anything? Will they get a warning that says they have unfinished plan moves? Will this warning include a button to execute the plan first? Will their plan be committed or ignored when end turn is clicked.

What happens when my ally creates 50 moves worth of plans all over my screen? Remember, I have a really crappy Intel on-board graphics.
Can Wesnoth still be played entirely with the left click mouse button and no keyboard shortcuts while planning mode is turned on?

Comments:

• The visuals appear solid. But, perhaps the arrow should end in the hex prior to the ghost? towards the edge of that hex.
  
  The words Commit, Cancel and Execute are programming terms. We should replace these with more player friendly terms like: Undo, Finish, Complete, Done, or Move.
  A method for executing a move with planning enabled: 1st click with a selected unit on a hex is planned, a second click on a planned hex with a planned unit selected commits the move.
  
  Planning mode should have a preferences check box, so that if I turn it on in a game it will be on the next time I start a game. It should not work like delay shroud updates currently does.
  
  "if a unit is selected when Execute All is called, only moves numbered equal or higher as the number of the current unit will be executed." If a user selects "Execute All" this button should do exactly what it claims to. If it pauses halfway through execute all because a unit was selected, the user is left confused. As long as commit all pauses on blocking events, most users will not want to pause a most of the time commit.
  
  Canceling planned actions can also be done with the current undo command. If a player presses 'u' or undo and they have planned moves displayed, it can take back the most recent planned move before undoing committed moves.
  
  The most common method for interacting with the plan will be to clear it and start over when an event happens.
  
  Holding shift while playing should skip planning and commit. However, the behavior of shift click should not invert. This will confuse players and cause user errors as they shift click during planned mode and execute by mistake thinking planning mode was off.
  
  Planning actions while not my turn: I click the screen ALOT while it's not my turn, mostly to adjust the camera and view unit information. I would not want these to build plans on accident.
  
  Planned moves should still be animated when committed unless accelerated game speed is enabled because they convey valuable information to the player so that they understand what happened.
  
  Commit all could be the default behavior. Commit next would not be necessary assuming 'commit all' paused after each blocking event like sight, ambush, combat. I would not want my units to continue with a plan in the event of 4 hits on an 20% defense unit all missing. This would be disaster.
  
  To toggle before plan/after plan states, the player can toggle planning off and on with no need for the tab key because shift p and tab appear to do a similar thing.

Comments on keyboard shortcuts:

• 'a' and 'z' would map more naturally to up and down than z, x (left right)
  
  Planning should turn on with p not shift+p because this is a non destructive command, we don't need it to be difficult to turn on.
  
  The short cut for clear labels might work to "clear a plan" if planning is turned on.

[chains]

This post is another method to implement the same feature with a lot less design complexity.

Add arrows to the default interface for all undoable moves. So in games with no fog, or in games with "delay shroud updates", or for moves that do not cause a blocking event. Place the ghost where the unit WAS not where it's going to be. When a person makes a blocking move, like getting ambushed, or attacking, then make only that move committed. Leave all other undoable moves still undoable. Pressing undo will undo all units one at a time other than the one that was blocked. Add the ability to undo a specific unit out of order by right clicking on it. Change recruiting so that recruiting is now an undoable event. When a user undoes a recruit, return their gold and remove the unit.

Finally, update allies every time you make a move whether or not the move is undoable. If you undo a move, update your allies again.

[pauxlo]

Change recruiting so that recruiting is now an undoable event. When a user undoes a recruit, return their gold and remove the unit.

The only cause recruiting now is (mostly) non-undoable are random traits for units (the principle is that nothing which gives new information can be undoable). So there are two solutions to this:

• remove random traits
• don't show the random traits until committed (= the unit stats are wrong until then)
• change the principle (but then one could undo and redo recruiting until the unit comes up with the desired traits).

[gabba]

First, let me say CONGRATULATIONS. This project is very exciting and stands to fix some of my major hangups in the wesnoth interface encountered by new players.

Thanks chains for your feedback. There's a lot to answer!

Error questions:
What happens when a user builds a plan and then hits end turn instead of commit? Will they end turn without moving anything? Will they get a warning that says they have unfinished plan moves? Will this warning include a button to execute the plan first? Will their plan be committed or ignored when end turn is clicked.

Planned moves will persist from turn to turn, so that you can have multi-turn planned moves. Some warning might be needed, that's a detail to solve later on.

What happens when my ally creates 50 moves worth of plans all over my screen? Remember, I have a really crappy Intel on-board graphics.

Wesnoth rendering is CPU-bound, but even then I don't expect problems, according to boucman explained me.

Can Wesnoth still be played entirely with the left click mouse button and no keyboard shortcuts while planning mode is turned on?

Good question. It's probably a good thing to keep it playable with the mouse only, especially if we think about the small devices ports.

Comments:

• The visuals appear solid. But, perhaps the arrow should end in the hex prior to the ghost? towards the edge of that hex.

TBD

The words Commit, Cancel and Execute are programming terms. We should replace these with more player friendly terms like: Undo, Finish, Complete, Done, or Move.

I'm with you on this, except that cancel is pretty widely understood, and undo is pretty much on the same level as cancel.

A method for executing a move with planning enabled: 1st click with a selected unit on a hex is planned, a second click on a planned hex with a planned unit selected commits the move.

Interesting idea, but it conflicts with the idea I had of eventually allowing click-and-dragging of unit ghosts. And with that of allowing planning several moves for the same hex, too (useful among other things for the future display of combat odds, i.e. with how many walking corpses do I need to attack this paladin from the same hex before I'm 90% sure he'll be dead).

Planning mode should have a preferences check box, so that if I turn it on in a game it will be on the next time I start a game. It should not work like delay shroud updates currently does.

Agreed.

"if a unit is selected when Execute All is called, only moves numbered equal or higher as the number of the current unit will be executed." If a user selects "Execute All" this button should do exactly what it claims to. If it pauses halfway through execute all because a unit was selected, the user is left confused. As long as commit all pauses on blocking events, most users will not want to pause a most of the time commit.

I agree about the misnomer. The reason why I wrote what you quoted is that I wanted to allow the user to commit only part of his plan. Not sure it's necessary, though.

Canceling planned actions can also be done with the current undo command. If a player presses 'u' or undo and they have planned moves displayed, it can take back the most recent planned move before undoing committed moves.

The problem with this is, what happens if you commit a specific planned action (out-of-order committing is a key feature) and then want to undo it?

The most common method for interacting with the plan will be to clear it and start over when an event happens.

Not so sure. If you're fighting on two fairly separate fronts, you'll want to cancel a few orders and keep the rest.

Holding shift while playing should skip planning and commit. However, the behavior of shift click should not invert. This will confuse players and cause user errors as they shift click during planned mode and execute by mistake thinking planning mode was off.

The popular suggestion to solve this was to have a very conspicuous visual clue that you are in planning mode. So, a large icon, or the border or the map area changing, or something like that.
But overall, you're suggestion that planning moves be completely unavailable outside planning mode?

Planning actions while not my turn: I click the screen ALOT while it's not my turn, mostly to adjust the camera and view unit information. I would not want these to build plans on accident.

Do you often accidentally select units and then left click elsewhere? Seems a bit unlikely to me. Otherwise, we probably need an option to have planning mode on or off by default when it's not your turn.

Planned moves should still be animated when committed unless accelerated game speed is enabled because they convey valuable information to the player so that they understand what happened.

Hmm, you mean with "Commit All"? In any case, I recently realized that not animating them would be more complicated. I wanted to at least make move (not attack) animations very short so that planning+executing would not be much more cumbersome than just moving. I hope that planned moves can replace undo, which I find to be a pretty clunky system.

Commit all could be the default behavior. Commit next would not be necessary assuming 'commit all' paused after each blocking event like sight, ambush, combat. I would not want my units to continue with a plan in the event of 4 hits on an 20% defense unit all missing. This would be disaster.

The plan is that "Commit All" does stop on any blocking event. And yes, I guess Commit Next wouldn't be essential. It's no extra effort to implement, but we don't wanna clutter the interface.

To toggle before plan/after plan states, the player can toggle planning off and on with no need for the tab key because shift p and tab appear to do a similar thing.[/list]

I think you misunderstood: shift-p is supposed to affect whether you're in planning mode or not, i.e. whether the default action is planning moves or committing directly. The Tab key wouldn't affect that at all, it would rather provide an alternate view (or a preview if you will) of planned moves, and still allow you to add/modify planned moves.
Note that the tab-key feature is marked as optional in my calendar.

Comments on keyboard shortcuts:

• 'a' and 'z' would map more naturally to up and down than z, x (left right)

z and x let your fingers rest on the same keys, it's more comfortable than a,z that are better used by moving a single finger. Anyways the up/down metaphor could just as well be move left/right in a horizontal list, so I don't see the key disposition as important here.

Planning should turn on with p not shift+p because this is a non destructive command, we don't need it to be difficult to turn on.

Sure, that makes sense.

The short cut for clear labels might work to "clear a plan" if planning is turned on.[/list]

You mean clearing labels+plans together with the same command? It could save a menu slot, but couldn't it be annoying in some use cases?

This post is another method to implement the same feature with a lot less design complexity.

Add arrows to the default interface for all undoable moves. So in games with no fog, or in games with "delay shroud updates", or for moves that do not cause a blocking event. Place the ghost where the unit WAS not where it's going to be. When a person makes a blocking move, like getting ambushed, or attacking, then make only that move committed. Leave all other undoable moves still undoable. Pressing undo will undo all units one at a time other than the one that was blocked. Add the ability to undo a specific unit out of order by right clicking on it. Change recruiting so that recruiting is now an undoable event. When a user undoes a recruit, return their gold and remove the unit.

Finally, update allies every time you make a move whether or not the move is undoable. If you undo a move, update your allies again.

Your idea has its merits, but it has several problems.
Well first, "delay shroud updates" must die a horrible death, because planned moves will be a good replacement, and because it breaks "sighted" wml events (a side-goal of this project is to fix them)
Also, it would not be easy to selectively commit only part of the undo stack. Not saying it's impossible, but a lot depends on that linear behavior, and I'd have to check every undoable move to see if it was affected by the recent blocking event (maybe it was a wml event that spawned walls somewhere...). Since undoable moves are part of the game state and therefore can affect events, I can't guarantee that they stay undoable if you don't commit them. With planned moves I can guarantee it, because they are "fake" and the game doesn't know about them.
In addition to the reasons above, recruits can't work this way because of random traits, as pauxio mentioned.

I considered the idea of having ghosts at the starting point instead of the ending, even for my current system; I think having them at the destination is better and easier to code, but then again I'm open to discussing it.

[gabba]

Change recruiting so that recruiting is now an undoable event. When a user undoes a recruit, return their gold and remove the unit.

The only cause recruiting now is (mostly) non-undoable are random traits for units (the principle is that nothing which gives new information can be undoable). So there are two solutions to this:

• remove random traits
• don't show the random traits until committed (= the unit stats are wrong until then)
• change the principle (but then one could undo and redo recruiting until the unit comes up with the desired traits).

Initially I'm just gonna show unit ghosts (so, "fake units") for planned recruits; hovering them won't display stats in the sidebar unless I find an easy way of doing it.

[chains]

Yeah replies to replies. Great points all through.

Do you often accidentally select units and then left click elsewhere? Seems a bit unlikely to me. Otherwise, we probably need an option to have planning mode on or off by default when it's not your turn.

Everyday I play Wesnoth someone says "misclick" and one of their units goes off in a direction that cannot be fixed. I then spend a minute explaining "delay shroud updates". This is the main reason I'm very excited about your features being built in by default. Most who play Wesnoth don't communicate with allies. But, they do misclick often and complain up a storm every time.

In addition to the reasons above, recruits can't work this way because of random traits, as pauxio mentioned.

If traits don't appear until after a blocking event then undoing recruits isn't a problem. This is probably something that could be implemented separate from planning mode if other people find this useful.

But overall, you're suggestion that planning moves be completely unavailable outside planning mode?

Your current design is to make regular interactions unavailable inside planning mode, but I was bringing up the idea that turning on planning mode might be another key than shift since shift currently enables accelerated speed. Mostly I am just concerned with shift becoming a possibly destructive key because I use it so often to speed up slow animations.

The problem with this is, what happens if you commit a specific planned action (out-of-order committing is a key feature) and then want to undo it?

If you commit an action and then hit undo the last thing done gets undone. If you plan an action, commit an action and then plan another action, and then undo twice your last plan will be taken back first, and then your last commit move will be taken back.

Interesting idea, but it conflicts with the idea I had of eventually allowing click-and-dragging of unit ghosts. And with that of allowing planning several moves for the same hex, too (useful among other things for the future display of combat odds, i.e. with how many walking corpses do I need to attack this paladin from the same hex before I'm 90% sure he'll be dead).

Clicking and dragging of ghosts with lots of units, ghosts, enemy units and ally ghosts all over a tight space overlapping each other.... This sounds like a potentially problematic area.

Your idea has its merits, but it has several problems.
Well first, "delay shroud updates" must die a horrible death

So, your saying, that merging planning with undo/delay shroud updates is too hard to code?

Making undo work more often, making undo-able moves shared to allies, and putting the "plan mode" arrows on the normal interface accomplishes most of your goals without the separate mode. While the separate mode will be powerful, don't overlook the chance to improve the default interface when planning mode is off.

Please feel free to ignore my ideas where they don't fit with your desires. Don't feel obligated to respond. I am hoping to create a brainstorm to flush out any areas that might cause problems later.

[Caphriel]

Well first, "delay shroud updates" must die a horrible death, because planned moves will be a good replacement

I strongly disagree. This planned move business looks awesome, but it also looks time consuming to use and complicated. I use delay shroud updates for misclick-protection, and would be very annoyed if it was removed and the only viable alternative was a system that was designed for multiplayer and was unnecessarily powerful for a 1v1 game. Especially in timed games, where quick and dirty can be more important than clean but slow.

[gabba]

With GSoC over and 1.9.0 out, you can now test the whiteboard yourself. Delay Shroud Updates have been disabled for this release so you can test the planning system as a DSU replacement, among other things.

The networked part hasn't been implemented during GSoC, but is still planned as a long-term development.

For feedback, head over to this thread.