YesNoOk
avatar

The greatest hits of character feedback (Read 196152 times)

Started by PotS, May 22, 2009, 11:49:10 pm
Share this topic:
The greatest hits of character feedback
#1  May 22, 2009, 11:49:10 pm
  • ******
    • network.mugenguild.com/pots/
So I noticed that I (and many people) keep repeating myself on many points when testing different characters to give feedback to their authors, and it occurred to me that compiling some list of all or at least many of those common problems and solutions could turn out helpful to people.  Since my Mugen time is kinda (read: totally) being wasted lately staring at forums, I decided to put it to a better use and actually make that happen.


Some notes:
- In the second post I'll cover said common issues that should be fixed in every character, and in the third things that, while I don't point them out when testing characters because of being optional, can still make a character work better.

- This is not the bible of character issues, I won't mention how to fix a palette for instance, it's mostly aimed at people who are already comfortable with coding characters.  So if you're at an intermediate level of character coding you probably really ought to put one of those boredom times to a "good" use and give this a read.

- I'm not going to explain every code in great detail and you're not required to fully understand them for them to work, but the more you can understand the better.

- All the variables used here are just the values I used in the source of the copy/paste, you can change them to whatever variables you prefer.
Use anything you want from my works.  If you need to contact me use email, not private messages.
Re: The greatest hits of character feedback
#2  May 22, 2009, 11:50:00 pm
  • ******
    • network.mugenguild.com/pots/

COMMON MISTAKES


Air physics

a) Outside of MvC-type characters, each aerial special and super attacks should use their own landing state instead of sending the character to State 52.  The reason for this is that each of those attacks has a different recovery time, i.e. a time during which your character should be vulnerable while landing, and State 52 would just make them all recover too soon and have always the same animation etc

b) Special and super attacks (as well as some others) that take the character off the ground should never use physics=A, but physics=N instead, as physics=A automatically sends the character to State 52 when landing (see above).  You can then apply the gravity manually with veladd, keeping in mind that each of those attacks usually needs specific physics (read: you don't have to use the same acceleration for every attack)

c) The trigger used to change the character from an aerial state to a landing state (e.g. landing from a Shoryuken) should not simply be the commonly used "pos y>=0" as that will allow the character to go below the ground before actually landing.  You should use "pos y > -vel y" instead, like this:


[State 1000, Land]
type= changestate
trigger1= vel y > 0
trigger1= pos y > -vel y
value= 1010


d) Make sure that the character's statetype is always A (aerial) when it's not on the ground, as being hit out of the air without the proper statetype specified will then allow the character to walk on air.  I like to use this simple code in State -3 while making a character to make sure I don't miss that issue:


[State -3, Wrong StateType]
type= superpause
trigger1= pos y!=0 && statetype!=A && statetype!=L
time= 99999
ignorehitpause= 1


It will freeze the game if you forgot to look out for that issue, at which point you can just check the state the character is in and fix it.  Don't forget to remove or disable this when you publically release the character.




Attack direction

The start of every attack should make the character automatically face the direction in which the opponent is, which can be accomplished by simply adding the "facep2 = 1" parameter in each corresponding Statedef.  Notice that I said the start of each attack, that means that only the first State of an attack or chain of attacks (example: Fei Long's Rekka Ken) should have that line.




"Character doesn't turn after jumping over P2" bug

When you start editing the jump timings of Kung Fu Man (or whatever character) you may notice that if you then jump over the opponent without letting go of the jump direction (up-forward), your character will be facing away from the opponent instead of towards him.  Fixing this only takes one line of code, so add the "facep2 = 1" parameter to State 40.
Note that State 40 is a common state, so to implement this change you'll need to copy it from common1.cns into your character's coding files before editing.




Collision boxes

These few basic tips actually make Clsn2 easier to make while making characters more functional:
  • Do not use too many Clsn2 boxes in each frame, 2 (old SNK standard) or 3 (old Capcom standard) will pretty much always get the job done. For Clsn1, one is enough
  • Basic animations like standing, crouching or walking should use the same boxes for all frames
  • The Clsn2 on jumping animations shouldn't come all the way down to the feet, characters aren't supposed to be sweeped during jumps
  • Standing get hit (anims 5000-5017), turning (5) and guarding (120, 130, 140, 150) animations should use the same Clsn as the standing animation (anim 0)
  • Likewise, crouching get hit (anims 5020-5027), turning (6) and guarding (121, 131, 141, 151) animations should use the same Clsn as the crouching animation (anim 11)
  • Walking animations should use Clsn2 similar to anim 0 as well
  • Make sure the air get hit Clsn2 (anims from 5030 to 5071) aren't too skimpy, no one likes missing juggles because of bad Clsn on the opponent

All these pointers are followed in my latest characters if you want a reference, and you can always check KOD's KOF Clsn tutorial.




Combos

It's nice when the coder puts some thought into which moves should allow combos and whatnot, I remember wanting to incluse some characters in combo videos only to then get sad in the pants because they had nothing special, or nothing at all.
That does not mean that everything should chain six times, just... don't forget to set cancels from normal attacks, and it's nice when a juggle or two can be done.

Also note that when a normal attack is cancellable, that means it can be cancelled into any special and super attack.




Constants - head and waist positions

So many people forget to set these it's not even funny.  They are used to let the opponent know where the character's head and waist are, so they are essential to making your character react properly to being thrown, for instance.  Make sure you set them properly in every character.

Some people like to set them according to sprite 5000,0, others according to the stance, and I can see the advantages of each of those options, so it's up to you.  Either way, you get this position like you would for say an explod.  You open the SFF and AIR with an adequate program (like Fighter Factory) and make an anim with the sprite you want to use to get the position.  Then click and drag the anim axis (crosshair) until it's on the character's head and check the X and Y position, that's your head.pos.  Repeat the process for the waist (mid) position to get the mid.pos values.




Damage levels

Just a general pointer here, since so much could be said for each individual character's damages, but:

a) The easier a move is to land, the less damage it should do
b) Likewise, the easier a move is to combo into or out of, the less damage it should do




