AE talk:Combat system

From OniGalore
Revision as of 02:08, 4 April 2023 by Iritscen (talk | contribs) (Iritscen moved page Talk:Combat system to AE talk:Combat system without leaving a redirect: this belongs in the AE namespace even if it's obsolete)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

CLEARED 10/27/2008

Loser, I have a quick question on something pretty basic, but I don't remember seeing it addressed before. Does pressing the 'back' button have any effect when blocking? Does it do anything differently than blocking by pressing nothing? *Can* it be made to do anything different from blocking while doing nothing? --Iritscen 00:19, 20 September 2008 (CEST)


Yes, It makes you more likely to be hit ^_^

serious stuff: when you press "back", character performs two animations: step back A, then step back B. Step back A is vulnerable for all characters, step back B again for all except Konoko, she has it "block high". So better is to do nothing.
Well, you inspired me -> I will try to set both back steps as "block high". Maybe it will be good. Thank you very much ^_^.

--Loser 06:28, 20 September 2008 (CEST)

Yeah, if you compare it to fighting games (within my very limited experience), backing up automatically becomes a block when under sttack. I had seen Konoko go into blocking status while backing up but I wasn't sure it was consistent. At the very least, it should be consistent and not matter which foot she's on.
I was also asking this because I was wondering if an animation can be set up to be used only while a character is back-pedaling and being attacked. Is that possible within the current framework of how TRAMs work? --Iritscen 14:08, 20 September 2008 (CEST)
There is NO possibility to make character play different block animation just because character is doing back steps. No parry/reversal ^_^. Once bit "BlockHigh" or "BlockLow" is set, it simply blocks according to already existing and hardcoded mechanics.
Also, I won't give block status to backpedaling, only I will try to give it to back steps. Blocking while backpedaling = cheap. But backsteps...maybe it will spice up melee. We will see.
"No parry/reversal" Hey! Stop reading my mind! It's creepy :-) But that's too bad, that we can't play other animations. Oh well.
Re "backpedaling"; sorry, I forgot that's not a common word and that you might not know what it means; backpedaling simply means "running backwards at a constant rate" (the movement resembles pedaling backwards on a bicycle; Konoko's backwards run is a beautiful example of backpedaling). --Iritscen 17:57, 20 September 2008 (CEST)


I was reading about offset 0x3C in the TRAM, where the attack statuses are set, such as BlockHigh/Low. It's not possible to take advantage of a new bit value in there, is it, to allow for a new kind of blocking status? It looked like the fourth bit is unused, if I read that right. I guess the point is that the engine would have to be hacked to make an 'if' statement based on that bit, right? I don't know how hard that would be; probably a question for Neo. --Iritscen 20:01, 26 September 2008 (CEST)

Yes, that is for Neo. Still want to make more sophisticated melee, eh? Me too, trust me (read my personal page ^_^). But I would save these ideas. We cannot do very much with engine so far. Altough Neo can, imagine that you have to "learn" AI2 this new ability as well. That means far more than just a few lines of code. --Loser 12:26, 27 September 2008 (CEST)


NOTE: (added 23rd November 2008):

I don't have enough time for consistent modding, however I am trying to keep in touch with AE stuff. I have found yet another two bugs in this version of throw TRAMs:
  • KONCOMrun_throw_bk_tgt is missing "drop weapon" flag.
  • STRCOMthrow_fw is missing 1 frame soft pause (required exactly for this animation, otherwise player can do punch forward bug).

Also, I think throws as a whole need one big revisit in terms of animation and end interpolation (TRAM, field 0x178). If there will be multiplayer, then I have to admit that my system IS unfair in terms of vulerability of throwing animations, denying advantages of semi-vulnerable throws to some characters (Konoko).

After reading posts from other members (Love_Oni, Gumby, Iritscen, EdT etc.) and after a few quick tests, this is what I mean:
  • ALL throw-related animations (thrower, thrown) should be semi-vulnerable, so we need to tweak those which cause character to end facing different way. Either modify them so they make victim turn back (Konoko's lariat case: force victim to turn 360°, not 180°) or adjust animation so it ends in very mild angle, max 45° from original facing should be OK (Elite's back throw). Goal is to make "sliding" back to original facing more acceptable (less eye-tearing).
  • About throwers:
