Saber system suggestions

[JRHockney*]

Well, part of the reason that the blocks aren't as "accurate" is due to me using the bounding box instead of the actual player model for the area at which the players block saber attacks. I did this to help with the illusion of sabers not passing thru player's bodies unless the swing actually hits the player for damage. However, the actual player models are still used for damage hit detection. Unfortunately, we have a limited amount of block animations that we can use for blocking incoming attacks. We could add in Keshire's block positions, but we can get to that in due time.

 

I see, so making it simplier than it is probably wouldn't do a thing. And I love that bounding box! It makes the combat look so much better. MB has a similiar function I think, but because everyones always running there, the saber still pass through people even though there is a draw back. The MB team decided to use this to cause gradual HP damage to shorten the saber fights, but I think it looks unrealistic. If only they would penalize running more!!

 

As for MB2's saber system, I'm not familar with what they internally after the cooperative split. I have a copy of the MB2 source from when Phunk moved on to other projects but I honestly haven't messed with it. Unfortunately, untagged code is very hard to port features. (Plus, I'm not into the mod porting business much anymore anyway. I got hellish, unorganized porting work dumped on me one too many times.)

 

Thats a shame, they could use a good coder like you. At present time, even though your saber system isnt quite as polished as theirs, yours definitely looks more movie realistic and probably even has more potential.

 

As for the parrying, that's the way the system currently works. IE, up-left attack can be blocked by any move made within one direction position of it (left, up, and left/up).

 

Wow, with in one space! Even diagnally! Thats easier than I thought, never mind.

 

I'll keep thinking based on this new information.

[razorace]

[JRHockney*]

I have a 2 questions and a suggestion and a bug report.

 

Question 1: when I successfully parry a person and their saber freezes, am I supposet to still lose DP? I notice I still do lose at least a little.

 

Question 2: Since the parry for a top down slice is back (s) because its inverted, does that mean that a parry for a top right (my right) slice is back-right (s and d) or is it inverted also to back-left?

 

Suggestion: I think that Tavions style and blue style should be slowed down to what yellow is now and maybe yellow style slowed down to desanns style but red stay the same. The speeds for tavion and blue are so fast that they end up rebounding most of way or all the way through the opponent and they are unbalanced because they are incredibly hard to defend against at that speed.

 

If you wonder why I suggest this, try fighting a tabbot in the holocron FFA who uses blue style, they are almost unbeatable without swing spamming. It is also more fun to watch and more movie like fight with slower styles because of the superior control and the cleaner rebound action (ahh huh huh...I said rebound action...huh huh huh).

 

Slowing down the styles a bit might also help with the hit detection (maybe). Along with this, it might be a good idea to make the faster styles weaker if they arent already. Of course, this is all assuming you don't still want to make all the styles the exact same speed.

 

Bug report: I notice that bots using blue style never freeze even in attack position when I parry them correctly and I don't recall ever freezing when I use it myself. Blue style bots and myself using blue and I think even tavions style only seem to get disarmed instead of briefly frozen.

 

I also noticed that when I try to kick in malee, I freeze in place for a few seconds.

[razorace]

1. Parrying still reduces DP by the same amount as normal blocks. I suppose we could try changing that.

 

2. Only the vertical axis is reversed. right/left is in terms of the player's left/right and not the attacker's. The reason why the vertical axis is reversed is for logical/gameplay reasons. An defender that is under attack from overhead swings (which is an advancing move for the attacker) would probably move backwards. Plus, from a gameplay persphective, this makes a defender naturally move backwards since an attacker is going to make a lot of overhead swings while he's moving towards the player (thanks for the JKA saber swing control system).

 

As for the attack speeds, I know this sounds unbelievable but the last time I checked, the actual attack animations ARE running at the same speed based on fps and frame numbers. At least this is the case for all the normal styles and probably the hidden ones as well. Granted, the starts/returns/transitions animations DO seem to take different amounts of time (most notably with the red style).

 

Anyway, a lot of the saber style's windup speeds are offset by swing range. While the blue styles do seem to move fast, they also don't have nearly the range as red or yellow.

 

That being said, I agree that styles do need some differences in terms of pros/cons to make them more even and enjoyable to use in their own right. I'm open to suggestions on what these pros/cons should be. However, I don't beleive in rock-paper-scissor saber combat so I feel that each difference needs to be justified logically.

 