Damage dampening

It is important that a character starts causing less damage as his combos get longer, for the sake of needing to catch the opponent more than once to win.  There are many ways to do this, but for the purpose of this thread I find it appropriate to use a simple effective code as an example:


[State -2, Damage Dampener]; Scaling in action
type= attackmulset
trigger1= numenemy
value= ifelse(enemynear, gethitvar(hitcount) < 3, 24, ifelse(enemynear, gethitvar(hitcount) >= 24, 2, 26 - enemynear, gethitvar(hitcount))) / 24.0
ignorehitpause= 1

[State -2, Damage Dampener]; Full damage
type= attackmulset
trigger1= numenemy
trigger1= enemynear,movetype!=H || (enemynear,stateno=[120,155])
value= 1.0
ignorehitpause= 1


Notice how the attack multiplier depends on the number of hits P2 has received.  Or this version based on Marvel vs Capcom's system (if I didn't mess up, was made a long time ago) which at this point is reposted in some places but is worth noting:


[State -2, Damage Dampener]; Scaling in action
type= attackmulset
trigger1= numenemy
value= ifelse(enemynear, gethitvar(hitcount) = 0, 1, ifelse(enemynear, gethitvar(hitcount) = 1, 0.9, 0.8**enemynear, gethitvar(hitcount)))
ignorehitpause= 1

[State -2, Damage Dampener]; Full damage
type= attackmulset
trigger1= numenemy
trigger1= enemynear,movetype!=H || (enemynear,stateno=[120,155])
value= 1.0
ignorehitpause= 1





Debug flood

If you see any debug messages while making the character be sure to fix them, usually it's only a matter of adding numhelper(ID), numenemy etc triggers where needed.  Leaving a character with debug flood is an immediate testament of how much thought was put into it.




Hitdef

Before mentioning specific issues, I should say that the more Hitdef parameters you specify, the easier it is to make every hit behave properly and consequently make the character solid.  Ideally you'd specify all parameters related to the time P2 is stunned (hittime) and the distance he travels when hit (velocities, yaccel).




Hitdef - ground velocities

Very, very often, mostly in MvC characters, people will use really low hit velocities in attacks to favour combos.  This technique was coined "Brazillian chains" at some point (desculpem-me pessoal, haha).  But you know what?  All the combo games this tries to emulate do not use such low velocities.  Low velocities only accomplish adding potential infinites (walking jabs) and a weak feeling of impact on each hit, all that just so that the character can do a boring six (or eighteen) move chain instead of "just" around three or four moves.

I'm not going to make a list of velocities for each game here... the point is, just take a quick look at the source game and see how far each attack type (light, medium, hard) hits back the opponent, then recreate that distance in Mugen (approximately or accurately, whatever suits you).




Hitdef - hit times

Very similar to the above, but related to how long the opponent is stun by a hit.  Often you'll see Mugen characters stunning the opponent for too long with weak attacks, or not enough with hard attacks.
The answer here is the same, take a look at the source game as counting ticks is actually much easier than making them up yourself until they work right.  If you want a quick fix on some values, you can use like 10 for weak attacks, 14 for medium and 18 for hard.

