The Mugen Fighters Guild - Character Editing Tutorial for Beginners

So, you're thinking about doing some edits, hey? Got little to no experience whatsoever? Perfect. This tutorial should get you from pretty much square 0 to a point where you can make some fun changes to characters you like. The grip it provides should be enough for you to teach yourself a lot more using the Doc's folder from there. Hope you enjoy, and happy editing!

1) GETTING STARTED
2) MESSING WITH ANIMATIONS
3) BASICS OF CODING
4) MESSING WITH MOVES
5) TYING IT TOGETHER
6) GOOD LUCK!

_____/ GETTING STARTED

Pick a character you like that you'll really enjoy working on, because it will keep you enthused throughout the learning process. It'll also be helpful if you're familiar with the characters game play before you change it. Ok, so you have your character. Save a backup of their folder and make a duplicate to start messing with. Remember you can always go back and redo the character if you want, so don't even plan on your first shot being something final, it's more like your sketch pad, a learning ground. That being said, all throughout learning you'll need to be referencing files in the 'docs' folder (in the mugen folder), so I usually just a keep it open. It's going to be mostly these 3 files:
sctrls.html
trigger.html
cns.html

_____/ MESSING WITH ANIMATIONS

This can be a lot of fun. It doesn't require any knowledge of how code works, and you can do a lot to a character just by messing with the animations. If you don't already have Fighter Factory, get it here. You will need it for almost everything. Open it up and Load the character by loading their .def file. Check out the Animations section by clicking on the red movie clip box at the top of the screen. Hover to check. Once you're in it should look like this:

