Since its the closest and most recent example - there you go.
Imagine a game not unlike Frozen Synapse, but instead of having to input a sequence of actions for your units - they can move and shoot completely independently. That is, let's say, a robot, where you order the legs to go here, and the upper body to shoot over there, and it executes those two orders simultaneously. With me so far ? Like a strafing FPS player, no ?
But ! What if you can move, and shoot, but if you shoot WHILE MOVING - your maximum movement range is reduced, say, by 10%. How do you go about conveying to the player his possibilities ? What i came up with, let's say you announce the maximum range for just moving, by a colored circle overlay on the ground, right ? Then, you show another, differently colored overlay ring, to show where are the player's limits if he moves and shoots. Easy, right ?

But ! What if, the unit has MORE than one weapon, and EACH ONE reduced the maximum range ? What to do then ? You dont know how many weapons the player will choose to fire. What, make more and more colored overlays ? Its a bit unwieldy and leads to major confusion, wouldnt you say ?
Besides, as a player, imagine, you order your unit to move over there, then select a target, and find that you cant move as far anymore ! And have to fix your turn ! Then you choose to fire a second weapon as well, and yet again your maximum range has shrunk and you are forced to fix everything. Isnt something wrong there ?
The idea is that the player should be able to (ideally and eventually) give the orders he wants without fixing, from the first attempt. Scrapping and starting your turn from the start not because of bad planning, but for the reason of interface resistance - thats baaaad.

Your thoughts ?

Seems like you're talking yourself into and then out of an idea. In your argument, you decide it might be fun to move and shoot independently in a turn-based game. You stifle that a bit by reducing movement range when attacking at the same time, and perhaps more-so with each weapon the character is using. You then reason that by doing this, you're left with an icky situation where you must robustly indicate to the player that he can't move as far on this turn.

I'd just back it up and make a demo where the player can move and attack on the same turn in a turn-based game... and to that end, that's exactly what you do in Front Mission and Final Fantasy Tactics, both of which robustly indicate when you can't move as far.

that's exactly what you do in Front Mission and Final Fantasy Tactics[/quote]
I dont remember anything of the sort in those games. I think you missed my point that both actions are executed simultaneously, a la Frozen Synapse. If i was talking about "traditional" turn-based game - then there wouldnt be a problem, such games have existed for ages, even going back to board games.

Let the player make the choices and then execute them as possible. If a shot fails because (a) the opponent has moved away, or (b) the player has no ammo, or (c) the player shot in the wrong direction, or (d) the player has ignored the movement speed, or ... then it is the responsibility of the player, isn't it? Isn't this a strategic aspect of the game anyway?

If a shot fails because (a) the opponent has moved away, or (b) the player has no ammo, or © the player shot in the wrong direction, or (d) the player has ignored the movement speed, or ... then it is the responsibility of the player, isn't it?[/quote]

Yes, that is true. But you are talking about the consequences of player's turn, after the fact. Player is responsible for his own decisions, but i'm talking about an interface issue that could cause the player to scrap his orders and start over several times with no fault of his own.

I could draw a cartoon to help people picture what i'm talking about better, but in the past i've been told that my cartoons make it even harder to understand the issue, lol.

If a shot fails because (a) the opponent has moved away, or (b) the player has no ammo, or © the player shot in the wrong direction, or (d) the player has ignored the movement speed, or ... then it is the responsibility of the player, isn't it?

Yes, that is true. But you are talking about the consequences of player's turn, after the fact. Player is responsible for his own decisions, but i'm talking about an interface issue that could cause the player to scrap his orders and start over several times with no fault of his own.
[/quote]
I understood that (or so I hope at least), but IMHO giving the player so many informations that s/he totally able to avoid a couple of "strategic" failures takes away that kind of responsibility from the player. Hence my point is: Let the responsibility at player's hand and give only necessary informations.

I admit that I'm not familiar with Frozen Synapse. However, a board game came to my mind where the playground is a grid in which different kinds of asteroids wander around. The player has to steer a starship to an (also moving) goal. How the asteroids move depend on 3 different dices, and colliding asteroids interact dependent on a set of rules. The player has to define up to 7 moves of his starship in sequence after the dices are rolled. The game mentioned is turn based, but that isn't the point. The point is that the player can calculate how the asteroids will move, and s/he has to plan so that the starship will move towards the goal without colliding with an asteroid.