Would do everyone good to pay attention to air.hittime as well.  And, while I'm at it, the pausetime too, for example in chain characters having too short pauses will make the chains feel chaotic.




Infinites

There's so many variables to consider here that there's no way to have absolute solutions, but there are some pointers one can follow:

a) The rule of thumb.  Make sure that a combo always leaves the character at less of a positional/frame advantage with each repetition, the most basic form of which being pushing the opponent further away every time you do it.  This means for instance that if you jab the opponent and keep walking forward then jab him again, the distance at which the opponent was by the time you hit him with the second jab must be longer than when you did the first one.  Actually the details on this rule could go on forever, but hopefully the basic idea is here already.

b)  Juggling.  If you're using limited juggle points make sure that every attack (eventually) subtracts them.  If you're using unlimited juggling then pay extra attention to a) when hitting the opponent in the air.




Invulnerability
A move being invulnerable to certain attacks does not always mean you should use a NotHitBy, it is often a matter of which areas of the character have or not Clsn2.
Consider Zangief's Double Lariat for instance, it doesn't avoid mid-level attacks and projectiles because of a NotHitBy but simply because he has no Clsn2 on his midsection and thighs.  Keep that in mind when you want a move to have an edge but not full-on invincibility.




Jumping normal attack properties

There's not much to say about this one, but jumping normal attacks should all cause light successful hits on the opponent, but guarded hits according to their strength (light, medium, hard).  That means that all jumping attacks should have the same hit properites of a ground weak attack, and guard properties corresponding to a ground attack of the same strength.
One of the reasons behind this, in most games, is that if a jumping hard punch caused the same hit as a standing hard punch, then the opponent would be knocked too far away for jump-in combos to be effective.




Jumping physics

Bad jumping velocities alone can throw off an entire character's aerial gameplay, so if you're not going to take the physics directly from the source game (or are making an original character) at least make sure to adjust the jumping velocities and the "yaccel" constant until the jumps feel just right.  Kung Fu Man's default 0.45 yaccel is a bad value by common standards (some characters are supposed to be floaty like that though) and 0.5 is usually considered a better value, but either way it's the combination of jump velocities and acceleration that determine a jump's floatiness, not either of them on their own.




Landing from a jump (State 52)

State 52 is a common state, so to implement these features you'll need to copy it from common1.cns into your character's coding files.
When a character lands from a jump...
  • Both X and Y velocities should be reset to 0
  • Position Y should be, of course, set to 0 as well
  • As a general rule, should regain control immediately as it lands, i.e. Statedef 52 should specify "ctrl = 1"
  • If you want to enable "trip guard", the ability to guard a low attack (usually kicks) as soon as you land, you must add this piece of coding to the state:


[State 52, Guard]
type= changestate
trigger1= inguarddist
trigger1= ctrl && command="holdback"
value= 120





Rolling (KOF / CvS)

This is the kind of game-specific thing I rather not mention, but so many people consistently make this mistake that it should be worth mentioning.
Rolls are not supposed to be completely invulnerable, they should be throwable at any time and completely vulnerable near the end.  To make a character only vulnerable to throws this is what is used:


[State 710, HitBy]
type= hitby
trigger1= animelemtime(6) < 0; Depending on your animation, of course
value= SCA, AT
time= 1





Running then crouching

Games usually don't allow characters to crouch while running (or dashing), the reasons for which can be debated but it for one makes it easier for you to position yourself while preparing a crouching attack or starting a special move motion.
This is easy to implement in Mugen, all it takes is removing control from the running state.  Then, so that you can still attack while running, you use "is in the running state" as an optional condition to executing a ground move in the command file.  Here's an example:


[State -1, Standing Light Punch]
type= changestate
value= 200
triggerall= command!="holddown" && command="x"
triggerall= statetype!=A
trigger1= ctrl || (stateno=[100,101]); "Has control or is running"


See trigger1? In this example State 100 is the running state and 101 is the stopping after running state.
Note that removing control from the running state makes it impossible for the character to jump out of it, so you'll need to add this in the state:


[State 100, Jump]
type= changestate
trigger1= command="holdfwd" && command="holdup"
value= 40





SFF

a) Make sure everything is aligned properly so that the character doesn't jitter while animating.  Remember that if you use a sprite pack like those by Just No Point you can simply align the stance perfectly then copy its coordinates to every other sprite.

b) Crop the entire thing when the char is ready for it.  Cropping means removing excessive and unneeded transparent portions of a sprite, and Fighter Factory even has the option to crop everything with one click (takes a while though, if you can use sprmaker that's a lot faster).

c) This is just a trivial reminder, but always make sure that the small portrait's size is 25x25 pixels and that the large portrait's is 120x140, and that both are properly aligned.  Cybaster will thank you dearly if you pay attention to this. ;P