For example, all single handed styles should have a penalty to their disarment chances since the sabers aren't being held by two hands. This is one way I think we can help balance the dual/double sabers vs the single saber styles.

 

I haven't seen a lack of slow bounces in the blue style but I'll keep an eye out of it.

 

Finally, the kicking bug has been resolved as of yesterday.

[JRHockney*]

1. Parrying still reduces DP by the same amount as normal blocks. I suppose we could try changing that.

 

Might be a good idea, but I suppose it could stay the same as long as the parried person loses more DP from that parry than you do from doing the parry.

 

As for the attack speeds, I know this sounds unbelievable but the last time I checked, the actual attack animations ARE running at the same speed based on fps and frame numbers. At least this is the case for all the normal styles and probably the hidden ones as well. Granted, the starts/returns/transitions animations DO seem to take different amounts of time (most notably with the red style).

 

Does this mean its not possible to slow down the styles individually? If it is at all possible still think the faster styles should be slowed down. Since they obviously have less animation frames than the slower style, may they should get less fps. They should hopefully rebound cleaner this way unless its the fault of the animations.

 

Anyways, I have a few more hopefully logical suggestions after playing with the styles for a while:

 

1. I think the freeze time caused by a successful parry or hit should be longer depending on the style that they where hit or parried with. Tavion and blue styles should cause a short freeze while red should cause the longest freeze. I've notice when I fought with red that if I parry someone, freeze ends long before I can finish my swing.

 

2. Make the block animation after doing a successful parry terminate quicker than it does. This often prevents a person who has done a parry from attacking the other person before the other person recovers from the parry they just recieved. I think this is also one of the reason way attacking is much more effective than parrying so far.

 

3. Make the faster styles do less DP damage. When I fight a Blue style tabbot and miss with a parry or get frozen from a hit, they swing spam and tear me to shreads very quickly. If they are going to stay that speed, they need some serious disadvantages. Red should still do the most damage, but not by much. If possible, staff should be weak but have more DP so it becomes a great weapon for fighting 2 or more people.

For example, all single handed styles should have a penalty to their disarment chances since the sabers aren't being held by two hands. This is one way I think we can help balance the dual/double sabers vs the single saber styles.

 

Good Idea, but I wouldn't penalize desann's style too much, its already pretty slow compared to the others. I would also make the dual sabers and staff move a bit slower because its alot harder to tell what direction they are swinging.

 

Soooooooo, do ya think you'll have the next build by next friday again! lol. That was really fast last time!

[razorace]

Might be a good idea, but I suppose it could stay the same as long as the parried person loses more DP from that parry than you do from doing the parry.

Well, I kind of like the idea of having DP only go down if you're getting attacked. That way we're heavily encouraging people to be offensive and not turtle their way to victory.

 

Does this mean its not possible to slow down the styles individually? If it is at all possible still think the faster styles should be slowed down. Since they obviously have less animation frames than the slower style, may they should get less fps. They should hopefully rebound cleaner this way unless its the fault of the animations.

No, I have complete control over the animations, if we need to tweak them, I can and have done so.

 

1. I think the freeze time caused by a successful parry or hit should be longer depending on the style that they where hit or parried with. Tavion and blue styles should cause a short freeze while red should cause the longest freeze. I've notice when I fought with red that if I parry someone, freeze ends long before I can finish my swing.

An interesting idea, we might have to try that. But is it logical to have the freeze times differ based on the defender's style or the attacker's style?

 

As for the slow bounce times, I agree that they don't seem long enough in some cases, I think I'll make it a little be longer in the next release.

 

2. Make the block animation after doing a successful parry terminate quicker than it does. This often prevents a person who has done a parry from attacking the other person before the other person recovers from the parry they just recieved. I think this is also one of the reason way attacking is much more effective than parrying so far.

Yeah, I've been struggling with the parry visual effect. I tried using the projective block animations but they're just too fast to be seen in saber combat most of the time. I'll see what I can do about speeding up the parry animations or maybe just use the knockaway animations whenever a parry is performed.

 

3. Make the faster styles do less DP damage. When I fight a Blue style tabbot and miss with a parry or get frozen from a hit, they swing spam and tear me to shreads very quickly. If they are going to stay that speed, they need some serious disadvantages. Red should still do the most damage, but not by much. If possible, staff should be weak but have more DP so it becomes a great weapon for fighting 2 or more people.

