Character Polishing Discussion for eventual Tutorial Building

[Iced]

if you really need a character to polish im sure i can come up with something.

[Saikoro]

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

[Iced]

Dont be mean.

I got a fullgame of mspaint characters that needs adapting into normal mugen. =P

[Saikoro]

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

[JustNoPoint]

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.

[Saikoro]

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.

[Cyanide]

The one from my tutorials, or one someone strips down themselves or the borked elecbyte template?

[Saikoro]

@[user id=6464]Cyanide[/user]: I didn't know you had one in your tutorial. Looking into it now....

[Joulz]

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

[JustNoPoint]

Don't forget about the main data on your character(s).

Spoiler (click to show)

Data like this -

Code Select Expand


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 among other need to know basics.

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.

Code Select Expand

[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

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

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.

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.

[Cyanide]

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.

[Saikoro]

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

[Rajaa Retired]

I'm in a tutorial mood. I think I'll make a tutorial about making characters from scratch.

[Saikoro]

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

[JustNoPoint]

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

[Cybaster]

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.

[Seraphs Ares]

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.

Code Select Expand


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

Code Select Expand


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

Code Select Expand


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

Code Select Expand


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

___________________________________

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

I didn't know that. I need to add that to my scaled characters! Tutorial is already working

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.

[Rajaa Retired]

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.

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.

[Seraphs Ares]

PosAdds take float values? I didn't know that. Thanks, good to know that.

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.

[Saikoro]

Although I am somewhat confused here, I believe my subconscious is slightly enlightened by reading about that code.