SND

With the possible exception of ambience SFX, Mugen characters do not need Stereo sounds as that is already handled by the engine according to where in the screen your character plays them.  Saving sounds effects in Stereo is only a waste of space.

And, similarly to the SFF, be sure to crop sounds and not save them with a lot of blank (silent) space.




Special move levels

Somehow there's this train of thought that grew in Mugen and says that the strong version of a special is the only one you'll want to use while the others should just be lesser versions of it.  Wrong!  Every level of a special move (weak, medium, strong) should be useful for its own reasons.

Take Ken's Shoryuken for instance, do you always want to use the strongest version and be open to attacks?  No, any experienced player will alternate between the different levels and only use the strongest in combos.  That is because every level has its strengths: light is the quickest (hard to punish), medium has the most invulnerability (best anti-air) and strong does the most damage (best in a combo).  The same principle should be attempted in most specials, don't make light and medium versions be only filler.




Statetype limiting in the command file

Sometimes, when people want a move to only be performable while standing, they'll use "statetype = S" as a trigger, or if only while crouching "statetype = C".  That is wrong in most cases, as for instance making Hadouken impossible to perform while crouching makes the motion harder to execute (starts by crouching, then must wait until the character stands again to press punch).

For ground special and super attacks, such triggers should be replaced with "statetype!=A" instead; and for normal attacks what decides whether a standing or crouching attack is used should not be the statetype trigger, but rather whether the player is pressing the down direction or not.  Examples:


[State -1, Hadouken]
type= changestate
value= 1000
triggerall= command="hadouken"
triggerall= statetype!=A
trigger1= ctrl || (stateno=[100,101])

[State -1, Standing Hard Kick]
type= changestate
value= 250
triggerall= command!="holddown" && command="c"
triggerall= statetype!=A
trigger1= ctrl || (stateno=[100,101])

[State -1, Crouching Hard Kick]
type= changestate
value= 450
triggerall= command="holddown" && command="c"
triggerall= statetype!=A
trigger1= ctrl || (stateno=[100,101])





Velocities

Nothing specific to say here, just that bad velocities alone can ruin a character so be sure to spend some time tweaking them until they're just right.  No one likes to see a character with floatiness, odd movement trajectories, or nigh instant full screen dashes.
Use anything you want from my works.  If you need to contact me use email, not private messages.
Last Edit: June 04, 2009, 09:43:32 am by PotS
Re: The greatest hits of character feedback
#3  May 22, 2009, 11:51:35 pm
  • ******
    • network.mugenguild.com/pots/

OPTIONAL FIXES


Corner Pushing
It is common knowledge now that Mugen's corner push (hitting a character near the corner) system is faulty, so to have proper corner gameplay it's always recommended overriding the common system with something more true to fighting games.
There have been many versions of corner push codes to somewhat go around that, but here's my own you can use (...which like every code here has been available for a long time in my chars):

1) First of all you'll have to disable the corner push in all Hitdefs, by setting each of said parameters to 0 like so:

ground.cornerpush.veloff = 0
guard.cornerpush.veloff = 0
air.cornerpush.veloff = 0
airguard.cornerpush.veloff = 0
down.cornerpush.veloff = 0

(Setting only "ground.cornerpush.veloff" to 0 is enough if you're not touching the others, since they all default to the value specified in it.)

2) Now for the actual code, add this to State -3:


[State -3, Corner Push]; Reset
type= varset
trigger1= fvar(5)
trigger1= numtarget
trigger1= (target, hitover) || (target, gethitvar(hitshaketime) > 0 && target, time <= 0)
fvar(5)= 0

[State -3, Corner Push]; Get initial velocity
type= varset
trigger1= movecontact=1 && numtarget
fvar(5)= (target, gethitvar(xvel))
ignorehitpause= 1

[State -3, Corner Push]; Apply corner push
type= posadd
triggerall= fvar(5)
triggerall= (statetype = S || statetype = C) && numtarget
triggerall= !hitpausetime && (target, gethitvar(hitshaketime) <= 0)
triggerall= (target, statetype = S || target, statetype = C) && !(target, gethitvar(yvel)) && !(target, hitfall); See note below
trigger1= target, frontedgebodydist <= abs(target, vel x)
trigger1= (target, gethitvar(xvel) * target, facing) > 0
trigger2= target, backedgebodydist <= abs(target, vel x)
trigger2= (target, gethitvar(xvel) * target, facing) < 0
x= ifelse(target, frontedgebodydist <= 0, -1, 1) * (target, facing) * fvar(5)