I thought more in direction of such strategic planning, driving an over-complicated interface as mentioned in the OP superfluous (not directly an answer to the OP, I know).

The player has to define up to 7 moves of his starship in sequence after the dices are rolled.[/quote]
Thats the thing, if its "in sequence" - then there is no problem. But if its not ?

Okay. Let's take a more specific example. In a traditional turn-based game, let's say you have a unit with 10 action points. Move one tile costs 1 point, shooting costs 3 points. Let's say you move 8 tiles and want to shoot - you find that you cant, because you only have 2 points left and shooting costs 3. What do you do ? Well, if the game has "undo turn" - you undo and easily fix things, if not - then you wait for the next turn and dont forget to keep 3 points if you want to take a shot. If you want to take two shots - you mentally (or with a special function on GUI) reserve 6 points leaving you 4 points to move around with.
The point is, with such a system - players will only have to fix his orders in rare moments of absent-mindedness, or if he misclicks, or something to that affect. Most of the time players will make units act exactly as they wanted to from the start.

Now, in a system i have in mind, its a bit different. Let's say you have a unit that can freely move 40 meters on the ground per turn in any direction of your choosing. You can see the maximum radius as a circle. So the player just clicks anywhere inside that circle and the unit will move there after the "GO" button has been pushed. But shooting in the same turn will cost 10% of that 40 meters. So what can the player do if he wants to move maximum distance while at the same time taking a shot ? If he gives order to move first, and shoot second - after the orders are given - it turns out the unit cant carry out the orders, because it cant travel that far anymore. So the player has to undo and basically eyeball 10% off the radius to find where he can move. It doesnt matter that much if its just 10%, but if there's more and there are different values - it gets really tricky, certainly much more complex than basic arithmetics, and is, after all, just guesswork.
But if player can order to shoot first, and move later - he can already see that the maximum radius has shrunk, so thats dealt with. However it gives birth to a whole lot of other problems, like line-of-sight availability, and so on.

The player has to define up to 7 moves of his starship in sequence after the dices are rolled.

Thats the thing, if its "in sequence" - then there is no problem. But if its not ?
[/quote]
How can it not be in sequence? Even if you reduce the time consumed by a turn to 0 you have the problem that a movement changes the location. Shooting before the movement allows to aim at other targets than shooting after the movement (or during the movement). Hence the player needs to have the possibility when (better "where") to shoot. So isn't it the case that the player either says "shoot" (what consumes some of the available energy) and then travel (what can be done only with the remaining energy) or the other case around? When the available energy is reduced by each step, then the player isn't able to spend more energy than it is available. Of course, deleting a step in the plan would give back its energy.

So the plan looks like a stack of orders. The player would be able to insert new orders into the plan as long as the remaining energy is enough for the selected action. S/he is also able to delete orders from the plan. When selecting an order the system is able to pre-compute the location (when ignoring unforeseeable occurrences). The target area around those location can be shown when the player picks a shot as new action.

Perhaps I still lack of an understanding of what you want to do...

Movement changes location and hence the targetable area, so the order or movement and shot plays a role for sure. Because of this, the player is required to build an ordered list of actions a.k.a. "the plan". Creating an action reduces remaining energy, and an action cannot be created if the energy reservoir is too low.

Now imagine that there is a plan, a factory for actions where to fetch new actions from as long as the energy allows it, and a pool where the player may (but need not) deposit actions after fetching them from the factory and before placing them into the plan. So s/he may "reserve" actions (not to say the energy for those actions) without already inserting them.

Imagine further that the plan is visualized as a list of actions, and the particular actions can be selected as insertion point and dragged to another place. This allows to insert new actions in-between already scheduled ones. Interestingly, this concept would allows that the aforementioned pool need not be given as a distinct element but may be implicitly given by the plan, too.

It's a bit too theoretical, but if i got you right, you seem to be saying that the player should plan to "declare" his possible actions previous to the actual Plan he will eventually make ? Its a bit counter-intuitive, isnt it ? Are you saying that, basically, the player should declare as many various actions as possible, and then actually use only those that he needs ? Is that what you are saying ?