Defining The Area You Must Hit To Ko

[Ishtvan]

I'd like to ask our AI modelers if it sounds feasible to define a separate damage zone for the area that you must hit in order to KO someone? Would it require putting all sorts of crazy bones in the head to be able to localize it to the back of the head? Here's a quote on how damage zones work:

 

"damage_zone head" "*Neck"

"damage_zone chest" "*waist -*Rshldr -*Lshldr -*Neck"

"damage_zone left_arm" "*Lshldr"

"damage_zone right_arm" "*Rshldr"

"damage_zone legs" "*Hips"

 

Damage_Zones: has the name this zone will be refered to as e.g chest included in the first parm.

Then a list of bones to include in the second e.g

*waist = every thing from waist upwards in the bone structure

-*Rshldr = minus everything from Rshldr upwards in the bone structure.

etc

 

The system I'm thinking of is, you define a damage zone like "damage_zone knockout" and the damage code checks to see if the weapon KOs and if the AI was hit in this zone. If it's a pain to define a damage zone just for the back of the head though, we'll have to do it another way.

[Domarius]

What do you think about the simplified method of - after a sucessful blackjack hit has occured, then check the direction the AI is facing relative to the player to see if the player hit them in the appropriate range in the back of th ehead?

 

That would directly mimic the diagrams Spring drew and we would have exact control over the angle you have to be on to blackjack them.

 

Also, it has to be less processor intensive this way.

[Ishtvan]

Actually it would be less processor intensive if we could set up a location area. That's basically just a grouping of joints/bones, and when an AI gets hit it's already calculating which joint/bone was hit and what zone that is in. Right now we know it's from the neck up, I think we just need another bone in the head or something to say from the neck up && behind this point.

 

We could conceivably do what you're suggesting Dom, it just seems like a roundabout way to see if you hit the right area. Also, you'd have to get the exact orientation of the AI's head in 3d, since it may be different than the rest of the body. Also, we don't know if we'll change melee combat so that it uses the actual arc of the blackjack instead of just the direction you're looking to calculate a hit. If we did, we'd have to rewrite this system.

 

I'll wait to hear from Odd or other modelers on how hard it would be to make an area defined by joints for the back of the head as opposed to just from the neck up like it is now.

[Ishtvan]

I may have spoke too soon. We can always get the point of impact regardless of whether we do some funky collision-based melee combat later on. I can just write it to use the point of impact, and some def file parameters to define the "sweet spot" (realtive to the eye position I guess), and Dom's method should work. Good suggestion.

[Ishtvan]

Finally got it working ingame. Actually, the idActor::Damage function where I was checking if the KO was in the right spot did NOT get passed the exact location of the hit, but it does now.

 

FM authors / modelers will be able to specify the following in the def file for AI:

 

// Knockout info

// name of the damage zone that must be hit for possible KO

// leave this blank to make AI immune to KO

"ko_zone" "head"

 

// defines the KO cone extending backwards from the direction AI is looking

// set to 360 if you want to be able to KO hitting anywhere on the head

"ko_angle" "120"

 

// by default the KO cone extends backwards from eye position

// use this var to offset it from that, relative to eye position - use to define a sweet spot offset from eye height

"ko_spot_offset" "0 0 0"

 

NOTE: Correctly locating the KO cone depends on having the eyes correclty located, which is set with the var "eye_height" Also, note that this eye_height is an offset from the origin, so either the origin must be properly located on the ground between the AI's feet, or "model_offset" must be set to put it there.

[sparhawk]

Do you also take into account the animations? What happens if the AI bends it's head or looks another direction?

[Springheel]

Sounds great, Ish! Will we be able to set default values for the various AI, or will FM authors have to do that all manually?

[Domarius]

Hooray!

 

Spar, the bones move with the animations, so will be fine.

[Ishtvan]

Sounds great, Ish! Will we be able to set default values for the various AI, or will FM authors have to do that all manually?

 

I already set up default values on ai_humanoid_base.def, which should be inherited by humanoid AI the FM author wants to put in. (I guess I should put some defaults on non-humanoids too).

 