[State -3, Corner Push]; Apply friction to the velocity
type= varset
trigger1= numtarget
trigger1= target, gethitvar(hitshaketime) <= 0
fvar(5)= fvar(5) * 0.85


Note:  This code was designed for types of gameplay where the attacker doesn't suffer corner push if the opponent is in the air (SF, KOF, so on), if you want to change that aspect you can change the line signaled above with "triggerall= (target, statetype != L)".  There's no guarantee that that change will make it work perfectly, but it will still get the job done.

One added benefit of using a custom system like this is that you can then reset or disable corner push at any time you want by making that var 0, and you'll want to reset it for instance when a super move's superpause happens.




Fall Recovery handling for the opponent

Games like King Of Fighters and Capcom vs SNK only have fall recovery near the ground, not the aerial kind Mugen has, so allowing the opponent to use the latter can easily cause unwanted situations (such as P2 recovering from a Shoryuken and hitting you back).  Some people solve this by simply disabling fall recovery entirely for the opponent, which then of course also prevents them from doing the ground recovery type those games allow.  Here's one way to allow ground recovery but not air recovery:

1) Specify the "fall.recover" and "fall.recovertime" Hitdef parameters for every attack the character has.  Set "fall.recover" as you usually would (0 to not let P2 recover, 1 to let him), but then set "fall.recovertime" to a high value (I typically use 120) so that P2 won't actually be allowed to recover on his own but only when you allow him, and you allow him by adding this code to State -2:


[State -2, P2 Safe Fall]
type= targetstate
trigger1= numtarget=1; Just to prevent Simul mode shenanigans
trigger1= target,command="recovery"
trigger1= target,pos y>=-20 && target,vel y>0
trigger1= target,alive && target,hitfall && target,gethitvar(fall.recover)
trigger1= target,stateno=5030 || target,stateno=5035 || target,stateno=5050 || target,stateno=5071
value= 5205
ignorehitpause= 1


2) Then add this simple state to your coding files:


[Statedef 5205]
type= A
physics= N
movetype= H

[State 5205, End]; Sends character back to his own recovery states
type= selfstate
trigger1= 1
value= ifelse(pos y<-20, 5210, 5200)





Flagging the recovery frames of an attack

In fighting games every attack is divided into startup, active and recovery frames.  Startup frames are the time it takes for a move to be able to hit (Ryu's jab animation before his arm is fully extended), the active frames where it can actually hit the opponent (arm extended) and recovery frames where the character is harmless and vulnerable (retracting the arm).

Startup and active frames automatically behave properly in Mugen, but the recovery frames you'll have to manually specify them for each attack, and all it takes is setting a state to movetype=I when the attack becomes harmless.  Why do that?  Because if you don't, the opponent will guard your moves longer than he should which makes them harder and more confusing to counter; also so that counter hit systems work properly and your character doesn't receive counter hit damage while for instance falling from a Shoryuken.

Example, Ryu's standing jab enters recovery phase (can no longer hit) from the third frame, so:


[State 200, Idle]
type= statetypeset
trigger1= animelemtime(3)>=0
movetype= I





Juggle "resets"

In fighting games, resetting a juggle means hitting an opponent out of the air with a move that makes him land on his feet, for example doing a weak Akuma hurricane kick in SF3 or SF4 and then using a normal attack on the falling opponent.  Again this is something that doesn't happen in Mugen and can't be reproduced by normal means (Hitdef parameters), so to add this feature to your character you can follow this method:

1) For every attack that isn't supposed to make the opponent fall on his back, but rather land on his feet, give its Hitdefs an ID.  I'll be using ID=200 here.

2) Add this code to State -2:


[State -2, P2 Recovery]; Notice how ID 200 is being used. ID must match those Hitdefs
type= targetstate
trigger1= numtarget(200)
trigger1= (target(200), stateno=5020) && (target(200), alive) && (target(200), hitfall); Hit out of the air while alive and already falling
ID= 200
value= 5025
ignorehitpause= 1


3) And create the corresponding State 5025 (or whatever you prefer) of course:


[Statedef 5025]
type= A
physics= N
movetype= H
velset= 0, 0
facep2= 1

[State 5025, HFS]; Resets the fall parameter, so that the opponent will not fall on his back
type= hitfallset
trigger1= 1
value= 0

[State 5025, End]; Sends opponent back to his own states
type= selfstate
trigger1= 1
value= ifelse(pos y, 5020, 5000)





Juggle "resets" - invulnerability

I wasn't quite sure whether this one should be mentioned, but well since there is one alternative to implementing this that is only one line of code (times N), it should be worth it.  You can plain simply disregard this if your character allows opponents to air guard ground attacks and suffers corner push when hitting them in the air.