I'm liking these ideas. But, again, should the DP costs be based on the defender's style or the attacker's style? Maybe both?

 

Soooooooo, do ya think you'll have the next build by next friday again! lol. That was really fast last time!

Maybe, as my school workload goes up, I'll have less and less time for the mod.

[JRHockney*]

Well, I kind of like the idea of having DP only go down if you're getting attacked. That way we're heavily encouraging people to be offensive and not turtle their way to victory.

 

Good point. Plus, I like the greater ephesis on attacking in order to win a fight. As long as being defensive isn't too dangerous or less useful.

 

An interesting idea, we might have to try that. But is it logical to have the freeze times differ based on the defender's style or the attacker's style?

 

I've been debating this along time in my head and I think it should be based on the attackers style because they are the ones who need to follow up with a swing. Two Red style fighters would never get any hits on eachother after parrying if their freeze time was too short.

 

As for the slow bounce times, I agree that they don't seem long enough in some cases, I think I'll make it a little be longer in the next release.

 

I'd be careful about this one. I would say that it might be better to work on making the parry animations shorter first so the parrying guy can swing faster. The knockaway animation might work better for this as you suggested. However, if you can't get this done or the attack style based slow bounces (the last idea) done before you make the next release, then its probably a good idea.

 

I'm liking these ideas. But, again, should the DP costs be based on the defender's style or the attacker's style? Maybe both?

 

Again I had to think about this very hard. I would say both, in a way. DP damage should also be based on the attackers style here, however, different styles will have different DP gains. Staff should have the fastest DP gain and do light to moderate DP damage, thus, making it the best defensive weapon for fighting two or more people. Dual sabers would do maybe Moderate to high DP damage but have a slowest DP gain. Red would have a pretty fast DP gain and do the most DP damage while tavion style would have a fairly slow DP gain and do the least DP damage. Mind you, these differences would have to be fairly small in order to keep it balanced.

 

I just had an interesting idea. Since the focus in more on attack now, I think there should be some strategy when both people are swinging. I was thinking about how in MB2, the point of the HPing system is to hit the opponent anywhere his saber isn't even when they are blocking or swing blocking. This gives me an idea:

 

When both saberists are swinging, whoever hits their opponent first anywhere their opponent's saber isn't (maybe two swing positions away or a virtual foot from the opponents saber), it will cause that opponent to lose some DP and it will make the rest of the opponents last swing do no damage or maybe even enter block. If a saberist senses that he is about to be hit first, he can try to turn so the swing hits his saber instead of him. This will give the faster styles a big advantage to make up for there short comings that I have already suggested being implemented. Is this idea even possible?

 

Maybe, as my school workload goes up, I'll have less and less time for the mod.

 

yep, we have like one more day of none-school freedom!!

 

Oh yeah, I almost forgot. Try using the saber sounds from Movie stances 2.0.

http://jediknight2.filefront.com/file/Movie_Stances_20;37063

They really make the combat sound more intense.

[JRHockney*]

I just thought of another crazy idea that your welcome to say "no way" on, because it would change alot of the dynamics of the system. This may or may not have to do with some of my previous suggestions above.

 

As I was messing arond with the tabbots tonight, I started tapping the attack button just as they were about to hit me. and it seemed to block them in a swing block fashion without losing DP if I did it right and it I was moving in a parry direction it also seemed to parry them. An idea came out of this.

 

My crazy idea it this: Get rid of auto block and make the fakestarting (or beginning swing) animations into what will be more of an active block. As long as the fakestarting animation has started and is still going even through the drawback animation after you let go of the attack button, your character with block the swing, lose DP, and, and do the proper block animation. You can still parry by pressing the right direction, but you have to have tap attack in order to parry block. An actual attack comes by holding down the attack button long enough to pass a certain point in the beginning swing animation and DP damage still only comes by attacking. If you do not at least tap the attack button an start up your swinging animation for an attackers swing, you will not block the swing and your Dodge will activate. A collision of to attacking sabers that have passed the point of where it is a block or fake still just collide with no DP loss (unless maybe one of them hits the opponent first where his saber isnt and my idea in the previous post takes place).

 

I think this might be good for two reasons:

 

1. It would make the system a little bit more realistic in terms of active blocking (which cant be spammed because it costs too much).

 

2. It would make the transition to a block animation look smoother because character has already started to move his arms into something.

 

