ChopperDave wrote:All of that should be already happening in the battle code. If it's not, then we have a bug, cuz I put in all the code for that. If it's a party item/skill, left/right changes parties. If it's an actor or point item/skill, then left/right changes parties assuming the item is neutral and you're at the actor level of choosing. If you're choosing an attack point, then all four keys simply change the attack point you target.
Ahh, I see it now. The UpdateTargetSelection() and UpdateAttackPointSelection() functions are just a little umm, messy, so its hard to see whats going on.
Actually, I really like this control scheme I proposed:
Up/Down: toggle between various actors in the same party
Left/Right: toggle between various attack points on the same actor (if the skill selected is indeed attack point specific)
Left/Right select: toggle between character and enemy party targets
My reasons for preferring this scheme are both for design -and- for code reasons:
1) Toggle between parties is something that the player is not likely to do very often. Thus, it makes sense to bind it to keys which are out of the way and also not used often
2) The arrow keys perform the same function regardless of the target type for the skill/item. Consistency is a good thing
3) It reduces the amount of key pressing from the user to browse and select targets. Currently you have to select an actor, confirm, select an attack point, confirm to execute an action. With this scheme you only need to select an actor, select an attack point, and confirm. This is a good thing
, because one of the weaknesses in our battle system is that it takes longer than is typical to select a target and execute an action.
4) In the code, I think implementing this scheme would greatly reduce the complexity (and hence, size) of the selection code. It would reduce BattleMode::_UpdateTargetSelection() and BattleMode::_UpdateAttackPointSelection() to a single function, and we wouldn't have to do as much fiddling with cursor states and examining context when we process key presses from the player.
What do you think? I'm actually just about to work on these two functions to make them compatible with my changes, so I'm kind of anxious to go ahead and implement this scheme if I unanimous approval for it.