When you connect one of those hits that makes the opponent land on his feet, he should be invulnerable until that happens.  Just fire up any SF or KOF game, hit a jumping opponent with a light punch and then try to hit him again as he falls.
There are several ways to implement this in Mugen, but the one most suited for a summarized tutorial consists of making every Hitdef only activate if the opponent isn't in hit states that make him land on his feet.  Like so:


[State 200, Hit]
type= hitdef
trigger1= (p2stateno != [5020, 5040])
trigger1= animelem=3
...


Note: For special and super moves you may want to use just "p2stateno != 5040" instead.  If your ground attacks are set up so that the opponent can guard them in the air then "(p2stateno != [154, 155])" should be added if needed.

It is also a good idea to set air.hittime parameters to a high value so that the opponent cannot hit you back either in these situations.




P2stateno

There's this elusive Mugen bug where if a helper (or possibly player 3/4) hits you in the exact same moment you connect with a throw, your character will be hit out of it but your target will still be sent to custom states and (usually) get stuck there.  To solve this simply forget that the p2stateno Hitdef parameter exists and get used to TargetState instead.

To achieve the same effect as P2stateno in throws, you can keep using P1stateno then use TargetState when the character starts throwing.  Example:


[State 800, Hit]
type=hitdef
(...)
p1stateno= 810

[State 810, Throw]
type= targetstate
trigger1= !time && numtarget
value= 815





"Size box" variations

Ever notice that, for example, in Street Fighter if Ryu does a hurricane kick and you crouch he'll just go over you?  Ever noticed that Mugen is rarely like that?  That's because the size of a character in a fighting game, or rather its "pushing area", changes depending on whether it is standing, crouching, jumping and so on.  In Mugen it is always the same, however, so a character is always equally easy to push no matter if he's in any of those situations.
There are two ways to fix this in Mugen, one requires changing every single character in existence, while the other just goes on your character and makes it react to others as it should.  The latter is of course the one I used, and it is merely one piece of code that goes in State -3:


[State -3, Variable Height]
type= playerpush
triggerall= statetype=A && movetype!=H && numenemy
triggerall= p2bodydist x = [-(enemynear,const(size.ground.back) + enemynear,const(size.ground.front)), 0]; checks if both characters are within each other's width
trigger1= p2statetype=S
trigger1= p2dist y >= (enemynear,const(size.height) - 22)
trigger2= p2statetype=C
trigger2= p2dist y >= (enemynear,const(size.height) - 48)
trigger3= p2statetype=L
trigger3= p2dist y >= 11
value= 0
ignorehitpause= 1


This will also make jump-ins and crossups easier to execute, or basically anything related to air to ground contact.
The values used here (22, 48 and 11) aren't some universal rules you must follow but rather some I cooked up while checking some games, so, while they are fine, you're free to modify them for each character.




Target facing

In Capcom games (and others as well), every attack you land on P2 that doesn't make him fall will make him face your way, to prevent all sorts of back attack shenanigans. This can be done in Mugen by adding this piece of code to State -2:


[State -2, P2 Facing]
type= targetfacing
trigger1= movecontact=1 && numtarget=1
trigger1= !(target,hitshakeover) && !(target,hitfall) && (target,time<=1)
value= ifelse(p2dist x>=0, -1, 1)
ignorehitpause= 1





Throw limitations

Throws should not simply work anytime anywhere, there are several situations in fighting games where a character can't be thrown for the sake of fairness.  Those situations are: while starting to jump, after guarding an attack and while being hit (not in every game).
Again there are several ways to go around and do this, but I used a variable to keep track of those situations my self, like so:


[State -2, Throws Disallowed]; Resets condition every tick to check again
type=varset
trigger1= 1
var(38)= 0

[State -2, Throws Disallowed]
type=varset
trigger1= (enemynear,stateno=[150,155])
trigger2= (enemynear,movetype=H && enemynear,statetype!=A)
trigger3= (enemynear,stateno=[5020,5040]) && !(enemynear,hitfall)
trigger4= ((enemynear,stateno=0) || (enemynear,stateno=52)) && (enemynear,prevstateno=[5000,5040]) && ((enemynear,time<=0) || !(enemynear,ctrl))
trigger5= (enemynear,stateno=0) && (enemynear,prevstateno=52) && ((enemynear,time<=0) || !(enemynear,ctrl))
trigger6= (enemynear,stateno=40) && (enemynear,time>=1 || enemynear,prevstateno=0 || enemynear,prevstateno=52)
var(38)= 1