Ok we're pretty much going to working with stuff inside the red oval only. See the play button? Click it. You should see the characters standing animation start to loop. Click stop. See the grey bar just underneath the play button? That tells you which animation you're on. It's not the same as the animation number that mugen looks for in the characters coding. That number is right under the 'Name:' field where it says 'Number:'. Don't mess with that or when your characters code goes looking for that animation it won't be able to find it. The 'Name:' can be changed to whatever you want tho, it's just for notes.
Now let's mess with some stuff. See where it says 'Time:'? Try changing that to 20 and pressing play again. That is the amount of time (in game tics) that it stays on that particular frame in the animation. Easy enough. Next to that is 'Flip:' which has the options H, V and HV which mean to flip the sprite Horizontally, Vertically or both, respectively. You can also change the Transparency: which makes that sprite only more or less transparent. 0 is totally solid 255 is invisible. You'll notice it has Source: and Dest: options next to it. Those tell it how to figure out the transparency. Source is how present the Sprite itself is, and Dest is how present the background underneath it is.
Then we have the X axis and Y axis. Those control the exact position of the sprite on the screen. If you go through each frame of an animation (that grey bar just below Name and Number), you can change these values to get the characters movement to feel more or less natural. You can also just click on the sprite and drag it. Test it out with the play button. That's called 'realigning' an animation. Finally, we have the Group: and Index: fields. ALL of the sprites are organized into numbered Groups (usually all the sprites in the same animation are in a single group), and each group contains numbered sprites, the number being the sprites Index. So let's say the characters walking sprites are all in Group 20 for example, and are Indexed as 0,1,2,3,4. You could then say the 3rd sprite in his walking animation is Group 20, Index 2. (They don't have to be indexed in ordered numbers, but it does help a lot for organization.) If you wanted to change one of the sprites in his walking animation to something else completely, try messing with these numbers.

Now let's get down to the collision boxes. When you get to changing frames around you'll need to understand how these work, and it's pretty important to get them right. At the very bottom of the red oval, you'll see some red and blue boxes labeled 'clsn'. Those correspond to the red and blue boxes you see on the characters sprite in the center work window. The blue boxes represent areas of the character that can be hit by an opponent during that animation frame. If your character has a blue box just around his head and none on his body, the opponent will only be able to hit your characters head, everything else will pass right through the body. Now, a common mistake people make here is to have something like 25 or 30 little blue boxes covering their character, to avoid covering blank space. Don't do this. 2 or 3 boxes is fine in most cases. It's a waste of time, and it can actually cause problems to have a lot of them. For example, say an opponent hurls a haduken at your character who happens to be moving toward it. It's possible the haduken could pass right through if the gaps are too big, or if the movement puts him in front of it one frame and behind it the next. You want to account for your characters motion with the blue boxes to avoid this kind of stuff.
As for the red boxes, they represent the area of the screen that your character does damage to, and the same thing applies. On a frame where you're punch connects, you don't want just a little red box on his fist and nothing else. Try to cover the space that his fist moved through as well. Once you got that, and this is good practice, put a blue box, just slightly bigger than the red one, right on top of it. What this does is keeps your attacks from having what's called 'infinite priority', meaning that other characters can't counter it. For great examples of well done collision boxes, download some characters by either Rajaa or PotS. If your collision boxes look like this, you're doing it right. Otherwise people will let you know with feedback when you share it. Here's an example of some decent collision boxes. Notice how the red box is just inside the blue one? A lot of the time, when they're well done, the red and blue will overlap, making the red one hard to spot, so keep an eye out for it. I actually shrunk the red one by 1 pixel for this example.

Now, try realigning a few animations, tamper with the sprite numbers, timing and collision boxes, add some frames (the green plus or minus buttons on the left and right of the Frames bar) etc, to get a feel for how an attack or animation moves. When you save the character, everything you do to the animations will be saved in text form in the characters .air file. After toying with the animations for long enough you should get a handle on how they work.

_____/ BASICS OF CODING

Once you've had your fun with the animations, and you want to start editing their moves, you're going to have to mess with the characters code. Dramatic music. Before you really dig into this, it'll be helpful if you have a basic understanding of how the mugen engine works, so here's a quick explanation.
During the fight, mugen has a bunch (and by a bunch I mean like a freaking novel) of text, or code, that it reads over and over and over 60 times a second. That bunch of code is made up of 3 main parts. 1) All of your characters code. 2) All of the opponents code. 3) Mugens own code that you don't have to worry about.
The only thing we care about to get started is your characters code. So, it all runs in a loop 60 times a second, and depending on what your character is doing at that specific moment, a certain 'chunk' of their code will be read and most of the rest will be ignored (Same goes for the opponent, obviously). These chunks are called Statedefs, or 'States' (<-the term we'll be using) for short. So whatever 'State' your character is in just keeps looping until it runs into a 'ChangeState' command, then it stops and changes to a new State which takes over. This keeps your character going.
Once you get how that works, open up your character in Fighter Factory and check out his States section. It's the blue box icon next to the animations icon at the top of the screen. Look around in there until you find a line like [Statedef 180]. It should look like this:

This marks the top of the code chunk that makes up that State. The State's code (the loop) ends when you reach the next Statedef. Looks like [Statedef 181] but could really be any number. Everything in between is considered State 180. State 180 usually happens to be the characters fight intro.
So next up we have to understand how a State works. What goes on in that loop? Here goes: Each State is broken down into smaller pieces still, called 'State Controllers'. Each State Controller is pretty much a small block of code (about 3 to 10 lines or so, maybe more) that tells the character to do something, like move 5 pixels to the right, start running the weak punch animation, or check to see if the opponent got blasted by that flaming car you just threw at him, or whatever it is. For starters, not counting the StateDef, every State Controller has a Type, and a Trigger. The Type says what it does, and the Trigger says whether or not it does it. Everything after that depends on what the Type is. They look something like this:

[State 0, Do shit] ;<-- obviously 'do shit' has no significance, it's just a note.
Type = changestate
Trigger1 = 2 + 2 = 4
value = 95 ;<-- could be any number you want

Here we have a State Controller that's Type is a 'ChangeState' which means it will change the characters State to 95, starting up the that block of code (state 95) immediately. This is 'Triggered', meaning it happens, only if 2 + 2 equals 4. Again that trigger could have been anything, like say 'if the opponent is within 100 pixles of your character' for example. In that case, instead of Trigger = 2 + 2 = 4 it would have looked like this:

Trigger1 = P2Dist X <= 100

Read triggers.html for the list of possible triggers. A quick side note, if Trigger1 = 1 then it triggers every time, if Trigger1 = 0 it will never trigger. To mugen, literally any number at all (pos or neg) means 'yes', and 0 means 'no'. Also, remember that the Type in a StateDef is totally different than the Type in a State Controller. In the StateDef, the Type tells mugen whether your character is standing, crouching, lying down or in the air (or unchanged) during the entire State. But the State Controller Types come in MANY forms and perform all sorts of wonderful functions. Check out sctrls.html in the docs folder. It starts with the list of State Controller Types, and clicking on any one of them will tell you what it does. Just remember, it has to be 'triggered' to make it do anything at all. Here are some good examples of State Controller Types and Triggers in action:

Now, hopefully that doesn't look as much like Chinese to you as it did a little while ago. Well, that's pretty much the basics, so lets recap. Your characters entire code is broken down into chunks called States which loop. Those break down into State Controllers, which do different things according to their Type. They only do those things if they are Triggered. If you understood that, awesome, that's a good mental image to start with. Either way tho, reading as much of the 'cns.html' file as you can stand will give you a more detailed idea of what I just explained, and lot more. You'll be seeing plenty of that file in the future. Also, all of the characters code is stored in their folder as files ending with .CNS .ST or .ST1 (e.g. asskicker.cns). The code in the .CMD file works the same way, but that deals with taking keyboard or joystick input, and that will come later. Check the cmd.html doc for info on how that works if you want.

_____/ MESSING WITH MOVES

So let's try some simple things to start out with, like see if you can change the damage that the quick punch does. See what other aspects of his quick punch you can change too while your at it. To do that, first your gonna want to open your character up in Fighter Factory and go into his States section. Again, it's the blue box next to the animations one at the top of the screen. Look around in there until you find State 200. The beginning of it will look like [Statedef 200] . State 200 is usually the quick punch, then 210 and 220 are medium and fierce respectively. Once you've found that, look for the State Controller that's labeled 'Type = Hitdef'. Look up "hitdef" in 'sctrls.html'. This will explain all values that go along with that State Controller Type. With that you should be able to change the damage and whatever else you want easily. It's a great place to get started.
Ok, now that you've earned your yellow belt in coding, let's take your character for a test drive. Fire up your mugen and get them into a fight. Vs mode or training mode will probably be best here. When the fight starts, press ctrl + D to bring up the debug menu in the lower left. Pressing it again will switch it to player 2. ( You can also press ctrl + C to make the collision boxes visible.) There are 2 things on there you will want to pay attention to at first, they are the ActionID and State No. They're in the lower left of that text block. Action ID tells you the number of the Animation that is running at the moment, and State No tells you the number of the State that the character is in. This way you can check on everything you've done so far. Throw a quick punch, and see what happens. There's a little dark gold number near the life bars, and that should tell you how much damage was done. Don't worry if it's not exactly the damage you set to quick punch, the opponent has a defense value too.

_____/ TYING IT TOGETHER

Once you've done that, your journey into the world of coding has begun. You've just looked through a few thousand lines, found what you wanted to change, and changed it. Now here's where you'll really take off. Check out State 200 again. Look at all the State Controllers that it has until you find the one of type 'ChangeState'. Pretty much every State has one of these in it, otherwise the character would never come out of that State. Now see what Value that ChangeState has under it. That's what State it changes to. Now go find that State. See where we're going? You could follow this through an entire character if you wanted to, but you would probably come out the other side insane. None the less you now know your way around a characters code.
At this point you can see how it helps to have really well labeled code. KFM is great for this. If the char you're using isn't, I sometimes keep KFM open in fighter factory while I also have the character that I'm working on open, just for reference. Mugen has a lot of State numbers which usually correspond to certain actions. Some of them are just general practice, but necessary (200 being quick punch for example) and some of them, States 0-99, 120-199, 5000-5999 to be exact, are reserved by the mugen engine, and really shouldn't be messed with. Check out the cns.html for a list of the standard states at some point.
Now your pretty much ready to be turned lose, but really quick a few more pieces of advice for your travels. Try to pay close attention to what you do when you edit, because there is very little room (if any) for error in coding. Labeling is HUGE when you're getting started, so you can find what you did, check it, test it and mess with it. I usually label changes I make with something like "my edit: description" so I can use a search and jump right too them. To label something in the code, add a semicolon ; and everything after that on the line, mugen just skips over when it's running, because it knows those are just your notes. It might end up looking something like this:

; my notes
[Statedef 0]
type = A ; my edit, changes move to Air type.
physics = N

You'll notice a lot of this stuff if you haven't already. Also, just a little on the negative numbered states. Statedefs -1, -2 and -3 are special. They are the first states read by Mugen on each loop, beginning with -3, then -2 then -1. They're all read in addition to (and before) whatever state your character happens to be in, with just a few minor exceptions, which I'll explain in just a second. State -1 is where the keyboard / joystick input handling goes on. You can usually find it in the characters '.cmd' file (cmd standing for 'commands'). It's full of things like 'if input is left key then changestate to walk left'. Not in that language obviously, but that's the gist. State -1 and -2 are read on every loop. State -3 is read almost every loop, except when your character is put into a 'custom state' by an opponent. If your character gets thrown for example, the opponent may put them into a custom state meaning they are then in a state in the opponents code, rather than their own, giving the opponent control of them. When this happens your character will not read their own -3 state, until the opponent takes them out of the custom state, giving control back to the character. While in the custom state, your character will still read their own -2 and -1 states though. The only instance where -2 and -1 (and -3) are not read is by 'helpers'. Mugen allows your character to create helpers which are an exact copy of your entire character. I know obviously the first thing you imagine is a clone of your character popping out, but what actually happens is you choose what state your helper starts in, and most of the time they're code is contained by making sure their changestates never allow them to leave whatever states they need to function. If you have a helper (could be anything from a weapon to a striker to a menu to the limits of your imagination) that helper will not read your -2 or -3 states. They will read -1 if you give them access to the keyboard using 'keyctrl' in the state that triggers the helper to appear, but other than that, they don't read anything from the negative states. You can read up more on negative states in the cns.html file if you like. Lots of potential there. If you do, you might want to check out 'explods' while you're at it.
Finally, if you get stuck on a problem, and you will many many times, read Every Single Line of Code in the problem state very carefully, and think about what it's doing. If it's not a problem in the State, check State -2 or -3. If you're really in a pinch and still can't figure it out, try creating a DisplayToClippboard state controller. You can read up on how that works, and you'll see what I mean. Remember to keep checking in with the Docs, because they will teach you how to do almost everything. They aren't going to be something you read once and then get, they're constant reference material.

_____/ GOOD LUCK!

Ok so there's the basics. Once you've been over everything in this tutorial enough times to understand it clearly, you should be well on your way to seeking out advice and understanding more advanced tutorials. Well, that does it for now, I hope you find this helpful, and best of luck to you in your creative endeavors!

-RobotMonkeyHead

P.S. Don't forget to share your work! Feedback is one of the best ways to learn. If it sounds harsh, trust me, it's probably not personal, and if it seems that way, just sift it for the useful bits, cause that's what counts!