Preferred target: Closest
Moderators: marionline, SDHawk
Preferred target: Closest
Hello,
I would like my hero's melee attacks to target the "closest" enemy only. An example would be, I wish to have a battle formation of 3 warriors with a mage at the back and the hero must take out the warriors before being able to strike at the mage (unless they have a ranged weapon, in which case they may target whomever they wish).
What is the best way to do this? I have experimented with "prefer target: closest", as well as setting "Target setting: first target" on. Do these 2 settings conflict? It seems that the enemy in the first slot will be the one targeted in this case. Is "prefer target: closest" based on the enemy's geographic proximity to the hero(es)?
Many thanks.
Edit: It seems to me that the only way to ensure that the closest enemy is targeted is to turn on the bitset "automatically choose a target". It's less than ideal as then you cannot see the name of the enemy you wish to attack, as well as not having a chance to back out and choose another action if you change your mind. I want the player to only be able to target the closest enemy with this particular attack, but still have the targeting cursor appear etc.
I would like my hero's melee attacks to target the "closest" enemy only. An example would be, I wish to have a battle formation of 3 warriors with a mage at the back and the hero must take out the warriors before being able to strike at the mage (unless they have a ranged weapon, in which case they may target whomever they wish).
What is the best way to do this? I have experimented with "prefer target: closest", as well as setting "Target setting: first target" on. Do these 2 settings conflict? It seems that the enemy in the first slot will be the one targeted in this case. Is "prefer target: closest" based on the enemy's geographic proximity to the hero(es)?
Many thanks.
Edit: It seems to me that the only way to ensure that the closest enemy is targeted is to turn on the bitset "automatically choose a target". It's less than ideal as then you cannot see the name of the enemy you wish to attack, as well as not having a chance to back out and choose another action if you change your mind. I want the player to only be able to target the closest enemy with this particular attack, but still have the targeting cursor appear etc.
Last edited by guo on Tue Mar 08, 2016 12:31 am, edited 2 times in total.
vvight.wordpress.com
Prefer Target: closest does indeed depend on the distance between the combatants.
If you want to be able to kill the warriors on the front line in any order before getting to target the mage, that's trickier. There are no targetting settings to allow something like that (and I can't even think of how a built-in for that would work). You could do something like having two versions of the mage, one of which is untargettable, and when the mage is alone it hits itself with an target to transmogrify itself into the targettable version.
If you want to be able to kill the warriors on the front line in any order before getting to target the mage, that's trickier. There are no targetting settings to allow something like that (and I can't even think of how a built-in for that would work). You could do something like having two versions of the mage, one of which is untargettable, and when the mage is alone it hits itself with an target to transmogrify itself into the targettable version.
That is exactly what you get if you use Prefer Target: closest and Target Setting: First Target. Don't use the bitset to skip attack confirmation.I want the player to only be able to target the closest enemy with this particular attack, but still have the targeting cursor appear etc.
Last edited by TMC on Tue Mar 08, 2016 12:36 pm, edited 2 times in total.
- Bob the Hamster
- Lord of the Slimes
- Posts: 7658
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
You can work some crazy wonders with non-targettable enemies and spawning. Imagine this scenario:
1 mage while warriors are alive = 1 untargettable enemy
1 mage when warriors are dead = 1 targettable enemy
The untargettable mage has its usual attacks for "normal", but then when "alone" it has an attack that kills itself while spawning the targettable version. There will be some tweaking necessary here I'm sure, but this is the setup I would probably try for.
It would be nice if the chaining logic for attacks included something like "if enemy/hero formation slot x is full/empty, alive/dead". This would allow for fairly easy cheats within the current framework to simulate some basic concepts like this.
1 mage while warriors are alive = 1 untargettable enemy
1 mage when warriors are dead = 1 targettable enemy
The untargettable mage has its usual attacks for "normal", but then when "alone" it has an attack that kills itself while spawning the targettable version. There will be some tweaking necessary here I'm sure, but this is the setup I would probably try for.
It would be nice if the chaining logic for attacks included something like "if enemy/hero formation slot x is full/empty, alive/dead". This would allow for fairly easy cheats within the current framework to simulate some basic concepts like this.
I am Srime
This system you're describing sounds a lot like the battle system in Inindo: Way of the Ninja (which is worth checking out for game designers, as it does some interesting things with the RPG genre). Your party members and the enemies can move to different positions in the battle screen. You may only melee attack an enemy that is adjacent to you, meaning enemies can body-block you from getting to other enemies.
As you proposed, ranged attacks can target anyone. I guess msw188's method wouldn't work with that.
I guess nothing quite like this is possible in the OHR's battle system, but you might be able to simulate some of the parts of it? Either way, I think you have an interesting idea.
EDIT: image won't work. don't know why.
http://i0.wp.com/snesaday.com/wp-conten ... =312%2C291
As you proposed, ranged attacks can target anyone. I guess msw188's method wouldn't work with that.
I guess nothing quite like this is possible in the OHR's battle system, but you might be able to simulate some of the parts of it? Either way, I think you have an interesting idea.
EDIT: image won't work. don't know why.
http://i0.wp.com/snesaday.com/wp-conten ... =312%2C291
Last edited by kylekrack on Tue Mar 08, 2016 6:43 pm, edited 1 time in total.
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
- FnrrfYgmSchnish
- Metal Slime
- Posts: 741
- Joined: Thu Jun 18, 2009 4:37 am
- Location: Middle of Nowhere
Couldn't this use a self-targeting transmogrifying attack now rather than "kill self, spawn the version you can target" method that used to be the only way to do this? No need to set up blank enemy spots to guarantee spawning in the right position that way.The untargettable mage has its usual attacks for "normal", but then when "alone" it has an attack that kills itself while spawning the targettable version. There will be some tweaking necessary here I'm sure, but this is the setup I would probably try for.
FYS:AHS -- Working on Yagziknian NPC walkabout sprites
Thanks for the replies.
I was playtesting most of yesterday using "prefer target: closest" and "pick target automatically" and it was giving me the effect I was after, albeit with the obvious drawbacks.
The problems I can see with the untargetable mage that becomes targetable when alone are:
*The hero does still have ranged spells
*Battles with more than 1 mage present
I think I will stick with the system I have in place at present, but will continue playtesting and trying different ideas.
-Regards
I was playtesting most of yesterday using "prefer target: closest" and "pick target automatically" and it was giving me the effect I was after, albeit with the obvious drawbacks.
The problems I can see with the untargetable mage that becomes targetable when alone are:
*The hero does still have ranged spells
*Battles with more than 1 mage present
I think I will stick with the system I have in place at present, but will continue playtesting and trying different ideas.
-Regards
Last edited by guo on Tue Mar 08, 2016 9:24 pm, edited 1 time in total.
vvight.wordpress.com
Yes, I explained the transmogrifying option. If you have multiple mages then you can't use Alone attacks. But you could instead set the "Boss" bit on the front row enemies, have the mages "die without boss" and then give the mages on-death bequest attacks that transmogrify themselves into the targettable versions. I at least I assume it would work.
I think you would have to settle for msw's use of "enemy types" to make non-ranged attacks fail; I don't see anything better.
I guess one of the large things holding back this sort of feature is all the hard coding of battle slot numbers throughout the battle system, but I'd say the biggest thing holding it back is that there are so many other worthy features to prioritise ahead of it.
I think you would have to settle for msw's use of "enemy types" to make non-ranged attacks fail; I don't see anything better.
Are you thinking of support for arranging enemies into rows, with some options affecting attacks on different rows? I think you've mentioned something like that.Bob the Hamster wrote:Someday I hope to add more features to the formation set editor, that would allow you to do what your are describing-- but I can't make any promises as to when I will get to it-- probably years
I guess one of the large things holding back this sort of feature is all the hard coding of battle slot numbers throughout the battle system, but I'd say the biggest thing holding it back is that there are so many other worthy features to prioritise ahead of it.
I agree that more possible chaining conditions should be added, because they're so important to creating complicated effects. I have an idea: how about we allow attaching tags to enemy slots in the battle formation editor, "set tag if this slot is occupied" and/or "set tag when this enemy dies". The latter would stay false if something else gets spawned in the slot, and wouldn't trigger if the enemy transmogrifies. And it's more flexible to put the tags on battle formations instead of enemy definitions so that different instances of the same enemy definition can have different effects (depending on where they're positioned, for example). We could add such tag-setting to enemy definitions too, though.msw188 wrote:It would be nice if the chaining logic for attacks included something like "if enemy/hero formation slot x is full/empty, alive/dead". This would allow for fairly easy cheats within the current framework to simulate some basic concepts like this.
Last edited by TMC on Wed Mar 09, 2016 11:10 am, edited 1 time in total.
- Bob the Hamster
- Lord of the Slimes
- Posts: 7658
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
I was thinking that you could optionally assign enemy formation slots into groups, and then say something like "Group 1 prevents targeting of Group 2"TMC wrote:Are you thinking of support for arranging enemies into rows, with some options affecting attacks on different rows? I think you've mentioned something like that.Bob the Hamster wrote:Someday I hope to add more features to the formation set editor, that would allow you to do what your are describing-- but I can't make any promises as to when I will get to it-- probably years
I guess one of the large things holding back this sort of feature is all the hard coding of battle slot numbers throughout the battle system, but I'd say the biggest thing holding it back is that there are so many other worthy features to prioritise ahead of it.
There would also be an attack option to make long-range attacks that ignore group-based targeting prevention.
I also really want to do all the stuff in http://rpg.hamsterrepublic.com/ohrrpgce ... provements
Last edited by Bob the Hamster on Wed Mar 09, 2016 6:01 pm, edited 1 time in total.