Crazy but maybe logical, huh?

[razorace]

When both saberists are swinging, whoever hits their opponent first anywhere their opponent's saber isn't (maybe two swing positions away or a virtual foot from the opponents saber), it will cause that opponent to lose some DP and it will make the rest of the opponents last swing do no damage or maybe even enter block. If a saberist senses that he is about to be hit first, he can try to turn so the swing hits his saber instead of him. This will give the faster styles a big advantage to make up for there short comings that I have already suggested being implemented. Is this idea even possible?

This is already the case with the current system, however, the first player to "get hit" does have to automatically enter into a block move.

 

As for your second suggestion, I REALLY don't think that button-based blocking can practically work at these attack speeds. I've already tried several different button-based blocking systems and it's simply too fast for the average player to be able to handle. I'm sure there's a few godlike players some where out there how could manual blocking like that, but I don't think that's something that the average player can enjoy.

 

That being said, I can see it making sense to have the attack fakes causing parry-like results in attack-on-attack situations. I could set it up that way, but I don't think it will be used very often. Right now the faking system isn't used very often. It's tricky to use even for myself.

 

However, your idea of using the start animations as blocks is rather interesting. I'll have to think about it, but using them might give the system a bit more visual heft. Good idea. I'll get back to you on that.

[JRHockney*]

This is already the case with the current system, however, the first player to "get hit" does have to automatically enter into a block move.

 

Cool, I was wondering why one of us (me and a tabbot or another player) seems to win in a swing fight.

 

As for your second suggestion, I REALLY don't think that button-based blocking can practically work at these attack speeds. I've already tried several different button-based blocking systems and it's simply too fast for the average player to be able to handle. I'm sure there's a few godlike players some where out there how could manual blocking like that, but I don't think that's something that the average player can enjoy.

 

Yeah, I figured that was a stretch. LOL

 

That being said, I can see it making sense to have the attack fakes causing parry-like results in attack-on-attack situations. I could set it up that way, but I don't think it will be used very often. Right now the faking system isn't used very often. It's tricky to use even for myself.

 

Maybe if the dfender chooses the perfect angle in a fake to meeting the incoming attack, it will do a shorter parry and because its a fake, the defender can counter attack quicker. That might help its usage.

 

However, your idea of using the start animations as blocks is rather interesting. I'll have to think about it, but using them might give the system a bit more visual heft. Good idea. I'll get back to you on that.

 

Yeah, totally. I suppose the animation could even end with a standard block animation.

 

 

ON a side note, I just made my first "Hello, World!" program with Java and a few others! LOL

[JRHockney*]

I just had another idea. I've already tried to sell a similiar idea to this to the MB site, but it may actually be more practical with this system.

 

I think that turning moves in all styles should do more DP damage and even force a slow draw back. The trick with this is that doing a turning move will cost more FP, be slower and will cause a big DP loss and slow drawback freeze to the attacker if the attacker gets hit in the back while he's doing it. I think it would add some depth to the attack on attack portion of the fighting and also make saberists avoid doing turning attacks unless appropriate and thus making saber on saber combat based less on random swings (noobs will get slaughtered!!! WAAAAHAHAHAA!). The faster styles will only get a slightly increased DP attack bonus (if any) and red style will cause huge DP loss and the longest slow draw back or maybe even a stun. Some saber flipping animations might be cool to use with these as well.

[razorace]

mmm, are you referring to the actual spin move or the attack that immediately follows said move?

[JRHockney*]

mmm, are you referring to the actual spin move or the attack that immediately follows said move?

 

I'm refering to the spin swing that follows a normal swing usually in a combo when swung in a similiar direction to the last swing (unless done when landing from a jump when it sometimes happens). Along with the benefits and risks I listed above, this spin move should also be able to get parried itself too if the defender does it right.

 

Its primary function will be to strategically break through a series of volleying attack on attack swings while causing some DP damage or give the defender an opening when the attacker tries the spin. It will make the attack on attack saber combat more disciplined because both saberists will have to avoid spinning until planned. Since its unrealistic to turn your back in a sword fight in the first place, combo spinning should be risky but stronger from the momentum. I think adding a feature like this would really increase the depth of this system and make it even more unique.

 

