11 replies to this topic

[Karnot]

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 ?

[Heath]

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.

[Karnot]

Quote

that's exactly what you do in Front Mission and Final Fantasy Tactics

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.

[haegarr]

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 © 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?

[Karnot]

Quote

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.

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.

[haegarr]

Karnot, on 05 February 2012 - 10:15 AM, said:

Quote

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.

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).

[Karnot]

Quote

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 ?

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.

[haegarr]

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.

[Karnot]

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 ?

[TechnoGoth]

sounds a bit confusing.
Traditionally as people have said before you have an action point system and the player has makes a combination of move and attack orders each turn. Move, shoot, move. or Move, Shoot, Shoot.

Maybe what you want to do is simplify that and have an easier interface.

So what about this you have two move radices the green one is move the range and red is the move and attack range. The player first chooses where to move, or to skip moving and stay where they are. If they stayed where they are or end their move in a red square then they enter attack mode. In attack mode every target they can attack at any point in their turn is highlighted with a cross hair. They then have a have a number attacks that they can divide between targets by clicking on them. After all attacks orders are given then the resolution phase happens and all orders are played out simultaneously.

This might mean that during the resolution targets are destroyed on route to their destination or targets move out of range before they can be attacked etc... This system assumes you have attacks and moves per turn rather then a common action point pool.

You expand on it by giving attack orders rather then specific attacks like:

• Concentrate Fire - Use all attacks on the first target seen
  
• Spread - Divide attacks around all visible targets.

[Waterlimon]

You could allow selecting multiple moves that are put in a queue, and then say how to do those moves, and it will make sure that you are left with enough energy to do the remaining moves.

like if you click the buttons MOVE, SHOOT and MOVE, you will have a list like MOVE, SHOOT, MOVE

First you will need to tell it where to move, so that you are left with enough energy to shoot and move some minimal distance.

Then it goes to the next one, so you need to tell it where to shoot (which will also make sure you are left with enough energy to move some minimal distance, unless shooting takes a fixed amount of energy)

Then you need to tell it where to move again. You might have energy to move 5 meters or a single step though, unless you add some way to tell that the last movement will need to be at least X meters.


Or, you could just allow telling all the things to do, and then be able to edit them. Like tell it to move, shoot and shoot. If theres not enough energy for the second shot, you could just drag some "Move here" object a bit closer to the start until the "Shoot" task turns green, indicating theres enough energy for that.

[Karnot]

TechnoGoth, on 06 February 2012 - 07:03 AM, said:

Maybe what you want to do is simplify that and have an easier interface.

You re-described what i wrote in the opening post, and therefore its subject to the same problems. It might kinda-sorta work out if we presume a unit to only have one weapon and/or only shooting once per turn. Not that i am adamant against that, but what i intend to do is to put small but progressive penalties on movement, the more weapons a unit has to shoot any given turn. Meaning there should be more than one weapon, etc. Like, say, a typical Mechwarrior robot, with cannons, lasers, missiles.

Waterlimon, on 06 February 2012 - 08:03 AM, said:

like if you click the buttons MOVE, SHOOT and MOVE, you will have a list like MOVE, SHOOT, MOVE

Sure, thats what haegarr proposed, if i understood him correctly. The thing is, with this system you will basically have to do every turn twice. I could call this "plan -> plot", first you imagine what you might need to do and "reserve" the actions, then actually lay them down on the gamefield. Its double work for the same result, i should say. There has to be a better way, call it a gut feeling.

Waterlimon, on 06 February 2012 - 08:03 AM, said:

If theres not enough energy for the second shot, you could just drag some "Move here" object a bit closer to the start until the "Shoot" task turns green, indicating theres enough energy for that.

Sure. The question is how often will the player get into situations where the amount of changes will reach the critical mass. Its a functional decision, and i've actually made a prototype like this before. The problem was, the way i was able to formulate it, that the people i gave it to test, thought that it felt wrong to correct the turn starting from the end. In their minds the turn was a linear progression, and they kept scratching the turn and starting over, instead of moving the "move here" goals.