Depending on what kind of character you are making, you can change those triggers to fit the game (particularly the first three ones), what I'm using here is Capcom's typical setup (and you can guess why).

And now that you have a variable keeping track of the throw conditions, you can use that to trigger the Hitdefs of throws, example:


[State 800, Hit]
type= hitdef
trigger1= animelem=2
trigger1= var(38)=0; opponent is not in an unthrowable situation
attr= S, NT
...





"Underground" juggles

Because of one asinine aspect of Mugen's common states (common1.cns), a falling juggled character will go below the ground just before hitting it.  If you hit that character again in the precise moment it's below the ground (more common than you'd think) it'll still be below the ground which always looks funky.  See an example:



I simply cancelled Kung Fu Palm into Triple Kung Fu Palm, and the latter caught the opponent below the ground as mentioned.

You can fix this with this code in State -3:


[State -3, Prevent Undergound Juggles]
type= targetbind
trigger1= movehit=1
trigger1= numtarget=1 && numenemy
trigger1= (target,time<=1) && (target,ID=enemynear,ID); this is just to prevent Simul issues as usual
trigger1= !(target,hitshakeover) && (target, hitfall) && (target, pos y>0)
pos= ceil(p2dist x), ceil(-pos y); keeps P2 at the same horizontal distance, but resets his Y position
ignorehitpause= 1
Use anything you want from my works.  If you need to contact me use email, not private messages.
Last Edit: September 30, 2009, 11:25:19 pm by PotS
Re: The greatest hits of character feedback
#4  May 22, 2009, 11:51:51 pm
  • ******
    • network.mugenguild.com/pots/
...And that's all I could think of in a couple of writing sessions.  Consider this post a placeholder maybe.
Use anything you want from my works.  If you need to contact me use email, not private messages.

BC

Re: The greatest hits of character feedback
#5  May 23, 2009, 04:13:04 pm
  • ****
    • UK
    • www.mugenevolution.co.uk/Forum
Thanks POtS thats some great helpful information there some of which i will definatly use.


always wondered how your characters were so flawless ;) thanks for sharing.
Retired from mugen but not development
Re: The greatest hits of character feedback
#6  May 23, 2009, 08:23:36 pm
  • avatar
  • **
This thread is very helpful. Love the wrong StateType code, and the random mention of teh Ken! I'm bookmarking this thread.
Re: The greatest hits of character feedback
#7  May 24, 2009, 01:04:01 am
  • ******
  • Legendary XIII
  • I am the eye of the storm to come!
    • New Zealand
    • network.mugenguild.com/cyanide/
Quote
P2stateno

There's this elusive Mugen bug where if a helper (or possibly player 3/4) hits you in the exact same moment you connect with a throw, your character will be hit out of it but your target will still be sent to custom states and (usually) get stuck there.  To solve this simply forget that the p2stateno Hitdef parameter exists and get used to TargetState instead.

Although targetstate is far better, priority = 4,miss in the hitdef itself would also prevent that.


In M.U.G.E.N there is no magic button

They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.
Re: The greatest hits of character feedback
#8  May 24, 2009, 01:09:08 am
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
Personally, for landing triggers, Vans and I use Pos Y + Vel Y >= 0. This pretty much prevents sinking in any form.
Re: The greatest hits of character feedback
#9  May 24, 2009, 01:13:42 am
  • ******
    • network.mugenguild.com/pots/
Although targetstate is far better, priority = 4,miss in the hitdef itself would also prevent that.
How?  The problem here is that the priority is only evaluated against the throw target or something along those lines.  I see what you're trying with the Miss parameter, but I already said it happens most commonly with throws, which already always have that anyway.

Personally, for landing triggers, Vans and I use Pos Y + Vel Y >= 0. This pretty much prevents sinking in any form.
That sounds like it can make the char land one tick too soon. e.g. a char falling with Y=12 velocity lands when pos y=-12 instead of on the very next tick.
It's essentially the same though, other than the ">=" sign.  Pos Y + Vel Y > 0 <=> Pos Y > -Vel Y
Use anything you want from my works.  If you need to contact me use email, not private messages.
Last Edit: May 24, 2009, 01:27:25 am by PotS
Re: The greatest hits of character feedback
#10  May 24, 2009, 11:20:53 am
  • ****
Hmm, the underground juggles always bothered me, thanks for the code :P

No Borders, No Nations
Re: The greatest hits of character feedback
#11  May 25, 2009, 02:56:14 am
  • ***
  • Master of Vicodin
Hohoho, I'm so using it in my FFU template. 8)

Only note I can think of, just so the "Velocities" section won't look too empty, post a link for that Movement Coder tool, I use it every time I make my own moves.

