Advertisement

Frozen Synapse - alike GUI dilemma.

Started by February 03, 2012 10:40 PM
10 comments, last by Karnot 13 years ago
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.
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.


o3o

Advertisement

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.


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.


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.

This topic is closed to new replies.

Advertisement