I suppose you could even assign a manual button to start up these spin swings without comboing, but I kind of like the discipline of avoiding spin moves. Then again, this comboing power spin idea might limit the types of chain combo directions that can take place without risk if there is no manual button for it, but I don't see that as being too much of a sacrifice.

[razorace]

Well, I just looked into it and it looks like using the swing start or swing return animations just doesn't look right for parrying or blocking. As such, I'm thinking it might be time to dust off the old keshire block animations and reimpliment them. That way we'll have a two-tiered saber combat animation library, one set for attacks and one for blocks. Hopefully with my better knowledge of the saber animation system I'll be able to impliment them in a way that will look good (which was a problem previously).

 

I think the main problem last time was that I didn't link the automatic movement cycling into the new animations. As such, the animations would look good until it was time to autoreturn to the ready position and then it would crap out and just jump back.

[JRHockney*]

LOL! You post the second after I responded to that last question!

 

And, great! I'd love to see Keshire's blocks in action. I hope it works out.

[JRHockney*]

Your probably knee deep in studying or your classes at the moment, but I thought I would point out a few bugs in the standard parry system in my last "beta testing" period.

 

I noticed that pushing up (w) or both diagnal up directions never seems to parry an attack even when they are swinging low. and pressing just the side buttons (a and d) rarely seems to work for side attacks.

 

The amazing thing is that I can parry any attack direction at just almost all the time by pressing down and most of the time by pressing both diagnal side/down directions! I've actually given up the side and up buttons all together for parrying at the moment.

 

Is this intended or related to fault hit detection maybe? If its neither, you might want to check your code again in this area when you get a chance because if it is just hitting the down key, that's probably too easy.

 

Btw, what do you think of my stronger yet more valnurable combo spin swing idea?

[razorace]

Well, it's possible that the hitLoc directional code isn't broad enough. I think I borrowed that code from other part of basejka so it's entirely possible that that's the case. I'll look into it.

 

I suppose we can try the spin attack combo idea but I'm not sure it will do much. Remember that spins slow down the player movement quite a bit so it makes them fairly hard to land.

 

Sorry if I seem wary to make more DP/FP cost altering moves, it's just that coming up with all the nessicary tables for mishap propabilities is tuff.

[JRHockney*]

I suppose we can try the spin attack combo idea but I'm not sure it will do much. Remember that spins slow down the player movement quite a bit so it makes them fairly hard to land.

 

I think its the slow movement that makes more of a balanced move because the defender has time to see it and attack it before it becomes a full swing, but he has to be paying attention otherwise he'll attack too late and get parried. Also, it will help determine who is a better saberist with this system because a one of them will either do these spin moves at inappropiate times or accidently do them and pay for it. Just like in real life sword combat, turning your back is usually a bad idea unless you know what youre doing.

 

Sorry if I seem wary to make more DP/FP cost altering moves, it's just that coming up with all the nessicary tables for mishap propabilities is tuff.

 

Hey no problem man. While I think the above idea is a good one, I'd say that it is not neccessarily a priority for the next build if it's going to be realised soon (which might be a good idea while youre work load isnt too insane and you have time to fix the existing bugs. I like to be able to market a really solid version of this saber system to the MB site and get people excited).

 

In my opinion, the biggest priorities from most to least important should be:

 

1. Fix the early disarm bug.

 

2. Figure out whats wrong with the directional parrying and why only back (s) seems to work (the problem I recently mentioned). That is, you you notice the same problem. Doing the new animations for the blocks might go with this too.

 

3. Making the saber styles different based on my previous suggestions. That is, if you still like them or haven't thought of a more balanced way of doing it.

 

4. Lastly and lowest priority, the stonger combo spin idea or maybe something similiar thats more powerful, risky, and breaks through attacks.

 

In other words, solidity of the saber system should always be the highest priority in my opinion.

 

For the next build, I would suggest that you, me or someone who knows the saber system well makes a manual for it that has all the features listed and the reader won't have to figure out what has been changed and what hasn't by reading about all the previous versions. I'd be happy to do it too if you want or you don't have time for it.

 

Most importantly, what ever you do, don't tire yourself out too much for the sake of this mod. Life always comes first, even when people like me are always throwing ideas at you! LOL. I'm sure you know this lesson well already given how long you've done this.

[Vruki Salet]

Have you separated out those blocks and made them animation config file ready?

[razorace]

mmm, I think I have the original source files for the animations and a version of it intergrated into an earlier version of the saber system. I'll have to mess with it when I have time.

