Hello all,
I want to write up an intermediate level polishing tutorial. I know there are a million and a half common mistakes made when coding a character, so I'm hoping we can discuss some of them, and how you think they can be fixed. The purpose being to provide a framework or a well defined series of steps that a person with basic or intermediate coding skills could follow to polish up the finer details of existing characters.
I guess I'll start with something simple by saying that I notice a lot of poor alignment and timing in animations which leads to jerky movement and just a sloppy appearance in general. The steps I take to fix that are this: Go into FF, load the char, and first check out their standing animation and make sure the feet stay in the same position throughout. Then check the x and y offsets of the first sprite in the standing animation, and then go into the 'crouch', 'stand to crouch' and 'crouch to stand' animations. In all of these, I add an extra 1st and last frame of the standing sprite (at the proper) offset with a tick count of 30, and play the animation to make sure their feet hold position again. Because the feet move often, choose one foot to anchor for any given motion. Which one is usually obvious if you imagine a person performing the motion. Once I have the foot positioning solid, I check the tick counts of each frame to make sure everything is smooth and nothing is 'jerky' that isn't supposed to be. Certain frames may need to be changed or added.
When the movement, timing and alignments are good, I delete that extra frames I added. I then do the same thing for all the standing and crouching basics (using a crouch sprite to check the crouching basics of course). Then I go into the jumping anims and do the same thing, adding the standing animation in the first frame to make sure the jump comes out of the standing position ok. Then take a jumping frame and do the same thing to all of the aerial basics, but paying more attention to their waste position (center of gravity while in the air) or their head position depending on the motion. Of course this can be applied to specials, supers, hypers, throws, blocks, or whatever other animations you want. In short I usually call that re-timing and realigning a characters animations for foot position or ground anchoring. It's also a great chance to review the clsns.
I'm sure you all have a ton of other polishing techniques that could be applied to almost any character, so if we can get enough of them together I'll assemble them into a polishing manual / tutorial.
Good alignment in the sff is required from the beginning. If you have axis rips, this is easy. If they're made up it takes longer. There is no need to enter the .air file. Turn on onion skin. All standing or crouch sprites should have a foot placed in the same place as 0,0. Use natural motion if a foot needs to move during animations. You should still always return to the base sprite point.
Walking takes practice. So does jumping. Although jumping is easier if you treat the alignment as their center of gravity. Normally the small of their back should not go anywhere.
The most important thing when polishing becomes "Is this as good as i can possibly make things without help?" if the answer to that is no, you need to keep going.
A little testing goes a long way. Using a training dummy like Training by Stupa will let you see your character's frame data. This will allow you to see what links are and aren't possible and if you want them to be possible. Hitstun/blockstun combined with recovery are the basis of frame data. If hitstun/blockstun lasts too long, it needs either to be shortened or the move's recovery to be lengthened unless you want a very hitstun heavy character.
It's also a good idea to use Training to check if a move can be recovered in the air or how quickly the opponent can get up off the ground after an attack. Again, this helps balance combos and see if you want options like that in your character. It'll also help if you want to see if you coded a super correctly and if the opponent can recover out of it.
Damage output is also very important. You'll want to make sure that if your character does a lot of damage, make sure it's either very difficult to get that much damage (like from a long combo) or perhaps make your character slow and difficult to start a combo with. If your character does a lot of damage but is slow, that makes the few opportunities to start its combos all the more precious.
Something I found very useful is that when you're coding (esp. editing the common files even slightly), don't just dummy test.
Load up your character in your MUGEN and fight against something with rigorous AI. A lot of bugs I had when I edited guarding I found through this because it forces you to move differently than in dummy tests.
Quoterigorous AI
Looks like
QuoteMuteki
rigorous, not batshit insane
Batshit crazy. I forgot about that quote. Love it.
It's interesting you mention this RMH. First of all, I think your edits are fantastic. I also think its great that you're reaching out to members with this idea of yours. Which leads me to say...
... I'm getting the itch to dive into character creation. I love doing high quality portrait work, so I want that level of diligence to carry in to character development/creation. I have also been obsessing over Eternal Champions lately and would love to create content based off of that severely underrated title. With modifications and improvements, of course!!
Quote from: Erroratu on December 31, 2012, 10:49:50 PM
I think he means something more along the lines of Kamekaze's AI. His AI does combos and various set-ups.
Quote from: Saikoro on December 31, 2012, 10:59:10 PM
... I'm getting the itch to dive into character creation.
If you do create something, I call dibs on testing!
@[user id=80090]Madam CanCan[/user]: You got it my friend. Actually, you and RMH here would be the first two of about 6 people I'd automatically give testing reigns to. I'd really love to give Eternal Champions some love. Trident would be my very first character.
This isn't going to happen right away. Lots of portrait work still needs to be done. I'll figure It out. Until that point, I could study up on RMH's tutorials as well as Ryon's videos. Damn I love it here!! :sugoi:
@[user id=55085]Saikoro[/user]: You are ready to unleash the beast upon your unsuspecting creation in the indefinite future. :twisted:
this is a VERY cool idea: take it from someone who doesn't have a single clue about coding in general whatsoever and coding involved in a mugen character, it is fucking hard when "all" you have is the regular docs... now that we have nice enough people (like Ryon) who actually take the time to show and explain to you how the whole thing kind of works, having a possible tutorial would be a most excellent add-on for sure!
Probably not character polishing but more as an after-service, but I like it when my MUGEN games/chars (stages or addons I care less about) come with very good documentation; beyond the usual readme.txt file.
A good example is XCB's Genkai that comes with a compiled help file. Although outdated today, it was a very nice touch. It contained simple screenshots, commands, history/story of the characters, bugs/errors, credits, etc, like a real game manual. Text files are boring to read unless it's on GameFAQs, and generally an illustrated guide is always a welcome addition. It'll stop people asking as many questions too (some creators like to be cryptic about what the character can do).
Added bonus would be, given today's standards (in and out of the MUGEN world):
1. Website
2. Leading to a development blog
3. Commentary (lol but hey there's commentary for literally anything nowadays)
4. Social networking; attempting to address people (fans?) who ask intelligent stuff -- not really important but could be an important skill to have given today's industry. The guys at Blizzard have mastered this to its finest
Quote from: Cyanide on December 26, 2012, 09:59:06 PM
Good alignment in the sff is required from the beginning. If you have axis rips, this is easy. If they're made up it takes longer. There is no need to enter the .air file. Turn on onion skin. All standing or crouch sprites should have a foot placed in the same place as 0,0. Use natural motion if a foot needs to move during animations. You should still always return to the base sprite point.
Walking takes practice. So does jumping. Although jumping is easier if you treat the alignment as their center of gravity. Normally the small of their back should not go anywhere.
The most important thing when polishing becomes "Is this as good as i can possibly make things without help?" if the answer to that is no, you need to keep going.
Using the onion skin to get the sprite alignments right in the first place sounds great. It will likely require realigning all the animations, but if that's something they're going to do anyway, this sounds like the logical first step. Also, yeah the small of the back is a great point for aligning aerial basics, certainly will mention that. Alignment (of the y axis I assume) on their center of gravity is great too.
Quote from: Madam CanCan on December 31, 2012, 10:17:25 PM
A little testing goes a long way. Using a training dummy like Training by Stupa will let you see your character's frame data. This will allow you to see what links are and aren't possible and if you want them to be possible. Hitstun/blockstun combined with recovery are the basis of frame data. If hitstun/blockstun lasts too long, it needs either to be shortened or the move's recovery to be lengthened unless you want a very hitstun heavy character.
It's also a good idea to use Training to check if a move can be recovered in the air or how quickly the opponent can get up off the ground after an attack. Again, this helps balance combos and see if you want options like that in your character. It'll also help if you want to see if you coded a super correctly and if the opponent can recover out of it.
Excellent. I'll provide a link to the Training Dummy in the tutorial, along with a a write up of how to use the data it provides. Any more expansion on ideas of how to use the training dummy for polishing seem like they're going to be key.
Quote from: Madam CanCan on December 31, 2012, 10:17:25 PM
Damage output is also very important. You'll want to make sure that if your character does a lot of damage, make sure it's either very difficult to get that much damage (like from a long combo) or perhaps make your character slow and difficult to start a combo with. If your character does a lot of damage but is slow, that makes the few opportunities to start its combos all the more precious.
Ok, maybe we can start with some suggested base ranges for different character types/fighting styles (adjusted for the characters specifics of course)?
Here's a format suggestion, the values are totally just place holders, but maybe we could say for your typical brawler style character you'll want damage ranges in the neighborhood of:
qp [30-60]
mp [40-90]
fp [80-120]
etc..
Then include notes like:
1) If the character is very combo heavy, lean toward the lighter end of the range, otherwise the heavier.
2) If the character has a lot of projectiles or ranged moves, lean toward the lighter side, otherwise the heavier.
3) If your characters defense or life is higher than average lean accordingly toward the lighter end.
etc...
Enough basic key factors to make it useful without being redundant or overly complicated.
What do you guys think?
Quote from: Bannana on December 31, 2012, 10:35:04 PM
Something I found very useful is that when you're coding (esp. editing the common files even slightly), don't just dummy test.
Load up your character in your MUGEN and fight against something with rigorous AI. A lot of bugs I had when I edited guarding I found through this because it forces you to move differently than in dummy tests.
For sure. It might be a good idea to establish a trial list of characters to pit them against. Characters that really exploit the shit out of their coding, and put them in all sorts of weird states and whatnot. Maybe we could get it down to a handful of them that cover most or all angles?
Quote from: ⒻⓊⒸⓀⓎⒺⒶⒽ on January 03, 2013, 12:17:31 PM
Probably not character polishing but more as an after-service, but I like it when my MUGEN games/chars (stages or addons I care less about) come with very good documentation; beyond the usual readme.txt file.
A good example is XCB's Genkai that comes with a compiled help file. Although outdated today, it was a very nice touch. It contained simple screenshots, commands, history/story of the characters, bugs/errors, credits, etc, like a real game manual. Text files are boring to read unless it's on GameFAQs, and generally an illustrated guide is always a welcome addition. It'll stop people asking as many questions too (some creators like to be cryptic about what the character can do).
Added bonus would be, given today's standards (in and out of the MUGEN world):
1. Website
2. Leading to a development blog
3. Commentary (lol but hey there's commentary for literally anything nowadays)
4. Social networking; attempting to address people (fans?) who ask intelligent stuff -- not really important but could be an important skill to have given today's industry. The guys at Blizzard have mastered this to its finest
Yeah I hear that. Generating a moves list from the cmd file if there isn't one would certainly be a good step. Linking to a feedback thread (and or the creators site) in the characters files too. Strategy guides for characters can be found here and there (Madam CanCan?), so I will definitely mention seeking those out and including them, as well as where to look.
Great stuff so far guys!
Posted: January 03, 2013, 10:50:20 PMQuote from: Saikoro on December 31, 2012, 10:59:10 PM
Batshit crazy. I forgot about that quote. Love it.
It's interesting you mention this RMH. First of all, I think your edits are fantastic. I also think its great that you're reaching out to members with this idea of yours. Which leads me to say...
... I'm getting the itch to dive into character creation. I love doing high quality portrait work, so I want that level of diligence to carry in to character development/creation. I have also been obsessing over Eternal Champions lately and would love to create content based off of that severely underrated title. With modifications and improvements, of course!!
Thanks Saikoro. You certainly do have great a eye, by your portraits. I can imagine how that will carry over into your creations! I think the most helpful thing for you in my tutorials would probably be the Basics of Coding in the editing one. It explains pretty simply how the mugen engine reads code, and what it does with it. It should give you a relatively solid foundation to start building your understanding from. Hope it helps! And yeah, I'll certainly be down for testing out some of your characters! I would suggest doing at least one edit first of a simple but clean character (cvg spawn is a great example), just so you can see a how a well structured, well labeled character looks. If you start with some spaghetti monster of code like alucards batman, it might be kind of 'discouraging' to say the least. Those things are a nightmare even for experienced coders. Anyway, good luck with your inspirations, I'll be keepin an eye out ;)
Training can even check head.pos and a few others. Fool with it and it'll come in very handy. If you don't have it, MFFA has a link to it on Mediafire.
The damage suggestion format seems rather solid. You might also want to include standard damage for things like Dragon Punches and fireballs. Also damage values for maybe a super fireball or a ranbu super and different levels (1-3, for example).
Quote from: Madam CanCan on January 04, 2013, 12:42:11 AM
Training can even check head.pos and a few others. Fool with it and it'll come in very handy. If you don't have it, MFFA has a link to it on Mediafire.
Cool, yeah I just picked up a copy, thanks.
Quote from: Madam CanCan on January 04, 2013, 12:42:11 AM
The damage suggestion format seems rather solid. You might also want to include standard damage for things like Dragon Punches and fireballs. Also damage values for maybe a super fireball or a ranbu super and different levels (1-3, for example).
Definitely.
Ok, so here's a template, if anyone feels like filling this in with your suggestions, or adding to it/changing it, awesome! Just quote this and go for it. Ultimately I think this will end up in a 'Character Balancing' section of the tutorial.
Here's an initial list of character types without getting to complex: Brawler, Grappler, Technical, Projectile, Aerial, Boss
Too much to ask? Anything helps really, so if you just feel like throwing a couple ranges out there without filling out this whole thing, please do!
___________________/ BRAWLER
Character Examples:
Life: [ ]
Attack: [ ]
Defense: [ ]
Suggested Range of Damage Values:
Stand Crouch Air
QP: [ ] [ ] [ ]
MP: [ ] [ ] [ ]
SP: [ ] [ ] [ ]
QK: [ ] [ ] [ ]
MK: [ ] [ ] [ ]
SK: [ ] [ ] [ ]
Throws: [ ]
Projectiles: [ ]
Charges: [ ]
Helper Assist: [ ]
LVL 1 LVL 2 LVL 3
Projectile: [ ] [ ] [ ]
Charge: [ ] [ ] [ ]
'Combo': [ ] [ ] [ ]
Hyper: [ ]
Throws can also have varying damage based on if they can be comboed afterwards or not. For example, if a throw wall bounces, its damage should be lessened a bit since its juggles can be limited depending on position. If a throw just keeps P2 in the air right next to the character (like Gouken), it's best to not give it any damage since any hit is basically guaranteed.
If you align correctly in the sff file you do not need to align anything additionally in the .air file.
^ Oh right, all the alignments in the anims would be 0 if the sprites were aligned correctly wouldn't they.
EDIT:For animations that use the same sprite for different purposes/positions, would you suggest duplicating the sprite or using the alignment in the animation editor?
Also, you know on second thought that template might be a bit much for people, so if anyone wants to suggest well made character examples of the specific types, I can just extrapolate the damage stuff and fill it in myself. If you feel like filling it in, please do though. Ultimately a group perspective will be best, so if we can get down to hashing those values out, it should take care of a critical part of the tutorial, being the damage balancing part.
Well, you technically could write up templates for, say, Capcom VS SNK, Marvel VS Capcom, and Street Fighter III just to name a few. Each character has varying attributes, so it would be great to see those variables laid out in front of our eyes.
There's this site named "Mugen Study Files" that I've been looking at a lot lately. It does a fine job explaining things, but I have these thoughts:
How would one go about coding chaining attacks, like Jab into Strong into Fierce Punch.
How would I code a multi hit attack, like a three string fierce punch??
How would I properly code a Dragon Punch??
The coding for basics looks very straightforward, so practice through doing will certainly help. It's those three things above that interests me the most.
I've kinda wondered why no one has tried to start making a "full game" for things such as POTS style, CVS2, etc. Basically making a new KFM (Ryu?) with no regards to other characters, just built to all work with each other with standard community set vars, special anims, etc.
Posted: January 04, 2013, 03:57:10 AMQuote from: RobotMonkeyHead on January 04, 2013, 01:32:07 AM
^ Oh right, all the alignments in the anims would be 0 if the sprites were aligned correctly wouldn't they.
EDIT:For animations that use the same sprite for different purposes/positions, would you suggest duplicating the sprite or using the alignment in the animation editor?
No the axis is still different for each character. It's just that once you get the axis you simply set all sprites to that axis and they are aligned. AOKManiac/Insanius is good about supplying the axis for you with his packs in a read me. I am doing that as well starting with my new Dee rips I just released.
As for the animations. Again, if the sprites are ripped like mine, Kong, AOK, etc get them they have a lot of duplicates. Just use the duplicates in the packs as they are. They are in the correct order for the moves and FF3 will link all duplicate sprites for you later anyway.
Unless you become progressively OCD about programming like I have, in which case you will want to optimize as much as possible and delete duplicate sprites, only use even numbers, use a specific order for controllers/functions, label all similar controllers the same, order animations and sprites a certain way, and AAAAAHHHHHHHHHHHHH.
Rajaa keeping it real. I've got a lot to look forward to, don't I??
The prospect of creating becomes more appealing every day. Gotta start somewhere I suppose....
Quote from: Just No Point on January 04, 2013, 03:51:35 AM
I've kinda wondered why no one has tried to start making a "full game" for things such as POTS style, CVS2, etc. Basically making a new KFM (Ryu?) with no regards to other characters, just built to all work with each other with standard community set vars, special anims, etc.
If you do that, won't you just get a bunch of people that insist on plugging in their own chars or extracting the chars from this game elsewhere only to find it not too compatible?
At the moment for my project I am making the "game version" and a "offline version" (lack of a better name) for use outside of the game. The plan is to give the option to download the chars seperately (which will work in people's own mugen without any tweaking; the full game version has different portraits suited for the game's screenpack)
---
That MUGEN Study Files site is blocked for me at work, but I take it the tutorials are not as simple as they should be? The questions you ask, here are some none technical answers and is answered at its simplest level:
QuoteHow would one go about coding chaining attacks, like Jab into Strong into Fierce Punch.
Add a trigger in the command file that allows you to activate Fierce Punch when Jab connects. This code will go into the Fierce Punch activation area.
QuoteHow would I code a multi hit attack, like a three string fierce punch??
Lets say your character's fierce punch has 2 sprites. So this will be a 2-sprite animation. 1st sprite is character pulling arm back, ready for punch. 2nd sprite is character punching.
In the character's CNS file, code a hitdef which will define the hit.
In the animation, make a 6-sprite animation using the same 2 sprites. Add a red hit box to the character's fist on each of the character punching sprites (you'll need to do this 3 times). Add some animation time, i.e. 5 tics for each "ready punch" and 3 tics for each "punch"
Going back to the hitdef, have this hitdef activate on animation 2, 4 and 6. In the hitdef make sure to give it a long enough hit time so it will register as a multihit (or the enemy can block or get out of this multihit).
BONUS -- make another hitdef to trigger on animation 6 only which will knock back the enemy
In the command file, allow the use of this move when the character is standing (state 0)
BONUS -- add extra "triggers" to allow the use of this move if a jab or fierce punch connects
QuoteHow would I properly code a Dragon Punch??
Same as above, but this time we only have 1 hitdef and 2 sprite animation. We add an extra code that moves your character forwards and up. Change the hitdef to hurl the enemy backwards and into the air a bit. Need to get a tiny bit technical here.
[State 1050, 2]
type = PosAdd
trigger1 = AnimElem = 2
x = 15
y = 30Line 1 is just a reference to state that this is part the code.
Line 2 states what this "controller" does. In this case, posadd ... think of it as acceleration
Line 3 specifies when it should be triggered (on animation 2)
Line 4 is the speed, x being horizontal. This will push your character forwards
Line 5 is also the speed, but y being vertical. This will push your character up.
So this "pushes" your character forwards by 15 whatever up 30 whatever. I'm unsure of the proper values to use but this might be a little too high. This is where trial and error comes into play.
NOTE: This is very untidy and probably very very wrong. Someone is probably in line to assrape me for giving such advice out. I'm confident this character will "fall down to the ground" normally after it ends but I'm probably missing something, so if it floats off the screen (which it shouldn't, because we only defined it to trigger on animation 2) then we'll need to add extras to help pull it back down :P.
But at the base of it all, every move/attack created in MUGEN is just basically that, just your normal attack. We just add layers and layers of complexity on top of it to make it look like a different attack/move. Otherwise at the end of the day, if you imagine a character to be ... (RMH might have some fun with me here again :beam: ) a pizza base (no moves, standard stuff such as 3 stand, air and crouch punches and kicks, and all required animations for get hit and win and intro etc) ... then all you are essentially doing is taking these punches and kicks and adding topping on them.
Toppings can include but not limited to: graphical effects, sounds, power up/reduce, instant kill, self-damage, movement (i.e. a "blindside" attack where you will warp to your enemy's face and do a punch)
What I ultimately do not want to do is to over complex things which will inevitably demotivate/demoralise people. It's best to start off simple and wrong and then move on to good (perfect if you have OCD) and right.
Quote from: Rajaa on January 04, 2013, 04:05:31 AM
Unless you become progressively OCD about programming like I have, in which case you will want to optimize as much as possible and delete duplicate sprites, only use even numbers, use a specific order for controllers/functions, label all similar controllers the same, order animations and sprites a certain way, and AAAAAHHHHHHHHHHHHH.
That's quite hard to achieve when your spriters keep sending you new sprites, asking you to insert new frames in the middle of animations, making you change all your animelemtime triggers and SFF numbering, sending you entirely new animations without the same framecount, sending you sprites for which you don't even know if there are duplicates with other animations or not. After a while, you just say "fuck it", and you character becomes a functional clusterfuck of all sorts, but players are happy with it. ;P
Quoteand you character becomes a functional clusterfuck of all sorts, but players are happy with it. ;P
Most of it would be invisible to your average everyday punter anyway.
Think how happy you were when you were first introduced into MUGEN, probably via some shittily compiled game.
I remember I had several weeks of fun with Dragonball Z MUGEN EDITION 2 ! And it was well put together.
Quote from: ⒻⓊⒸⓀⓎⒺⒶⒽ on January 04, 2013, 01:16:16 PM
If you do that, won't you just get a bunch of people that insist on plugging in their own chars or extracting the chars from this game elsewhere only to find it not too compatible?
Yeah but those projects wouldn't be made for those people. It'd be more like MUGEN CVS2 edition, or MUGEN KOF edition. I'd like a MUGEN Darkstalkers edition myself.
Not everyone likes playing mugen as is since very rarely do any 2 characters play well with each other you get limited to a handful of characters made by a certain author or 2. For that reason I don't ever even play MUGEN. I really need to download Capcom vs the World's new version again. See what all was fixed. The full game package is all I want.
can we please post pictures or snapshots to help noobs like me?
it would help me a lot.
And why not take a char badly coded and post step by step how to update him??
Quote from: DONATELLO on January 04, 2013, 03:13:31 PM
can we please post pictures or snapshots to help noobs like me?
it would help me a lot.
And why not take a char badly coded and post step by step how to update him??
I'll need to look at MUGEN Study's stuff first to see how well that is actually done. I noticed that guy posted on the Elecbyte forums and loads of people pointed out a bunch of errors or improvements. But it was way too much for me to read and absorb for now.
If we were to take a badly coded char, this could have lots of implications:
1. It might suggest the creator sucks
2. Possible fights will break out
3. Too broken to fix
It would be better to take a base KFM with all the specials stripped out and then tutorial up on how to add them back in (maybe with alterations). That way, you learn the basis of it all, and then you can move on to tweak/modify the base stuff.
Quote from: Just No Point on January 04, 2013, 02:52:39 PM
Quote from: ⒻⓊⒸⓀⓎⒺⒶⒽ on January 04, 2013, 01:16:16 PM
If you do that, won't you just get a bunch of people that insist on plugging in their own chars or extracting the chars from this game elsewhere only to find it not too compatible?
Yeah but those projects wouldn't be made for those people. It'd be more like MUGEN CVS2 edition, or MUGEN KOF edition. I'd like a MUGEN Darkstalkers edition myself.
Not everyone likes playing mugen as is since very rarely do any 2 characters play well with each other you get limited to a handful of characters made by a certain author or 2.
Ah I see. Yeh, it'll be made for the people that want a pre-determined environment (these "editions") and to "play" that exclusively without any external plugs. I'm not sure if this is just a creator's bane that they become not interested in "playing" anymore lol
I don't think so. I still haven't actually "created" anything :P
I'm just picky about the kinds of fighters I do like to play. As I've gotten older I get pickier and pickier.
Interesting stuff. At first, it's a little overbearing to read. But once you "absorb" all of that, it actually makes sense. Thanks for your excellent insight FuckYeah. I couldn't get your name to quote.
I'm liking where all of this is going. Perhaps the tutorial can start with that stripped down KFM character and explain on how to build upon his "pizza" with specific "toppings." My interest here is building, that's for sure.
Don't forget about the main data on your character(s).
Data like this -
attack.dist = 90 ;Default attack distance (by pixel.)
proj.attack.dist = 90 ;Default attack distance for projectiles (by pixel.)
head.pos = 0, -114 ;Approximate position of head (by pixel.)
mid.pos = 0, -80 ;Approximate position of midsection (by pixel.)
-are important. Some creators (like me) do use these numbers in their characters. Mainly these numbers are important for AI coding, but these numbers can be used if you're using a projectile or helper that homes based on their mid.pos or head.pos (for headshots).
Also, if you're going to have testers for your character, have testers with experience in that fighting game-style. Unless if it's a completely custom game-style, of course. It's not necessary, but it does help.
And for positioning characters, onion skinning does help; but if the character is taking big steps when attacking and you want the character's sprite to stay in the middle of the X axis, use the PosAdd state controller. Take the amount of pixels from the leg it started, move it to the desired axis (mainly put the axis in between the legs of the character) and use the difference of that number (starting X - ending X) in the value of the PosAdd state controller.
[State PosA, 1]
type = PosAdd
trigger1 = animelemtime(14) = 0
x = floor(40 * const(size.xscale))
The * const(size.xscale) helps if you're scaling characters.
And.. ..I think I just confused some people.
JNP: I did the whole "Do what the fuck i like" in SBME. They had 400 life. I made up my own animation for the spinning about your axis. Crouch was disabled etc etc. It still had SOME regular mugen stuff in it, but mostly it was me making it up.
After release people put their own stuff in and complained that the sonic stuff was too weak or took it out, complained that it vanished when it crouched AND that it was too weak.
Morons.
Ok so I whipped up a quick outline for the tutorial. Not near writing it yet, just figured it would be better to have early on in the process so we can make adjustments to it as we want. As we come up with new material, I can just add a placeholder in here for it. I realize there are a lot of sub sub sub...points to add still and again this thing is not remotely concrete, and totally open to any input suggestions, section or total revamps whatevs etc.
1 - Introduction
1.1 - Scope of Tutorial
1.2 - Requirements (FF3 & Training Dummy)
2 - Alignments
2.1 - Aligning Sprites
2.1.1 - Onion Skin
2.1.2 - Y Axis Centering
2.1.3 - Holding and returning foot position
2.1.3.1 - PosAdd
2.1.3 - Lower Back hold position for aerials
2.2 - Aligning Animations
2.2.1 - Mention of clsns while aligning anims
3 - Clsns
3.1 - Simplicity
3.2 - Accounting for Motion
3.3 - Infinite Priority
4 - Damage Exchange
4.1 - Training Dummy
4.1.1 - Quick how to / overview
4.2 - Life, Attack, Defense
4.3 - Damage Value Suggestions
4.3.1 - Character Types (Grappler, Aerial etc...)
4.4 - Hitstun
4.4.1 - Frame Advantage
5 - Constants
5.1 - Data
5.2 - Size
5.3 - Velocity
5.4 - Movement
6 - Finishing Touches
6.1 - Play testing
6.1.1 - List of characters to play test against (in game)
@[user id=61380]RobotMonkeyHead[/user]: You're piquing my interest here. Please keep doing what you're doing; you have someone waiting to get started on the right foot. :sugoi:
Now that I think about it, how about an absolute basic section for simple coding of movements like walking back/forward, jumping, etc and a basic attack section. That way you can comment on how and why these codes are in play. Then subsequent chapters can elaborate on specialties like ex moves and whatnot, all built from this foundation.
Like adding toppings to a pizza. Goddamnit, that stuck with me.
You don't code walking or jumping. As this is a beginner tutorial i imagine that will sort itself out.
RMH: Sorry if this derails it slightly but it seems it's branching here into
1. Your tutorial, seemingly for people that know what they're doing already and would like some refined documentation around it
2. The completely "new to programming"
I'm just gonna continue into what Cyanide, JNP and Saikoro are talking about.
Quote from: Saikoro on January 04, 2013, 08:31:06 PM
Interesting stuff. At first, it's a little overbearing to read. But once you "absorb" all of that, it actually makes sense. Thanks for your excellent insight FuckYeah. I couldn't get your name to quote.
I'm liking where all of this is going. Perhaps the tutorial can start with that stripped down KFM character and explain on how to build upon his "pizza" with specific "toppings." My interest here is building, that's for sure.
Pleasure, but I'm still unsure if it actually makes that much sense. I'll try to re-explain briefly:
Each function/move/feature in a character is essentially the pizza base :P
From your usual kick, punch, taunt, get hit, get up... but different pizza bases depending on category. However, we're creating something here that essentially, as a whole, is just adding more attacks. To start off with, creating a character by replacing all of KFM's sprites with your own, and then recreating the attacks, is just essentially what you're doing (before thinking about character specific data) doing to create a char. Everything else can be changed/improved from there once the basics of adding your own "attack" becomes normal to you. Because KFM (another base) already contains the usual such as walking, jumping, crouching, getting hit, getting up, win pose, time out pose etc you don't need to think about such things. Cyanide said, you don't need to code walking, jumping, because it's all laid out for you by KFM.
Thinking purely on attacks:
All attacks (lets not think about anything complex here, some characters will say, for example, have a helper that does the attack for them) will have at least 1 hitdef that defines the attack(s), the hitdef is the pizza base here. And then, as mentioned:
Quote
Toppings can include but not limited to: graphical effects, sounds, power up/reduce, instant kill, self-damage, movement (i.e. a "blindside" attack where you will warp to your enemy's face and do a punch)
So this leaves 2 more things you have to "link" together (And is how the AIR (animation), CMD (command) and the CNS (programming) files work together). It can be summed up as:
An attack (CNS) has a reference to the animation (AIR) linked by a unique ID. The command (CMD) to pull off this attack is defined in the CMD file, which has an unique ID linking to the CMS. The unique IDs between CNS<->AIR and CMD<->CNS does not have to be the same, but can help with keeping things tidy.
CMD relies on what you define to activate it in the CNS which relies on the AIR to display it
Quote from: Just No Point on January 04, 2013, 03:51:35 AM
No the axis is still different for each character. It's just that once you get the axis you simply set all sprites to that axis and they are aligned. AOKManiac/Insanius is good about supplying the axis for you with his packs in a read me. I am doing that as well starting with my new Dee rips I just released.
As for the animations. Again, if the sprites are ripped like mine, Kong, AOK, etc get them they have a lot of duplicates. Just use the duplicates in the packs as they are. They are in the correct order for the moves and FF3 will link all duplicate sprites for you later anyway.
Ok so maybe I could say something like "check the readme to see who is credited for the sprites. They may be able to forward you a readme with all the proper alignments." If not, yada yada yada... Sound about right?
Quote from: Madam CanCan on January 04, 2013, 01:16:37 AM
Throws can also have varying damage based on if they can be comboed afterwards or not. For example, if a throw wall bounces, its damage should be lessened a bit since its juggles can be limited depending on position. If a throw just keeps P2 in the air right next to the character (like Gouken), it's best to not give it any damage since any hit is basically guaranteed.
For sure. I'll mention that in the damage exchange section.
@[user id=902]Djoulz[/user]: Hey if you ever want a basic breakdown of how Mugen handles code in general, there's a decent explanation in my beginners editing tutorial. (http://mugenguild.com/forum/topics/character-editing-tutorial-beginners-145533.0.html). Hope it helps!
@[user id=55085]Saikoro[/user]: Glad to hear it man! As a professional chef, of course I like the toppings on the pizza analogy. 'Even topping distribution damn it!' haha that's what this tutorial is going to be about I think, more the toppings than the pizza, and how to get 'even topping distribution'. For the crust and sauce, I'll probably link to the Mugen Study Files and maybe Ryon's character creation tutorial. This will be more for taking an already baked pizza, putting some gloves on and touching up the presentation.
@ⒻⓊⒸⓀⓎⒺⒶⒽ:No worries about derailing, I'm kind of a tangential person myself. I'll just go back to the focus as it becomes necessary ;)
Quote from: DONATELLO on January 04, 2013, 03:13:31 PM
can we please post pictures or snapshots to help noobs like me?
it would help me a lot.
And why not take a char badly coded and post step by step how to update him??
Yes, plenty of pictures in this one for sure. It's geared towards beginner / intermediate level coders & editors.
Quote from: Seraphs Ares on January 04, 2013, 09:37:55 PM
Don't forget about the main data on your character(s).
Data like this -
attack.dist = 90 ;Default attack distance (by pixel.)
proj.attack.dist = 90 ;Default attack distance for projectiles (by pixel.)
head.pos = 0, -114 ;Approximate position of head (by pixel.)
mid.pos = 0, -80 ;Approximate position of midsection (by pixel.)
-are important. Some creators (like me) do use these numbers in their characters. Mainly these numbers are important for AI coding, but these numbers can be used if you're using a projectile or helper that homes based on their mid.pos or head.pos (for headshots).
Right, that should probably go into Constants section, and will use Training Dummy to test them.
Quote from: Seraphs Ares on January 04, 2013, 09:37:55 PM
Also, if you're going to have testers for your character, have testers with experience in that fighting game-style. Unless if it's a completely custom game-style, of course. It's not necessary, but it does help.
Yeah asking for testers would be a great step too. Adding for sure. I'm not sure if this is a response to another idea I was suggesting about a list of characters to pit them against, but if so what I meant was to have a list of other characters to download and put in your roster so you can test the character you're editing by playing against their AI. As Banana pointed out this might help to illuminate some issues that don't arise in training mode.
Quote from: Seraphs Ares on January 04, 2013, 09:37:55 PM
And for positioning characters, onion skinning does help; but if the character is taking big steps when attacking and you want the character's sprite to stay in the middle of the X axis, use the PosAdd state controller. Take the amount of pixels from the leg it started, move it to the desired axis (mainly put the axis in between the legs of the character) and use the difference of that number (starting X - ending X) in the value of the PosAdd state controller.
[State PosA, 1]
type = PosAdd
trigger1 = animelemtime(14) = 0
x = floor(40 * const(size.xscale))
The * const(size.xscale) helps if you're scaling characters.
And.. ..I think I just confused some people.
I know just what you mean, and I'll be sure to point that out in the alignment section. It ends up being pretty obvious which attacks have posadd in them, so I'll make a note to check the debug for which attack states move the character forward or back entirely.
thanks for that, RobotMonkeyHead
No prob mang!
EDIT:@[user id=55085]Saikoro[/user]: This (http://mugenguild.com/forum/topics/character-editing-tutorial-beginners-145533.0.html) might be helpful for you too, now that I think of it. Check out the basics of coding section, it will give a breakdown of how Mugen reads code, and a glimpse at how it's structured. Not quite a recipe or anything, just some framework, really.
@[user id=61380]RobotMonkeyHead[/user]: Personal Chef!? Dude, that's awesome!! The amount of interesting and talented people here on Guild never ceases to amaze me. Fun fact: Two4Teezee is an aerospace engineer.
One thing I'd like to request is pointing us newbs in the direction of, or at least posting where we could find, that stripped down Kung Fu Man. I'd like to start with the absolute basics. Reading this tutorial along with some additional input from Ryon's videos, will help a ton!!
Thanks for starting this thread!! :lugoi:
if you really need a character to polish im sure i can come up with something.
Quote from: Iced on January 05, 2013, 02:22:11 AM
if you really need a character to polish im sure i can come up with something.
Anything by CvS Artist.
Wait, did I let that slip out??
Dont be mean.
I got a fullgame of mspaint characters that needs adapting into normal mugen. =P
Quote from: Iced on January 05, 2013, 02:24:41 AM
Dont be mean.
I got a fullgame of mspaint characters that needs adapting into normal mugen. =P
Okay... :)
Those characters are still floating around somewhere, eh?? Interesting...
Why don't we use me and Saikoro as guinea pigs for this tutorial? He wishes to make an Eternal Champions character and I wish to make Demitri.
If he has the rips me and him can try to assemble the characters. More people work with resources as those so it'd help to clarify what should be standard for the Required sprites. When making Ryu it was kinda hard finding the right sprites for certain requireds even using KFM. And The docs are not always clear.
That is if Saikoro would be interested of course. This kind of reminds me of that MUGEN class we had in Guild YEARS ago. :P
:cawg:
I suppose I could. I mean, you guys totally twisted my arm enough!!
Seriously though, why not. Gotta start somewhere, right?? I must warn you though, progress will be very slow with work and portraits. I'm down.
The one from my tutorials, or one someone strips down themselves or the borked elecbyte template?
@[user id=6464]Cyanide[/user]: I didn't know you had one in your tutorial. Looking into it now....
@[user id=55085]Saikoro[/user]: ever since you told me you'd eventuallly try the character coding process (with Eternal Champions characters), i got excited! i think you should definitely do it!! very nice choice for a learning/starting choice (not like mine >__>)
btw: shotgun on testing...even if there is a shit load of better feedbackers ;) (it goes both ways of course if you want)
Quote from: Seraphs Ares on January 04, 2013, 09:37:55 PM
Don't forget about the main data on your character(s).
Spoiler (click to show)
Data like this -
attack.dist = 90 ;Default attack distance (by pixel.)
proj.attack.dist = 90 ;Default attack distance for projectiles (by pixel.)
head.pos = 0, -114 ;Approximate position of head (by pixel.)
mid.pos = 0, -80 ;Approximate position of midsection (by pixel.)
-are important. Some creators (like me) do use these numbers in their characters. Mainly these numbers are important for AI coding, but these numbers can be used if you're using a projectile or helper that homes based on their mid.pos or head.pos (for headshots).
We also need to add in some of the stuff POTS had like how to implement the ability to reduce the height of your character's pushbox. It's mentioned here under "Size box" variations (http://mugenguild.com/forum/topics/the-greatest-hits-character-feedback-99092.0.html) among other need to know basics.
QuoteAnd for positioning characters, onion skinning does help; but if the character is taking big steps when attacking and you want the character's sprite to stay in the middle of the X axis, use the PosAdd state controller. Take the amount of pixels from the leg it started, move it to the desired axis (mainly put the axis in between the legs of the character) and use the difference of that number (starting X - ending X) in the value of the PosAdd state controller.
[State PosA, 1]
type = PosAdd
trigger1 = animelemtime(14) = 0
x = floor(40 * const(size.xscale))
The * const(size.xscale) helps if you're scaling characters.
I didn't know that. I need to add that to my scaled characters! Tutorial is already working :P
Quote from: Cyanide on January 04, 2013, 10:16:38 PM
JNP: I did the whole "Do what the fuck i like" in SBME. They had 400 life. I made up my own animation for the spinning about your axis. Crouch was disabled etc etc. It still had SOME regular mugen stuff in it, but mostly it was me making it up.
After release people put their own stuff in and complained that the sonic stuff was too weak or took it out, complained that it vanished when it crouched AND that it was too weak.
Morons.
GOLD. That's hilarious. Probably best within a sub forum if it got kicked off then. Though you may have had your own private area for that and it still happened...
Quote from: RobotMonkeyHead on January 04, 2013, 11:14:52 PM
Ok so I whipped up a quick outline for the tutorial. Not near writing it yet, just figured it would be better to have early on in the process so we can make adjustments to it as we want. As we come up with new material, I can just add a placeholder in here for it. I realize there are a lot of sub sub sub...points to add still and again this thing is not remotely concrete, and totally open to any input suggestions, section or total revamps whatevs etc.
list
Let's not spend a lot of time on the actual alignment. There are a lot of tutorials about that. Ryon posted some great videos talking about that process. If you have not seen his vids you should look at them. They may be good to actually add into this tutorial.
The only thing still somewhat confusing about the sff is what sprites go where in some custom states.
Quote from: RobotMonkeyHead on January 05, 2013, 02:03:03 AM
Ok so maybe I could say something like "check the readme to see who is credited for the sprites. They may be able to forward you a readme with all the proper alignments." If not, yada yada yada... Sound about right?
Maybe something like "If you are lucky and can get a sprite pack with perfect axis that gives you the axis be sure to set all sprites to those numbers. If the ripper does not supply you with the axis then you'll have to use your best effort to make sure the feet feel firmly planted unless of course you know how to accurately get the axis yourself."
IMT Mugen Forum uploaded my Dee rips to Kong's section. Maybe I can get the axis info from some of the CPS2 games and they'll add in the document for me.
I'd intended to say all this earlier but had less time to post.
The way to sort accurate axis out for Dee is actually pretty simple.
Rip him with his shadow. Use FBA/MAME:RR and rip someone else from the same game series with shadow AND axis. Align axis character. Align Dee to the shadow of axis character. There is your alignment correct.
Really possible with capcom stuff, cos their shadows are circles. SNK would be harder.
@[user id=6464]Cyanide[/user]: Your Narutorials are intriguing. Very much so. I'm going to read through these and watch Ryon's videos. Then.... well, that's when the fun starts. I remember how fun it was when I ripped, resized, reorganized and recoded every frame of animation for BrokenMugen's background animation loop.
I think its time I begin planning stuff for my intended Trident. Mugen needs good Eternal Champions conversions. :devilish:
I'm in a tutorial mood. I think I'll make a tutorial about making characters from scratch.
@[user id=35413]Rajaa[/user]: Do it. The more info, the merrier.
And goddamnit, it looks as if these antiquated Eternal Champions Sprite Sheets are missing a lot. Like a whole fucking lot. Well, time to bring up some ROMs and patience. Yay.
Quote from: Cyanide on January 05, 2013, 09:16:38 AM
The way to sort accurate axis out for Dee is actually pretty simple.
Rip him with his shadow. Use FBA/MAME:RR and rip someone else from the same game series with shadow AND axis. Align axis character. Align Dee to the shadow of axis character. There is your alignment correct.
Really possible with capcom stuff, cos their shadows are circles. SNK would be harder.
I had already gotten Dee's axis. He has the same axis as Demitri and I already ripped Demitri's from Mame RR using the CLSN displayer. Dee has an axis.txt
Quote from: Rajaa on January 05, 2013, 09:36:50 AM
I'm in a tutorial mood. I think I'll make a tutorial about making characters from scratch.
Having followed a tutorial in French from Mike Werewolf for my 1st Mugen creation, I can say these work wonderfully if written right.
If you ever get the motivation to start one, I can "beta-test" it and proof-read it. ;)
Some stuff that I didn't get to add in my earlier post - stuff that I've learn from creating my BlazBlue edits from scratch. Four BlazBlue characters from stratch - I could probably write a tutorial for it.
Smart PosAdd-ing and Sprite Positioning-If your character takes more than one PosAdd or the animation takes more than one step, consider the following:
Take the starting sprite X axis that takes that step, then take the ending sprite X axis that centers itself into the standing sprite (0,0), then that that difference and divide it by the amount of sprites it takes from the starting sprite to the ending sprite.
Example: Starting step to ending recovery sprite takes 100 pixels, from start to end step takes 4 sprites. 100/4 = 25 pixels. For every sprite in between the starting step to ending sprite, add 25 to the X axis. Confused? Take all the sprites after the starting step to the sprites before the ending sprite and add 25 times whatever sprite you're on. 25 for the first sprite after the step, 50 the second sprite, ect.
After that, add the code for each animelem that you added the 25 on.
[State PosA, 1]
type = PosAdd
trigger1 = animelemtime(3) = 0
trigger2 = animelemtime(4) = 0
trigger3 = animelemtime(5) = 0
trigger4 = animelemtime(6) = 0
x = floor(25 * const(size.xscale))
Makes your character move smoother across the floor, and makes it look center if you have that attack follow up into a different attack. This also helps A LOT if you're working with BlazBlue characters. Some of them, like Noel Vermillion, have attacks that have more than 100 pixels in one step.
Now this is different if the animation does not have an even amount of sprites from start to finish. Take the same example but instead it takes 3 sprites from start to finish. 100/3 = 33.333~. Don't panic, be smart, know your math. 33+33 = 66+34 = 100. So the first sprite after the step add 33, then add 66, then 100 to the second to last sprite. Then in the code:
[State PosA, 1]
type = PosAdd
trigger1 = animelemtime(3) = 0
trigger2 = animelemtime(4) = 0
x = floor(33 * const(size.xscale))
[State PosA, 1]
type = PosAdd
trigger2 = animelemtime(5) = 0
x = floor(34 * const(size.xscale))
Now if the character has a cluster**** amount of sprites to take that step- like my Jin-Edit in State 225, don't get overwhelmed. Try to separate the steps or try to have the same amount of pixels to take that step. Try to understand what I have below (Taken from my Jin-Edit State 225)-
[State PosA, 1]
type = PosAdd
trigger1 = animelemtime(2) = 0
x = floor(10 * const(size.xscale))
[State PosA, 1]
type = PosAdd
trigger1 = animelemtime(3) = 0
trigger2 = animelemtime(6) = 0
x = floor(50 * const(size.xscale))
[State PosA, 1]
type = PosAdd
trigger1 = animelemtime(4) = 0
x = floor(70 * const(size.xscale))
[State PosA, 1]
type = PosAdd
trigger1 = animelemtime(5) = 0
trigger2 = animelemtime(12) = 0
trigger3 = animelemtime(13) = 0
x = floor(60 * const(size.xscale))
[State PosA, 1]
type = PosAdd
trigger1 = animelemtime(14) = 0
x = floor(40 * const(size.xscale))
-sometimes the step is not completely perfect. This is why testing is very useful.
Creating a character in MUGEN may look very confusing and overwhelming at first, but most of it is common sense. Unless you're working with a very complicated character
that spawns helpers that swarm all over the screen giving instant death to all characters, of course.
PosAdd Faults and how to fix them-If you're going to work with a lot of PosAdds or the PosAdd takes more than 50 pixels, consider the following:
State controller Width is your best friend. When to add Width state controller? On your character's state with the PosAdd. Take your character and pit him/her/it/thing/being/whatever against a character that has decent amount of speed in their run. I suggest any of the Guilty Gear, Basara, Arc Sys characters or any character that can run forever. Make that character run into your character until your character is being pushed. While your character is being pushed, activate that attack or state that has that PosAdd; if the running character teleports behind your character then you need to add Width to that attack with the PosAdd. When and how much Width? Add Width at the starting animation element then ending it with the ending time of the finishing sprite and the same amount of pixels it takes to take that step (Give or take a few pixels). Taking the example above with the PosAdd code:
[State Width, 1];Add Width during the active animation element to the end of the last active element.
type = Width
trigger1 = animelemtime(3) >= 0
trigger1 = animelemtime(6) <= 5 ;Ending sprite with the last frame/tick/time of that sprite.
player = 25,0
Now your character won't teleport behind the running character. I recommend testing this frequently: most of the time you may NOT need to have the same amount of Width it takes to make that step. You may have more Width that you should: the character will have a lot of space between the running character and yours.
___________________________________
Quote from: Just No Point on January 05, 2013, 04:42:29 AM
We also need to add in some of the stuff POTS had like how to implement the ability to reduce the height of your character's pushbox. It's mentioned here under "Size box" variations (http://mugenguild.com/forum/topics/the-greatest-hits-character-feedback-99092.0.html) among other need to know basics.
Favorited. I didn't know that existed til now. I will have that implemented in my 1.0 versions of my characters.
Quote from: Just No Point on January 05, 2013, 04:42:29 AM
I didn't know that. I need to add that to my scaled characters! Tutorial is already working :P
At first when I was recreating Ares; my thoughts "D***, I have to multiply 0.34 to all the steps? Wait a minute, can't I just add this * const here?" And you're welcome.
Hopefully some of my contributions here can help you guys out.
I'll post back here when I have more stuff to share during my porting of my Haku=Men edit.
Edit: Fixed the coding and explanation of the Width code.
Posadds take float values.
Also, it's a matter of looking correct, not division of number of frames from start to finish by the amount of pixels you wish to move. When it comes to stepping forward moves, use onion skin or move the axis in the air file to see exactly how much posadd should be applied, every case is different.
Quote from: (det∇ϕ(x))²-µ(λ+µ/θ)/∂Ω on January 05, 2013, 11:59:35 AM
Quote from: Rajaa on January 05, 2013, 09:36:50 AM
I'm in a tutorial mood. I think I'll make a tutorial about making characters from scratch.
If you ever get the motivation to start one, I can "beta-test" it and proof-read it. ;)
Sure thing. :)
PosAdds take float values? I didn't know that. Thanks, good to know that.
Quote from: Rajaa on January 05, 2013, 01:33:37 PM
Also, it's a matter of looking correct, not division of number of frames from start to finish by the amount of pixels you wish to move. When it comes to stepping forward moves, use onion skin or move the axis in the air file to see exactly how much posadd should be applied, every case is different.
Very true Rajaa. Everyone makes their character(s) differently. I have that method to simplify things - keeping the amount of PosAdds to a minimum.
Although I am somewhat confused here, I believe my subconscious is slightly enlightened by reading about that code.
I've done some experiments on 1.0 with the whole localcoord and the x/y scales. I see a lot of conversions and confusion of this topic. I'll share my piece of LocalCoord VS. Scaling, since this is a somewhat of a intermediate coding tutorial. If I'm wrong, feel free to correct me. I haven't seen a definite explanation to this topic, so here's my version:
LocalCoord VS. Scaling:LocalCoord affects the size of your characters, including CLSN boxes AND your character's protrait (9000 group). LocalCoord is like the overall workspace of your character. Think of this as the resolution of your character. If you don't know what numbers to set for your localcoords, here's some resolution references.
320x240 - Standard Mugen
640x480 - Hi-Res Mugen
1280x720 - Hi-Def Mugen
1920x1080 - Full-HD Mugen
Standard low-res characters are mostly 320x240. Hi-Def Characters, which are mostly the HD fighting games that are around now, like BlazBlue, are 1280x720. Many characters in MUGEN are scaled differently, so you can play around with these numbers if you want to scale your character to your desired scale.
Messing around with LocalCoord does not effect velocity/gravity.
It also doesn't affect positioning of all helpers/projectiles/explods.
All scaling of all explodes will stay the same to whatever you have it set to.LocalCoords help a lot if you want to keep the scale of your characters to 1,1.
Scaling also affects the size of your characters, and also effect CLSN boxes. Scaling does not effect portraits. If you're working with two different scaled sprites; player sprite is larger than projectile sprite, you may have to make the projectile CLSN box larger.
The smaller the scale, you have to modify the numbers to a smaller number in your velocity/gravity in your main data. Up-scaling = Larger Numbers, Down-scaling= Smaller numbers.
Be wary of changing your scaling frequently, because it will affect the positioning of your explods. This is true unless you defined the scales of your explods already.
If you're like me, working in WinMugen then deciding to port to 1.0 later, feel free to use this code to your explods; it'll save you a lot of time. Instead of changing the scale, it'll scale along with your character's main data (which is the x.scale and y.scale).
[State Explod, 1]
type = Explod
trigger1 = time = 0;change this to whatever you want.
anim = 1 ;change this to whatever you want.
ID = 1 ;change this to whatever you want.
pos = 0,0 ;change this to whatever you want.
postype = p1 ;change this to whatever you want.
bindtime = 1 ;change this to whatever you want.
ignorehitpause = 1 ;change this to whatever you want.
sprpriority = 1 ;change this to whatever you want.
ownpal = 1 ;change this to whatever you want.
scale = const(size.xscale),const(size.yscale)And if your helpers are supposed to be scaled along with your character:
[State Helper, 1]
type = Helper
trigger1 = time = 0 ;change this to whatever you want.
helpertype = normal ;change this to whatever you want.
name = "Example" ;change this to whatever you want.
ID = 1 ;change this to whatever you want.
Stateno = 1 ;change this to whatever you want.
pos = 0,0 ;change this to whatever you want.
postype = p1 ;change this to whatever you want.
sprpriority = 1 ;change this to whatever you want.
facing = 1 ;change this to whatever you want.
keyctrl = 0 ;change this to whatever you want.
ownpal = 1 ;change this to whatever you want.
pausemovetime = 1 ;change this to whatever you want.
supermovetime = 1 ;change this to whatever you want.
size.xscale = const(size.xscale)
size.yscale = const(size.yscale)Again, feel free to add anything to this or correct me in this guys. I have some grasp of the whole localcoord/scaling thing here, but I haven't worked in MUGEN 1.0 too long to have this concrete.
____________________________________________________
Quote from: Saikoro on January 05, 2013, 07:44:24 PM
Although I am somewhat confused here, I believe my subconscious is slightly enlightened by reading about that code.
It does get confusing, you just have to get used to the whole pixel/posadd-ing concept. It just takes testing and seeing if your positioning/posadd looks natural.
Edit: Fixed my very bad wording for velocity/scaling explanation.
Localcoord DOES affect velocity. Velocities have to be adjusted globally for different localcoord, which is the reason why these triggers exist: http://elecbyte.com/mugendocs/trigger.html#const240p
Scaling doesn't affect velocities at all.
Scaling actually affects velocities. Take a look at the velocity set I have on my Haku=Men-Edit. From WinMugen to 1.0. I'm working with a scale of 0.34,0.34 then I converted it to 1,1. I had to multiply the velocity by 3.4 due to his 340% upscale percentage. I'm still tweaking his 1.0 converted velocities.
WinMugen Haku=Men in 0.34,0.34 scale:
[Size]
xscale = .34 ;Horizontal scaling factor.
yscale = .34 ;Vertical scaling factor.
[Velocity]
walk.fwd = 1.7 ;Walk forward
walk.back = -1.2 ;Walk backward
run.fwd = 7.5,-2.5 ;Hop forward (x, y)
run.back = -6,-2 ;Hop backward (x, y)
[Movement]
yaccel = .45 ;Vertical acceleration
MUGEN 1.0 Haku=Men in 1,1 scale:
[Size]
xscale = 1 ;Horizontal scaling factor.
yscale = 1 ;Vertical scaling factor.
[Velocity]
walk.fwd = 5.78 ;Walk forward
walk.back = -4.08 ;Walk backward
run.fwd = 25.5,-8.5 ;Hop forward (x, y)
run.back = -20.4,-6.8 ;Hop backward (x, y)
[Movement]
yaccel = 1.5 ;Vertical acceleration
If I keep the values in his scale 0.34,0.34, he doesn't go anywhere in scale 1,1.
Indeed, a velocity of 8 with a localcoord of 320,240 will give you 8. The same velocity at 640,480 gives you in effect a velocity of 4. Sprites are halved in size, velocities are halved in size. Probably posadds as well though i'm not sure about that.
Localcoord is slightly broken in that it only reads the first number. 320,240 is the same as 320,57483904. No seperate Y scaling.
Although it DOES give a friendly workaround for HR sparks on LR characters without using helpers or explods.
Localcoord 640,480 on a low res character. Then xscale yscale = 2. X and Y scale do not affect hitsparks, but the hitsparks have been scaled down by localcoord. You have then scaled the character back up again. This does mean vel changes etc.
And yes X and Y scale do affect velocity, but not in any sensible manner by the looks. Just checked, my Y jump of 8.8something goes to 8.6something.
Walk changed from 3.8 to 3.2, not logical. Scale was set to 0.2,0.2 and i got this effect, strange.
Scaling does not (is not supposed to) affect velocities at all. Not even in the way you described. I used a displaytoclipboard to test what you just said, Cyanide, and you probably have your displaytoclipboard in a negative state. Place it in the state that the velocity is actually applied, like walking or something. Can even change the scale to 0.0 for X and Y and still get the same velocity.
@[user id=80188]Seraphs Ares[/user]:
You probably changed his localcoord to represent a HD character, which would mean you needed to multiply his velocities by 4 or 6, depending on the HD resolution of the character.
From what original scale are you down scaling from, Cyanide?
If you use up/down scale by a lot, like what I'm working with, you'll see big change in numbers. I'll test out more of this scaling-velocity topic. I have 3 more characters to scale to 1,1 from their WinMugen scales.
Quote from: Rajaa on January 06, 2013, 06:26:35 AM
You probably changed his localcoord to represent a HD character, which would mean you needed to multiply his velocities by 4 or 6, depending on the HD resolution of the character.
I down-scaled his localcoord to 640x480, making him extremely large; I kept his values of 0.34 and he's still in the same velocity as he was in 0.34. Then I upscaled his localcoord to 1920x1080, keeping his 1,1 scale velocities; he has the same velocities he has in scale 1,1 with 1280x720. Used the same setting, 1920x1080, with .34's velocities, still the same 0.34 result: going nowhere, both walking forward/backward, same values.
I'll recode my DisplayToClipboard, do more testing, and continue to play around with the whole localcoord/scaling - velocity setting here. I'm still in the middle of testing the rest of his velocities.
I'm glad to have you guys around; I'm learning new things here in 1.0. :)
Yep, that made a difference, no vels are not scaled.
Why i got stupid results when the displaytoclipboard trigger is 1 though is rather retarded. It was walk, it would have been the same vel every tick of the animation. So it should have reset even with that dozy time = 0 bug. But it didn't. Fuck you mugen.
I just re-read my post for my scaling-velocity. I worded it very, very wrong. I didn't mean that scaling will affect velocities. I mean if you scale your character you have to change the velocities according to the scaling; down-scaling = smaller numbers, up-scaling = larger numbers.
That's what I get for MUGEN-izing and posting here with 4 hours of sleep.
Blame my broken english.
(Edit) I apologize about that small mess I just made. I edited the post to make it sound better.
Scaling does not change velocities, dude. Not one bit. You don't need to mess with velocities if you use scale to change your character's size. This has everything to do with you not know what you're talking about and nothing to do with broken English; your English is fine.
Compare Kung Fu Man and Kung Fu Man 720. They have different localcoords and the same scaling. Everything will become clearer to you.
@[user id=35413]Rajaa[/user]: if you ever feel/decide to actually make that tutorial, PLEASE for the love of porn, make sure you keep in mind that it is a tutorial to introduce coding (amongst other things) to people who do not have primary knowledge in coding in general a.k.a noobs!
Cybaster's Complete Stage Turorial comes to mind straight up: well detailed, with pictures clearly showing what's what, covering the very basics to make a very decent & fun stage!
the idea of talented/great coders sharing their knowledge of the engine language to the community (in a "passing of the torch" kind of thing) is excellent and motivating! i really hope it happens!
I'm with Djoulz here. If someone should actually write up a tutorial, please be as descriptive as possible, much like Cybaster was with his stage creation write up. Being visual with your elaborations is a huge help. I also think it would be wise to have this write up come from the brightest and most knowledgeable minds, like Rajaa, Cyanide, Cybaster, RMH and Ryon. The more input, the better.
As far as my character creation process goes, I'm going to hold off a bit until I actually start something. First off, I'm going to have to manually rip all of Trident's sprites since his available sheets are shit. I also have a shit ton of portrait work to plow through first. In a nutshell, I don't want to change my projected work path. Again. However, in the meantime, I will slowly pick away at absorbing as much as I can. I also want to be sure these rips are as clean as possible WITH color separation!!
You'll want to see Froz about color separation then. :P
I could help write up the section on frame advantage if you'd like, MHB RMH.
@[user id=80090]Madam CanCan[/user]: Will do. I figure its a nice segway to lead in to character creation. None of my sprites are going to have any losiness. Guaranteed.
Also, I think your idea would be great. It would give us better insight into priorities for frame advantages/disadvantages. I'm all for that!!
@[user id=80188]Seraphs Ares[/user]: Yeah Localcoord and Scaling certainly do deserve a mention in this. When it comes to polishing a character, size tweaking is sometimes in order. Specifics aside, good call on the topic.
@[user id=35413]Rajaa[/user]: Thanks for clearing up the localcoord / scaling issue. If you write up that tutorial you mentioned, I will certainly be among the hordes of readers.
@[user id=55085]Saikoro[/user]: I hear the visual thing, it really does help a lot, and I'll try to make that a staple of this tutorial. Also man, just have to point out that I am no where Near the same bracket as Cyanide, Cybaster, and Rajaa. <- These guys are seasoned experts. I'm still in mugen elementary school by contrast ;) But thanks for the comment none the less! Reading both Cyanide's and Cybaster's tutorials has certainly helped move me along though, and I'm stoked to share what I've learned in the same way. That will be really cool if you end up test driving Rajaa's tutorial. I'm going to keep an eye out for that in the (slightly more distant) future for sure.
@[user id=80090]Madam CanCan[/user]: That would be absolutely fantastic. If you want to write up the section on frame advantage, please go for it! Of all the things in this tutorial, that's actually the one I had some apprehension about, so it's perfect really. Thanks for taking the initiative. I was actually thinking I was going to post the sections in this thread as I write them up just for collective checking / proof readage and whatnot, so if you want to do that with the frame advantage section whenever you to it, that, I think would be a good plan.
Ok a couple other section of the tutorial comes to mind to add:
8 - Attack Chaining
8.1 - Testing Combo Chains
8.1.1 - Test Dummy
8.2 - Chaining and Unchaining Basics
8.3 - Juggling
8.3.1 - Wall Bounce, Lifters
8.3 - Super Cancels
8.4 - Dampeners
9 - Scaling
9.1 - X and Y scale to find your proportions
9.1.1 - A few characters to test size against
9.2 - Localcoord vs Scaling
9.2.1 - Adjusting Vels (and likely posadd)
Ok, can I ask for a couple nominations real quick? If you could name one or two characters for each of these types that you think is really coded well, especially in terms of balanced damage exchange, who would they be?
Brawler:
Grappler:
Quick Fighter:
Aerial Fighter:
Technical Fighter:
Boss:
The reason being is I'd like to include them as examples in the damage toning section, and scope out all their damage vals to establish preliminary averages.
Oh, one more final nomination as well: A character we can use to test drive this tutorial on!
I'm getting excited at the thought here. I guess its safe to say I'm gonna be creating something at some point in the near future. It's awesome peeps like yourself that's fueling my efforts.
Hmmm... Perhaps I'm looking at this differently than I should, but how about you list the principles of why a generic fighter, like KFM, acts the way he does, and them segway into your listed templates of sorts?? That way, you could describe why, say the brawler template, functions the way he does because of changes to "X" from your template.
I say this because you're going to have a shit ton of people asking all of those "why" questions. This way, you cover your tracks while also being as informative as possible.
Quote from: Saikoro on January 06, 2013, 07:50:36 PM
I'm getting excited at the thought here. I guess its safe to say I'm gonna be creating something at some point in the near future. It's awesome peeps like yourself that's fueling my efforts.
Hmmm... Perhaps I'm looking at this differently than I should, but how about you list the principles of why a generic fighter, like KFM, acts the way he does, and them segway into your listed templates of sorts?? That way, you could describe why, say the brawler template, functions the way he does because of changes to "X" from your template.
I say this because you're going to have a shit ton of people asking all of those "why" questions. This way, you cover your tracks while also being as informative as possible.
I hope you do delve man, but I understand having a pile of work to get to.
Will do, establish a baseline (kfm) and go into play style 'variations' from there. I might go as far as to mention specific games / companies and their tendencies in damage to cover the gulf between 'source accurate' damage and 'fair in mugen' damage.
I'm almost to the point where I'm ready to start writing up rough drafts for the specific sections, so hopefully well be getting down to the nitty gritty soon.
Yup. My level of excitement is now at a 20 out of 10.
I constantly mention elaborating on KFM because you're going to have people, like me, constantly asking questions, even with KFM's documentation sitting right in front of me. With your descriptions of why KFM behaves the way he does, visually and text wise, you're going to answer a lot of questions and put many concerns to rest. I'd like to see why, say, state XX is this and why these parameters work the way they do. As we read, we will learn. And the more we learn, we could... better apply those toppings.
I had to make that Pizza reference. LOL
@[user id=35413]Rajaa[/user]: I see what you mean. I'd stay in WinMugen if only it didn't freeze so much. I'm in unfamiliar territory here in 1.0. Thanks for the clear up.
Quote from: RobotMonkeyHead on January 06, 2013, 07:34:51 PM
Oh, one more final nomination as well: A character we can use to test drive this tutorial on!
Test drive the tutorial, as in break down the character or remake/polish the character? Whoever is the COTM this month.
Just kidding; jokes aside, I would recommend KFM (In Mugen 1.0). Especially if the tutorial is going to cover both WinMugen and Mugen 1.0. His character (KFM/KFM720) covers both 320 and 720 resolutions. Then again, I haven't downloaded/added enough characters in my roster to even recommend any. I'm too busy with making mine.
Again, Training is probably best to test drive on. I'll get to Frame Advantage writing and probably PM you about it.
Quote from: Madam CanCan on January 06, 2013, 05:42:29 PM
You'll want to see POTS about color separation then. :P
Fixed. Because Froz uses POTS style of separation.
Quote from: Madam CanCan on January 06, 2013, 09:39:21 PM
Again, Training is probably best to test drive on. I'll get to Frame Advantage writing and probably PM you about it.
Sounds good. I've started on the Damage Exchange section, so I'll post a draft of that as soon as it's finished.
Ok, here's that. It still reads clunky, and needs to be refined and added to, but it's a start:
Spoiler: Damage Exchange Draft (click to show)
Ah damage, exchange. There are a lot of things to consider when updating a characters damage values, and we'll cover as many of them as we can without making it too confusing. The first thing we're going to do is to establish exactly what they are and where they are. To do that, let's start by breaking out the Training. Start up your Mugen and pick Vs mode. Set your player up as player 1 and Training as player 2. Once the fight has started, press the Training's medium punch (Y Button) to call up the damage counter (insert pic). What we'll be paying attention to for this part is the top two numbers, Damage and Total Damage. Hit the Training a couple times with your character just to see what they are. For most single attacks, these should be the same, and if they aren't, don't worry about it, we'll cover that in a minute. For now, just grab the Total Damage value. Now for the fun part:
__________/ BASICS
STAND CROUCH AIR
QP: [ 200 : d ], [ 400 : d ], [ 600 : d ]
MP: [ 210 : d ], [ 410 : d ], [ 610 : d ]
SP: [ 220 : d ], [ 420 : d ], [ 620 : d ]
QK: [ 230 : d ], [ 430 : d ], [ 630 : d ]
MK: [ 240 : d ], [ 440 : d ], [ 640 : d ]
SK: [ 250 : d ], [ 450 : d ], [ 650 : d ]
Throw 1: [ s : d ]
Throw 2: [ s : d ]
__________/ SPECIALS
Projectile 1: [ s : d ]
Projectile 2: [ s : d ]
Projectile 3: [ s : d ]
Charge Move 1: [ s : d ]
Charge Move 2: [ s : d ]
Helper Assist: [ s : d ]
__________/ SUPERS AND HYPERS
LVL 1 LVL 2 LVL 3
Projectile: [ s : d ] [ s : d ] [ s : d ]
Charge: [ s : d ] [ s : d ] [ s : d ]
'Combo': [ s : d ] [ s : d ] [ s : d ]
Hyper: [ s : d ]
Here's how to fill it out. Each attack has a [ s : d ] box. The 's' is for the initial state number of the attack, and 'd' is the damage it does. We know how to check the damage already (Training), but how do we check the initial state no? In game, press Ctrl + D to bring up the debug menu for your character. In the lower left you will see a line that reads "STATE NO:" followed by a number. When you throw a punch, or move or do anything at all, you should see that number change. That number is what we're after. Sometimes when you attack, the state will go through a couple different numbers, but what we want here is the first one it goes to when you pull off the attack. That's what's going in the 's' slots on our table. [ State No : Damage ]. If the attack does go through multiple numbers in the State No, just put a little * next to the number like so [ 923*, d ].
Now, since the basic attacks most often use their default states, I've filled those ones out for you already. Be sure to double check them and make sure your character uses those states for their basic attacks though, and if they don't change the numbers I have written in there!
Now, onto the doing it part. You're going to want to get this data for every one of the characters attacks, and there may be attacks that aren't on the table. You'll need to make your own notes / slots for these attacks in the same format. The table is just a basic guide based on common attack types. By the time you're done with it though, it should be tailored to your character, and have each and every one of their attacks noted for state number and total damage. You're probably going to want to break out their moves list, if they came with one. If they didn't, check the Creating a Moves list section in this tutorial.
Once you're done with that, and you have the table filled out, save the original someplace safe and copy and paste another version of it to edit. Take that version of it and compare and contrast it against the Basic Character Type templates in this section. This should give you a very basic idea of what relatively fair attack values look like. Now it this point, if you don't already know, it's probably a good idea to stop and think about how you want your character to play. It's easy enough to make a well rounded characters with a few projectiles and little bit of everything, but in the end, a game full of rounded characters probably isn't going to be as fun as one with some variety. So really think about what you want your characters strengths and weaknesses to be. I'll give you a few things to consider;
Fighting Range: Is my character usually right on the front line throwing punches, kicks and melee attacks (like say Wolverine), or does my character tend to hang back a bit more and use ranged attacks (more like Cyclops).
Technicality: In close combat is my character the type to dodge, counter and parry a lot, setting up for bigger hits (think Samurai Shodown), or is my character more of a button smasher (think Hulk) who wins by doing more damage on the average.
Special Reliance: Does my character spend a lot of their focus on trying to get the power bar up to pull off special attacks that do a lot of damage, or does my character tend to do more damage in other ways.
Comboability: Does my character tend to string a lot of basic attacks together into combo's or do they rely more on single hits to do damage?
This part can be really fun and imaginative, and there is no real right way to do it. Just try to keep it fair is all. If your character turns out to be an ass kicker in every department, you'll see why when you have to fight them! There really is a whole lot more to consider, but this should get you in the right frame of mind for recreating your characters strengths and weaknesses in combat. You could start by listing 1 or 2 strengths and weaknesses you want your character to have, and adding it to their list of damages for reference sake. Note that the 2 values in these templates make up a suggested range for the damage value, they don't include the state numbers.
__/ AERIAL CHARACTER TYPE
Examples: Spiderman, Vega(claw), etc...
__________/ BASICS
STAND CROUCH AIR
QP: [ 20 - 40 ], [ 20 - 40 ], [ 30 - 50 ]
MP: [ 40 - 60 ], [ 40 - 60 ], [ 50 - 70 ]
SP: [ 60 - 90 ], [ 60 - 90 ], [ 80 - 100]
QK: [ 20 - 40 ], [ 20 - 40 ], [ 30 - 50 ]
MK: [ 40 - 60 ], [ 40 - 60 ], [ 50 - 70 ]
SK: [ 60 - 90 ], [ 60 - 90 ], [ 80 - 100]
Throw 1: [ s : d ]
Throw 2: [ s : d ]
__________/ SPECIALS
Projectile 1: [ s : d ]
Projectile 2: [ s : d ]
Projectile 3: [ s : d ]
Charge Move 1: [ s : d ]
Charge Move 2: [ s : d ]
Helper Assist: [ s : d ]
__________/ SUPERS AND HYPERS
LVL 1 LVL 2 LVL 3
Projectile: [ s : d ] [ s : d ] [ s : d ]
Charge: [ s : d ] [ s : d ] [ s : d ]
'Combo': [ s : d ] [ s : d ] [ s : d ]
Hyper: [ s : d ]
__________/ TWEAKING CONSIDERATIONS
1) If your character has more projectiles than average, consider leaning their Basics damage toward
the lighter side. Adjusting the Throws damage depends on the strategy type of your character.
If your character has few to no projectiles heavy, you might want to make up by adding slightly
more damage to the Basics (aerials especially).
2) If your specials and supers are really powerful, try making up for it somewhere else by lowering
the damage of Basics or Projectiles.
Missing: Lots. Other character type templates. How to search cns for state and change damage value. How to account for multiple hit attacks. Finalizing Life, Attack & Defense.
You'll want to refer to Training's buttons as X, Y, etc. Also, Training's name isn't Training Dummy. :P
Oops, ma B. Fixin. Fixed. Thanks.
C.A.N's first draft of the Frame Advantage section:
Spoiler: Frame Advantage (click to show)
What is frame advantage?
It's the your recovery relative to your opponent's recovery from hitstun. Take this example: your jab takes four frames to recover, but P2 recovers in 5 frames. Since you recovered one frame faster, you are at +1 frame advantage.
What is frame advantage good for?
It allows opportunities for links and other combo tools to extend your combos. For example: if your jab leaves you at +5 frames and your medium starts up in 4 frames, a good bit of timing allows you to connect with the medium after the jab connects. Links aren't as useful if your character uses basic chaining, but it can be used to combo aftercertain special moves to extend your combos further or start them a different way.
Why bother with frame advantage?
Because it makes sure that your moves aren't unsafe even on hit. If a move leaves you at negative frames, your opponent can act before you recover. Not to mention links are going to be critical to your character if they don't use basic chains. A look at frame data can also make sure your attacks aren't too unsafe on block or, inversely, too safe on block. Bad frame data can lead to nasty infinites on hit or block.
How do I check frame data in Mugen?
You could go for frame counting, but there's a far easier solution. There's a character called Training that can allow you to see frame data of attacks that hit it. This combined with data from the AIR file can help you find out what links are and aren't possible and if you want them to be possible.
Quote from: RobotMonkeyHead on January 06, 2013, 11:43:19 PM
C.A.N's first draft of the Frame Advantage section:
Fixed. I love how some people call me my display name and others go by my user name. I usually want my username to be the one I'm credited as.
Ah. Good old frame advantages. Vanilla Tekken Tag first taught me about this. And buffering.
Speaking if which, does Mugen even allow for buffering??
I'm really liking where this is going....
I'm pretty sure there's something in the CMD that allows buffering. I know Don Drago's chars used it.
I just realized how much research I'm going to have to do to make this damage exchange section the way I want to. Does anyone know where I can get some good data for damage values in source games? (MvC, MSH, SFA etc...) I'm going to make a damage table kinda like this: (in final form it will be a picture of a table in excel or something) Might be a form of self torture, but I may add frame advantage in these if I can find the data. If I can't get source game, I'm making a list of existing mugen characters to test anyway. Well balanced ones. Any suggestions?
__/ Power Houses
S.QP | S.MP | S.ST | S.QK | S.MK | S.SK | SPECIAL 1 | SPECIAL 2 | HYPER 1 |
Hulk MvC : | | | | | | | | |
Zangief SF2: | | | | | | | | |
Zangief SF3: | | | | | | | | |
Zangief SFA3: | | | | | | | | |
Juggetnaut : | | | | | | | | |
AVERAGE: | | | | | | | | |
Posted: January 07, 2013, 08:46:10 PM
References:
http://wiki.shoryuken.com/Street_Fighter_2:_Hyper_Fighting/Vega
http://wiki.shoryuken.com/Sagat_%28HF%29
http://wiki.shoryuken.com/Balrog_%28HF%29
http://www.gamefaqs.com/dreamcast/914427-marvel-vs-capcom-2/faqs/11265
http://www.eventhubs.com/guides/2009/nov/01/character-strength-comparison-street-fighter-4/
http://www.gamefaqs.com/dreamcast/914427-marvel-vs-capcom-2/faqs/14687
http://faqs.ign.com/articles/429/429845p1.html
http://shoryuken.com/forum/index.php?threads/mvc2-damage-scaling.43636/
http://wiki.shoryuken.com/Haohmaru_%28CvS2%29
http://www.gamefaqs.com/ngpc/198682-snk-vs-capcom-match-of-the-millennium/faqs/8450
http://www.gamefaqs.com/ps2/920078-street-fighter-iii-3rd-strike/faqs/29359
http://www.gamefaqs.com/snes/588700-street-fighter-ii/faqs/25190
I'm pretty sure Koopakoot's Zangief's damage values are accurate to SFA style damage.
Ok, got a template table built in spreadsheet form for easy calculating later on: (click image to enlarge)
[img resized=1 width=800 height=500]http://i.imgur.com/FSVjN.png[/img]
Brawler table will act as a template for the other character type tables.
All damage values will be scaled to Mugen's 1000 point standard life bar from their source games.
Reference material:
Shoryuken.com (http://wiki.shoryuken.com/Special:Categories)
GameFAQs.com (http://www.gamefaqs.com/arcade/list-57)
This table will be filling up slowly, please feel free to suggest characters that you feel should be represented here. My taste tends to be a bit lopsided toward vs series stuff, and arcade classic fighters, so any suggestions are helpful, and will help provide a wider array of tastes represented overall.
With the table how it is now, each fighter type can have up to 6 'representatives'. In the tutorial the table will be downloadable in excel format too, so people can customize it if they like. Here's what I've got so far:
Brawlers: Wolverine MvC2
Grapplers: Zangief SFA3
Powerhouses: Hulk MvC 3, Hulk MvC 2, Juggernaut MvC 3
Aerial: Spiderman MvC 3, Vega (Claw) SFA 3
Technical: Haohmaru SS5, Genjuro SS5
Ranged: Ryu Sf2 HF, Ryu MvC 2, Cyclops MvC 2
Combo Happy: ...may just delete this category all together...
Miscellaneous: Shuma Gorath MvC 2
Posted: January 09, 2013, 11:24:29 AM
So I released an empty version of the table here (http://mugenguild.com/forum/topics/damage-balancing-tool-good-rosters-or-full-games-147302.0.html) for people to check out, and use to balance their own rosters if they want. I have yet to add an attack multiplier column to it. Did consider adding frame advantage data to it, but that more than triples the work load, and it can be explained to useful enough effect without the data.
It lives...
So I'm just about finished cooking up the balancing chart, calling it Grasshopper. All that stuff I said about 'fighter types' is basically out the window at this point (unless it ends up being included as an alternate layout to the chart), it seems to work much better broken up by game. I think someone suggested that...
Here's a link (http://mugenguild.com/forum/topics/grasshopper-balancing-chart-147831.0.html) to the Grasshopper WIP topic if you want to check it out. It's in the 'data gathering' phase at this point, where I'm just trying to load it with characters frame data. If anyone would like an early copy to help with the inputting or just to have, let me know. Usually only takes about 10 min or so to add a character's data.