RobotMonkeyHeads Editing Tutorial for Beginners

[RobotMonkeyHead]

So, you're thinking about doing some edits, hey? Got little to no experience whatsoever? Well then, 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 understanding 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!

_____/ 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 by 2 + 2 equaling 4. Again that trigger could have been anything, like is the opponent 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 not, if Trigger1 = 1 then it triggers every time, if Trigger1 = 0 it will never trigger. To mugen, any number at all means 'yes', and 0 means 'no'. Also, remember, the Type associated with a StateDef is a totally different thing than the Type of a State Controller. 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. There are 2 things on there you will want to pay attention to at first, they are the ActionID and State No. 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. You can also press ctrl + C to make the collision boxes visible.

_____/ 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, Statedefs -1,-2 and -3 are special. They're all read basically every single loop no matter what, in addition to whatever other State your character is in. Read up on them in the cns.html file. If you get stuck on a problem, read Every Single Line of Code in a state very carefully, and think about what it's doing. If it's not a problem in the State, check State -2. If your 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 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, and totally capable of 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!

[Ryon]

Hmmm your editing tutorial looks nice i'm short on time so i cant read it. But i will. and it looks very well detailed. *troll time* but my complete character creation tutorial is better.* *end troll time*

[llyyr]

huh? Trigger1 = 2 + 2 = 4 ;Is that valid? then what it means? LOL

[Ryon]

no its not valid. in fact i think thats a STUPID example, to use a made up trigger.

[RobotMonkeyHead]

2 + 2 = 4 is an absolutely brilliant trigger, which evaluates to True, and is completely valid. Ryon you should know that. Awesome etiquette btw.

[Laharl]

why did you report my post ROFL and I actually couldn't tell you were joking. espescially when you edited the post when it just said you suck at life.

[llyyr]

2 + 2 = 4 is a stupid trigger example..........for sure. also Ryon's Tutorials are great watch them first then talk about them.........

[RobotMonkeyHead]

Look, I could care less if you think 2 + 2 = 4 is idiotic or not. It's not changing. The reason it is what it is, is to make the double equal signs less confusing and lay the groundwork for the logic of how a trigger functions to someone who has no idea what one even is. In my opinion it's perfect because it requires no further explanation. Get it? Also that post about Ryon's tutorial that I erased was a joke. It said so in the post. Read them first, then talk about them... (erased because I knew some genius would take it for serious)

[Ryon]

my tutorial aside. i just think for a "beginners" tutorial. you should use some form of a real trigger, and tell them where to go to get other triggers (i.e. doc's folder , triggers.html)

[RobotMonkeyHead]

That's fine. I do follow it up with real examples of triggers immediately afterwards. The point of that one is to lay the logical groundwork / understanding without the specifics of any particular trigger getting in the way. Thanks for the advice, but I think I'm going to keep it the way it is. Also, not everyone is looking to learn Everything about creating a character from scratch. Some people just want to dabble a little, and tool around with some basic stuff without "wasting months or years of their time on some video game." The hardest part of getting into it is the first step, bridging the gap from 0 knowledge to a place where you can have some fun, and know enough to teach yourself from there. That's where my tutorial lands. I wouldn't call your tutorial any 'better' than this one. More thorough, and you put more time into it, I'll give you that, but it's geared toward a different audience, for a different purpose. There are plenty of people who would skip you 'encyclopedia' for my 'magazine' while they're taking a dump or killing a little time. On another note, I'll certainly be giving your tutorial a test drive some time in the near future, I'm sort of working myself up to character creation. Looks pretty comprehensive at a glance, and I'm tempted to say 'nice job' without even looking through it. Kinda funny you thought plugging your own tutorial was trolling, but calling parts of mine stupid wasn't, tho. I think you got it backwards. Just a tip, but that kind of stuff can be kind of off putting for newcomers to your forum, so I would try to keep it more constructive, and less offensive. Cheers P.S. I'm not even remotely done with this yet. It's kind of a work in progress that I'll be adding to as my learning progresses, so check back in a few months or so, and there should be a bit more!

[llyyr]

you could just use trigger like time = 0 that is simple too.