I guess I should put in another optional parameter that rotates the facing of the KO cone, since right now the sweet spot will always be centered on the back surface of the head (the KO cone always extends opposite the front of the AI's head is facing), and someone might want it centered on the top of the head for an animal or something.

 

Do you also take into account the animations? What happens if the AI bends it's head or looks another direction?

 

I'm not positive. If idAI::viewAxis is the way they're looking with the head bone, which I think it is, then the KO stuff should be correct. If viewAxis is only the way their feet are facing, then we might have to change methods and get the direction of the head bone instead. My guess from looking at the code is that viewAxis is in fact the direction the head is facing, but I can't be sure 'cause it's not documented.

 

We'd have to do a test where the AI is looking around while keeping the feet in place to be sure. Unfortunately, the only "look around" anim currently ingame is the one after they draw the sword, at which point they're already too alerted to be KO'd. I guess I could disable the alert state checking temporarily and use that anim to test this.

[sparhawk]

I think the viewaxis is just the camera. I don't think it is neccessarily tied in with the anims.

[Springheel]

I already set up default values on the AI

 

Excellent! Does that mean we can set up everything according to the design docs?

 

1. Civilians (servants, townsfolk, etc) can be KO'd by a regular blow to the head from any direction, whether they are alerted or not.

 

2. Guards without helmets can be KO'd by a regular blow to the head from any direction, when unaware. When alerted, it takes a powerful hit to the back of the head.

 

3. Guards with normal helmets can be KO'd by a powerful blow to the back of the head when unaware. When alerted, they cannot be KO'd.

 

4. Certain guards (elite guards or guard wearing distinctive helmets) cannot be KO’d by regular means.

 

The above might be better as a value (KO-easy, KO-medium, etc), so that it could be easily modified according to playstyle/difficulty.

 

 

A few other things that we need to add:

 

Power-swings

The player can make two different attacks with the blackjack. Tapping the Attack button delivers a short, sharp swing that does 5 dmg if it hits the victim's head. This regular hit is sufficient to KO opponents who are unaware and not wearing a helmet. Holding down the Attack button for several (approx 5) seconds delivers a much stronger blow (similar to the way the sword works).

 

Flat-footedness

AI struck in the head with a blackjack (but not KOed) will take damage from the strike, and will be considered ‘flat-footed’ (see combat) for a few seconds. While flat-footed, an AI may attack, turn, and defend itself. It cannot, however, move to pursue a player.

 

Sound FX

Hitting an AI on the helmet (whether the KO is successful or not) is going to cause a muffled clang sound, about the same volume as a footstep on a marble floor.

 

Lightgem/Speed modification

While holding down the Attack button, the player is slightly more visible (about the same amount as having the bow out). His movement speed is also reduced slightly as he concentrates on hitting where he can do the most damage.

 

Reaction Speed

For a second or two after being alerted, however, AI will not be considered “alert” and may still be KO'd. An AI that walks around a corner and runs smack into the player can still be knocked out if the player acts quickly enough. After that second—even if the guard is not finished his ‘bark’—he is then considered alert and may or may not be able to be KO’d.

[Ishtvan]

I think the viewaxis is just the camera. I don't think it is neccessarily tied in with the anims.

 

What's your evidence for this? I looked at the code for lookAtEntity which definitely moves the head to look at things (as you can see ingame), and it checks viewAxis to see where the AI is looking. That's why I thought it's the head.

[sparhawk]

Ah. I only checked the players field of view (that was some time ago) and I had the impression that the camera was independent of the model. But it might be that this is only in case of the player and the AI is handled differently. I only assumed that it is similar.

[Ishtvan]

1. Civilians (servants, townsfolk, etc) can be KO'd by a regular blow to the head from any direction, whether they are alerted or not.

 

2. Guards without helmets can be KO'd by a regular blow to the head from any direction, when unaware. When alerted, it takes a powerful hit to the back of the head.

 

3. Guards with normal helmets can be KO'd by a powerful blow to the back of the head when unaware. When alerted, they cannot be KO'd.

 

Actually I don't want to put in too much about the alert state now, since SophisticatedZombie is changing that code, but I don't know how it will be stored yet until I talk to him. Right now I just disabled KO for all AI if they're above alert state 2 using the old code, but I don't want to code it in too much detail since it will have to be rewritten once SZ puts up the new system.

 

Crap, I forgot that the angle they have to be hit from will also change with alert state... that will take some rewriting.

 

I guess I must now pass additional parameters to idAI::Knockout: Whether it is a "power hit", what angle the attack comes in from (this was handled elsewhere but will need to be passed to AI if the angle changes based on alert state).

 

4. Certain guards (elite guards or guard wearing distinctive helmets) cannot be KO’d by regular means.

We can currently make guards immune to KO. The way to do it right now is to leave "ko_zone" blank.

 

Powered up Blackjack

I haven't added the "powered up" blackjack to the weapon script. How long should it take to power up and how are we going to let the player know that it's powered up? Animation? Sound? I guess it should work like the sword power up, but we don't have that either. Are you sure we all agreed that a powered up blackjack should reduce your speed? I thought that part was voted down or at least not agreed upon. Lightgem modifier we'll have to ask Spar about, we don't have one for crouching or movement yet, but once we do it can be coded the same way.

 

Other Issues:

As for flat footedness and reaction time, we don't have combat coded yet, and reaction time will be on the AI code in terms of taking some time to come to the next alert state.

 

Sound of the blackjack hitting depends on the surface type it hits. This shouldn't be a special case for the blackjack, but should be handled by making all sounds of something striking something else suspicious, that way the AI will hear it when you hit a wall or other metal object with the blackjack, too, as it should be.

[Ishtvan]

Ah, with the BJ "power up speed modifier," we were still disagreeing about when it should apply. I thought it should only apply to running, others thought it should apply to walking as well, and I guess everyone agreed that it should not apply to creeping.

 

We also disagreed about when the speed modifier should kick in; once you have powered up the blackjack all the way and are concentrating for a "power hit," or as soon as you raise it?

 

Personally I think it's already challenging enough to sneak up on an AI without worrying about powering up the blackjack, especially if they start turning their head from side to side when they hear the creep footstep behind them, and especially when an AI alerted above alert #1 will turn and face any additional sound they hear, but I guess the team has spoken.

[Ishtvan]

Okay, I added in the stuff that depends on alert, now the cone angle can change when they get alerted. Also rewrote it to be a bit cleaner. I put in a key to define the alert state name above which they are considered alert, in case we want AI with more than the 3 standard alert states.

 

I didn't differentiate "easy, medium hard", but I did make all the settings available, so it should be easy to make some different defs for guards at different difficulties.

 

I added power blows to the AI code, but they'll have to be set up in the weapon_blackjack script to actually power it up and deliver. I realised Domarius' sword does in fact power up, so I can re-use this code.

 

I'm a bit skeptical about whether we need the added difficulty of "power blows" after testing ingame though. It is already ridiculously hard to blackjack a moving AI when you're on a stone floor, since they hear your footsteps, creeping is the only safe bet, and if they're alerted and randomly searching, they change directions often, and you have to be pretty much right behind them in order to hit at the right angle to KO. They often turn around right into you while you're slowly stalking them and attack. Also, if you miss hitting the right angle, they attack you and you're screwed, so the "sweet spot" system itself adds a fair bit of challenge. It will get even more challenging once we add looking left/right while searching, since this will also make you miss the sweet spot.

[Springheel]

Also, if you miss hitting the right angle, they attack you and you're screwed,

 

Well, when we implement the flat-footed thing you'll have time to at least get a head start running away.

 

The power up feature wasn't really to make BJing harder overall...it was to make guards with helmets harder to BJ than guards without.

 

We can always leave it as is for now and playtest it for a while. If we find with playtesting that KOing guards is already quite hard, we can always do away with it.

[Ishtvan]

Yeah, we'll have to see; there are still a lot of things that will be changed in the release version, like response times and footstep volumes and how AI search for things. I put in the option for the script to send a "power up blow" in the code, it just needs to be put in the blackjack script.

 

Also, even if flat-footed, they can still rotate and hit right? If they've already got their sword out (because they're searching and alert), you might not have time to get away before they spin around and whack you one. They're fast.

[Domarius]

I put in the option for the script to send a "power up blow" in the code, it just needs to be put in the blackjack script.

Awesome I know this needed to be done because each weapon only could have one damage entity associated with it.

[sparhawk]

This setup should be documented in the design scripts and preferably on wiki as well.