Animations need to end sooner and fully use "end interpolation". This would make thrower more dynamic, able to launch attacks or to escape fluently from end of throw animation.
Demonstration VIDEO, KONCOMrun_throw_fw. You can see that although animation ends sooner (it is mercilessly trimmed via 0x16C in TRAM), thanks to a bit higher end interpolation it looks almost same as original, plus giving character more agility.
In conjunction with thrower being vulnerable as soon as it is possible (depends on animation) this feature would speed up gameplay. And I am not talking about mashing buttons, but about reduction of "grab-one-guy-after-another-from-crowd" and "hit-thrower-even-tough-he-looks-battle-ready-but-is-not" situations. Still, window where thrower can be hurt should be big enough to force wise throwing.
  • About throwns:
I have discovered another bug which is not usually harmful, but in case of throwns it is. If we set soft pause (0x152 TRAM) to some non-zero value, then we can simulate character lying on ground in pain (unable to do a thing for a set number of frames). Drawback is, that on narrow surfaces thrown animations with non-zero soft pause behave weird, sometimes causing victim to play "air knockdown" as if victim was in the air. Plus he usually takes no dmg then (frame of damage is not played as animation is replaced). Thanks to this we cannot set soft pauses for throwns properly.
Yet another problem is that we have two kinds of fallen animations in Oni - Konoko's (female) and Striker's (male). Count out special Zombie Shinatama's one, please ^_^. Now when some character is thrown, it plays thrown anim which ends either in female or male fallen position, depending on how Steve animated it. Nuisance is, when male is thrown but anim ends in female fallen position, character is set up for transition to female fallen position at the end of thrown anim. Then, after thrown anim ends, this male character "jerks" to his right fallen position. Looks awful.
I suggest solution for both of those above - reanimate endings of thrown animations. Extend them a bit (depends on animations of course), that would simulate soft pause (I assume that all throwns are vulnerable as soon as possible). And reanimate ending, so character ends in some medicore pose from which he can interpolate to both male and female fallen position without looking weird.
Also, in terms of damaging - I suggest to use PAR3s instead of internal Damage part for some thrown damages, mainly for those caused by smashing/tossing victim. Bone-breaking and neck snaping should still use damage part.
Point is that then we can easily create wall collision for such throws, at least I think we can. Then if character is thrown by Tanker's back throw near edge, it would not cause damage because character flew over and didn't hit hard surface. If we talk about small heights - in small height thrown animation is still played, ready to deal damage. And in case of higher height, well, gravitation does work for Tanker. Also, if he performs back throw and flings victim onto a wall, victim would be damaged by hitting the wall.
--Loser 14:49, 23 November 2008 (CET)

\NOTE

Very interesting information and ideas, Loser. I was just wincing at the jerking fallen animation bug yesterday, not for the first time or the 50th time, so I am fascinated at the simple reason for it. I never realized there were male and female fallen anims. You're saying that some animations that involve falling always end in male fallen poses, and some always end in female fallen poses, correct? Also, I only remember seeing this bug when an enemy is finally KOed, and comes to his final resting pose. Maybe normally it is not as obvious because they start to get back up right after reaching the fallen pose? --iritscen 17:11, 23 November 2008 (CET)

Yes, there are two sets of fallen animations plus one bonus.Easy recognition:
  • female fallen animations: fallen_back has right arm close to body , fallen_front has arms above head
  • male fallen animations: fallen_back has right arm away from body , fallen_front has right arm along body and left arm slightly raised above head
Next, usually each set of TRAMs is utilized for specified character, so you cannot see "jerk bug". But thrown animations are forced upon every thrown enemy. Animations are rigid, so in their current state you can see from time to time that they were meant to end in male or female fallen animation (usually when it is performed by wrong-fallen anims character) ^_^. Normally, you ignore this because you are hyped in action (yes, it happens each time, not only after KO), but as time passes and you are not so tense in fight ( after 8 or what years of playing... guess ^_^.) you can see this bug quite clearly. So clearly it starts to annoy you.
Also, my apologies, I forgot to mention you in my list. Now you are in. --Loser 17:47, 23 November 2008 (CET)

I don't have any other specific comments just yet, but I like what you are proposing for allowing characters to move sooner after throws. Definitely a good idea. --iritscen 17:11, 23 November 2008 (CET)

Retrieved from "https://wiki.oni2.net/w/index.php?title=AE_talk:Combat_system&oldid=39485"