Character Polishing Discussion for eventual Tutorial Building

[Seraphs Ares]

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).

Code Select Expand


[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:

Code Select Expand


[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.
____________________________________________________

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.

[Rajaa Retired]

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.

[Seraphs Ares]

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:

Code Select Expand


[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:

Code Select Expand


[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.

[Cyanide]

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.

[Rajaa Retired]

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.

[Seraphs Ares]

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.

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.

[Cyanide]

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.

[Seraphs Ares]

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.

[Rajaa Retired]

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.

[Joulz]

@[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!

[Saikoro]

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!!

[Sinnesloschen]

You'll want to see Froz about color separation then.
I could help write up the section on frame advantage if you'd like, MHB RMH.

[Saikoro]

@[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!!

[RobotMonkeyHead]

@[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! 

[Saikoro]

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.

[RobotMonkeyHead]

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.

[Saikoro]

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

[Seraphs Ares]

@[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.

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.

[Sinnesloschen]

Again, Training is probably best to test drive on. I'll get to Frame Advantage writing and probably PM you about it.

[Aldo]

You'll want to see POTS about color separation then.

Fixed. Because Froz uses POTS style of separation.