[JRHockney*]

I know I've been having alot of these lately (probably way too many to all be instituted anytime soon if at all) but I have another idea. This one, I think my very well be the coolest and most benefitial yet.

 

Remember when I suggested making an offensive and defensive style for each saber style and you thought it might overcomplicate things? Well, I just thought of a way to make the this idea work an a way too obvious to be overcomplicated (hopefully).

 

1. The Attack vs. Defense styles of each style with be based on a SITH (attack) vs JEDI (defense) model.

 

2. The Sith style will have stronger attacks and do a little more DP and much more HP damage than jedi style.

 

3. Only Jedi will have DODGE! Sith will have half the DP meter missing and only sustain lighter HP damage when their DP is gone or when their actual Dodge would otherwise activate.

 

4. Light and dark side force powers will be stronger based on whether you are using Jedi or sith style.

 

5. Jedi style would have a faster FP gain than Sith.

 

6. These two styles will have a separate toggle key with a 2 or so second delay on switching.

 

7. Make extra game options like Both JEDI/SITH (default), Jedi only (like OJP now) and Sith only.

 

Rational: Lets face it, not everyone likes the DODGE function (especially who play MB2, but I'm not one of these people) and those who don't should have an alternative. I would be more true to the fighting in the movies as well as the jedi or sith philosophy. It would make fighting two people easier because, I've found that swining is the best defense for surviving power duel and the fact that defense have faster FP gain but less attack power would make it easier to swing block while keeping it balanced. The toggle key would also allow a sith attacker to switch to jedi defense with after getting parried, but the 2 second delay would cause them to still lose some HP. It would also make it easier to regenate FP after a long fight as a Sith.

 

I know it would take a lot of time to do this, but what do you think about it?

[razorace]

Again, I think adding defense/attack modes would be over complicating the system and not really gaining us anything.

 

As for Dodge, I realize that a lot of people aren't happy with it, but it is literally the only way to make the game playable with lethal damage and still allow for extended saber battles. Removing Dodge from Sith characters would only result in people whining their heads off about "instant death" when their character has its hand sliced off when they botch a move.

 

That being said, I understand that Dodge has its flaws (like Dodging off cliffs in the older versions) but I have been working to address them (like fall detection for said cliff Dodges).

[razorace]

Oh, yeah. Also, having the force powers alter based on the attack/defense mode doesn't really make sense. You're either a dark sider or a light sider, it doesn't make logical sense to suddenly have different force skill advantages based on weither or not you're attacking.

 

So if I seem to be shooting down a lot of ideas. I'm really just trying to come up with what's best for the combat system.

[JRHockney*]

Alright, yeah I suppose this would need to be better thought out in the first place. I didn't really consider how quickly to people using attack style would kill eachother with their heavy DP/HP damaging hits, only block and no dodge. The entire idea was more to make the system more universally appealing, but youre probably right that this isn't the way to do it. Back to the drawing board.

 

I guess I'll stick to endorsing my "proirity" list in my previous post.

 

One more thing though. I remember you saying in response to one of my ideas that if person's saber hits his opponent where the opponents saber isn't first while both players swinging in attack on attack combat, the opponent will lose DP and switch his swing to block. I was wondering if its possible to make that more sensitive than it is because when I try for that, it doesn't happen that often even when I get a solid hit away from their saber.

[razorace]

Unfortunately, the Dodge issue is one that I've been struggling with since the MotF days. I don't expect a perfect alternative to just appear over night.

 

As for the attack-on-attack stuff, it really comes down to which player hits the other player's bounding box first. The first person to land an attacking swing onto the other guy's hit box forces that player into a block to defend himself. I hope that explain things a bit better.

 

But, that might change a little bit in the future. I've been musing over Keshire's block animations and how I could possibly impliment them in a way to make the blocking more realistic and better looking.

 

My current idea is to make the bounding box just be trigger for starting a block animation instead of the actual point of blocking impact. Right now, the bounding box counts as the impact point for the blade and that's the partial reason why the blocking animations seem to occur after the attacker's blade bounces. However, if I change this to make the bounding box just start the block animation, the attack swing should in theory hit the actual saber blade (assuming the block animations are good) a fraction of a second later. Please note that if I do that I'll still make the act of blocking count even if the attacker's blade technically slips past the block, which often happens with such intercate animations and player positions.