Edit: Also, maybe a pointer for all those AI taking control issues could help aswell.

[size=5pt]Edit2: And head/mid pos stuff.[/size]
Last Edit: May 25, 2009, 03:00:25 am by Dr. H
Re: The greatest hits of character feedback
#12  May 25, 2009, 03:47:52 am
  • avatar
  • **
Hohoho, I'm so using it in my FFU template. 8)

Only note I can think of, just so the "Velocities" section won't look too empty, post a link for that Movement Coder tool, I use it every time I make my own moves.

Edit: Also, maybe a pointer for all those AI taking control issues could help aswell.

[size=5pt]Edit2: And head/mid pos stuff.[/size]

There's a movement coder tool?
Re: The greatest hits of character feedback
#13  May 25, 2009, 03:55:09 am
  • ******
    • network.mugenguild.com/pots/
Hohoho, I'm so using it in my FFU template. 8)

Only note I can think of, just so the "Velocities" section won't look too empty, post a link for that Movement Coder tool, I use it every time I make my own moves.
Dunno, didn't want to pass off the image that you must make everything perfectly accurate. How helpful is it when making up velocities?

Quote
Edit: Also, maybe a pointer for all those AI taking control issues could help aswell.
Hm, gets so specific to each activation method that I wouldn't know what to say other than "don't leave it like that", hehe.

Quote
Edit2: And head/mid pos stuff.
Oh, good one.  In the meantime people may just click this old link:  http://mugenguild.com/forumx/index.php?topic=45102.0
Use anything you want from my works.  If you need to contact me use email, not private messages.
Re: The greatest hits of character feedback
#14  May 25, 2009, 04:36:28 am
  • ***
  • Master of Vicodin
Quote
Dunno, didn't want to pass off the image that you must make everything perfectly accurate. How helpful is it when making up velocities?
That tool isn't really about accuraccy, it just make things more... polished, especially if you know the patterns that your favorite company uses when making similar moves. People will understand it's not a requirement, just a suggestion.

BTW someone gotta reupload it, just checked the old link and it's gone. :P

Quote
Hm, gets so specific to each activation method that I wouldn't know what to say other than "don't leave it like that", hehe.
Following topic's title filosofy, just this two should solve things 95% of times:

*Make sure that the XORs commands are identical;
*Make sure your commands are really human impossble. Bia once suggested that the only real commands that fits this description is the ones that requires all buttons to be pressed at once, screws keyboard buffer limit or something.
Re: The greatest hits of character feedback
#15  May 25, 2009, 04:53:27 am
  • ******
  • I got a PM.
Hey man,

Do you got something on your A.I. I've played with it a lot but still haven't figured out what you are doing in your var. I don't want you to go into Winanne's stuff there is all ready a tutorial. I'm talking about you implementation ai triggers and your use of var in those triggers. Thanks for the info man.
Re: The greatest hits of character feedback
#16  May 25, 2009, 05:05:48 am
  • ***
  • Master of Vicodin
Hm, you're talking to me or to POTS? Sorry, I'm not sure of what kind of info you're asking for, but I'm willing to help you if I can.
Re: The greatest hits of character feedback
#17  May 25, 2009, 05:08:26 am
  • ****
  • A frame here, a pixel there.
Nice collection of stuff here, very helpful. With regards to the playerpush thing, I'm hoping that one of these Mugen clones in development will eventually implement an AIR-based push box standard (CLSN0?) so that we could do it the way most of the commercial games do.
Re: The greatest hits of character feedback
#18  May 25, 2009, 07:28:51 pm
  • ******
  • I got a PM.
P.O.T.S I want to know his method of triggers while using the winanne Ai activation.
Re: The greatest hits of character feedback
#19  May 26, 2009, 12:20:11 am
  • ******
    • network.mugenguild.com/pots/
Oh, now that I see what you're asking and answered by PM I guess it's something that can go in there too, some basic pointers on how to not make AI's too dumb or too hard.
Use anything you want from my works.  If you need to contact me use email, not private messages.
Re: The greatest hits of character feedback
#20  May 26, 2009, 07:04:56 am
  • ******
  • Just a butcher on a mission.
    • www.justnopoint.com/lbends
If you don't add a bit of randomness, even the seemingly safest moves will be exploitable by the player.  This is a guarantee.  (Also something I have been guilty of in the past)

AI throws need to have a limiter so it won't spend an entire match trying to grab something like Onslaught.

Something I have learned recently is to have a statetypeset in every attack to set movetype=I after the hitframes are over.
This is also courteous vs. AI that relies on movetypes to know when to block.
Last Edit: May 26, 2009, 07:08:21 am by Insanius