Character Creation Walkthrough

[DavidGee]

• Part 1: Ripping from Windows Games with VMware Workstation
• Part 2: Cleaning Rips with PSP Scripts
• Part 3: Sprites that are Required for MUGEN Characters
• Part 4: Preparing a Character Palette with PSP
• Part 5: Making a Character SFF File with MCM
• Part 6: Making Character Animations with MCM
• Part 7: Making Collision Boxes with MCM
• Part 8: Squeezing out a Few More Sprites
• Part 9: Making a Character CMD File
• Part 10: Programming Basic Attacks

Part 1: Ripping from Windows Games with VMware Workstation

This is the first part of my character creation walkthrough, where I'll be walking through the entire process of making Sou, the playable character from Blade Warrior.


Tools used: VMware Workstation, VirtualDub, Paint Shop Pro

The first thing that has to be done, of course, is obtaining the character's sprites. I'll do that by capturing a regular video of the game and taking the sprites out of that. As far as I know, it's not possible to capture video from this kind of game (full screen Windows 95 games) simply by using a screen capturing tool such as SnagIt, as you'll end up with a blank screen because the captured video won't use the game's palette. I suppose this problem can be overcome with the right hardware, or there may be other solutions, but I'm not familiar with any. I used VMware Workstation to get my video. This tool allows you to install an OS on a virtual machine on your hard drive and run that OS from a window in your real OS. I installed a copy of Windows on a virtual machine and added the game to it from a CD I burned.

Screenshot 1 - a virtual machine running Windows XP.

Then I just started the game and used the Capture Movie option, which will record the screen of your virtual machine and output it to an AVI video file.

Screenshot 2 - starting a video capture of the virtual machine.

I simply played through the first level of the game, making sure to include all the sprites I would need in the video. In the case of this particular game, it will be very easy to get all the graphics I need from normal screen shots, but for other games, you would probably want to hack their memory or graphics storage if possible to make things easier. After I was finished with the capture, I opened the AVI file with VirtualDub, a free program that allows you to scroll through frames in a large video very rapidly with your mouse's scroll wheel. I used this in conjunction with Paint Shop Pro to save all the screens from the video that I will need as individual images.

Screenshot 3 - the video in VirtualDub.

In PSP, the screen capture commands are found in File-->Import-->Screen Capture. First I set it up to capture "object", or a visual component of an application. Then, I customized the layout of the tools by placing the Start command from the Screen Capture menu on the main menu for easy access. Right-click-->Customize on any toolbar to enter a mode where you can drag tools and commands to other locations. Now, all I have to do is click Start and PSP gets minimized and is ready to make a capture. Then I just right-click and then left-click on the video's screen in VirtualDub to capture the image, and PSP regains focus.

Screenshot 4 - setting up the screen capture in PSP.
Screenshot 5 - customized main menu in PSP.

Now, I repeat that process for each image I'll need and save them as separate images with meaningful names. I use the .pspimage file type simply because it is the default (so I just need to click the disk icon and type a name in the Save As dialog). Also, this is a lossless format, so no image data will be lost. Never use image compression formats like JPG for MUGEN development. I will use the Batch Process tool to convert them all at once later.

Screenshot 6 - saving stand.pspimage in PSP.
Screenshot 7 - saving slash-up1.pspimage in PSP.

I noticed that some instances of particular animations were missing frames that were included in other instances. I don't know if this is the game's fault or VMware Workstation's fault, but I made sure to double check everything to ensure that I wasn't missing any frames. Anyway, once I was finished saving all the images I needed, I used PSP to convert them all to the PCX format that MUGEN uses. From the menu choose File-->Batch-->Process to get the dialog. Click the Browse button to select all of your images, choose New Type for Save Mode, and choose ZSoft Paintbrush (*.pcx) for Type. Make sure that Use Script is not checked, as we aren't running any scripts on the images. I chose an empty new folder for the output folder so that I could simply delete the folder with the .pspimage files after the job is over. Just click the Start button, and your image conversions are made.

Screenshot 8 - Batch Process dialog in PSP.

The next step, "cleaning" the rips -- or removing the excess so that we only have the actual character sprites, is covered in Part 2: Cleaning Rips with PSP Scripts.

[DavidGee]

• Part 1: Ripping from Windows Games with VMware Workstation
• Part 2: Cleaning Rips with PSP Scripts
• Part 3: Sprites that are Required for MUGEN Characters
• Part 4: Preparing a Character Palette with PSP
• Part 5: Making a Character SFF File with MCM
• Part 6: Making Character Animations with MCM
• Part 7: Making Collision Boxes with MCM
• Part 8: Squeezing out a Few More Sprites
• Part 9: Making a Character CMD File
• Part 10: Programming Basic Attacks

Part 2: Cleaning Rips with PSP Scripts

This is the second part of my character creation walkthrough, where I'll be walking through the entire process of making Sou, the playable character from Blade Warrior.

This article deals with preparing the rips for use in MUGEN.


Tools used: Paint Shop Pro, FastStone Image Viewer

First of all, I use FastStone Image Viewer, a free program, to browse through my images. There are plenty of image browsing tools, and PSP even includes one, but I prefer using FastStone's for various reasons. I don't recommend xnView at all, because it was hell uninstalling and then removing all the crap that didn't uninstall as well as fixing all the damage it caused. Here's a screenshot of my images in FastStone Image Viewer.

Personally, I use a graphics card that supports a dual display setup, so I have a lot of screen real estate. I definitely recommend doing this if you can. Here's a huge (2560x1024) screenshot of what it actually looks like when I'm doing this kind of work, if you're interested. I have both applications maximized on separate displays, and I just drag and drop images I want to work with from Image Viewer to PSP.

I open a random image and change the background color to pure green, which is what I'm going to change everything other than the character's sprites to (screenshot). I choose pure green since it's clearly different from any colors in the sprites. If you have sprites that use green, you'd want to choose another color for your background (like pure pink). I then select the Color Replacer tool. You may need to click the arrow to the right of the Dropper tool to select Color Replacer. Now I click the Start Script Recording button on the Script toolbar to begin recording a script that I'm going to run on every image (screenshot). When using the Color Replacer tool, you just hold the Ctrl key on your keyboard to use the Dropper tool. These are the only tools that I'm going to use.

I start by using the Dropper tool to make a particular color in the background the foreground color by left-clicking on it (screenshot). Then I stop holding Ctrl and double-right-click to replace that color in the image with pure green, my background color (screenshot). I repeat this process for every color in the background until there aren't any more that can be changed. Unfortunately, the character's sprites share a few colors with the power bar and the enemy that was captured. So each time I replace a color, I make sure that no part of the character has changed to green, else I undo the change. After completing this process, I click the Save Script Recording button to save every command I've made to a script (screenshot). You'll notice in the screenshot that there are still some excess pixels, because they use colors that are shared by the character sprite. When saving the script, you probably have to place it in a "trusted" location, such My Documents\My PSP Files\Scripts-Trusted. Also, I used my mouse's scrollwheel to quickly zoom in and out on the image, which makes the process easier, so I would definitely get a mouse like that if you don't have one. Now I close the image, and there is no need to save changes.

Next, I make a copy of the folder containing all the sprites in FastStone Image Viewer, because I will need a back up of the original images in case anything goes wrong (e.g., I may have removed colors that are actually used by other sprites). It turns out that PSP doesn't batch process PCX files, so I used Image Viewer to batch-convert the copies to BMP (screenshot). Then in PSP, I choose File-->Batch-->Process from the menu to run the script I saved on all of these images (screenshot). This can take a very long time depending on your system and how much work is being done. After the job's completed, I check Image Viewer to see the results, and I find that many of the rips are nearly cleaned, while others that were taken from other areas still have some excess that obviously doesn't share colors with the character (screenshot). So I make a new script to remove these colors and run that one. Since there's no images where I will need the area occupied by the power bar on the bottom of the screen, I then make a script to change the size of each image from 640x480 to 640x450 (Image-->Canvas Size), effectively cutting the power bar off.

At this point, there isn't any more I can do to remove excess through scripting. So now I move all the modified images (BMP) to the same folder as the orignal ones (PCX) so that I can go back and forth between them in Image Viewer to make sure that no colors were removed from any of my character sprites (screenshot). No sprites were harmed, except that in the knee of some of them, there is one green pixel. So I just get the color from an original image and fill it in (screenshot). For most of the remaining excess, I just make selections with the Selection Tool and cut them from the image (Ctrl+X) -- that is, change them to my background color (screenshot). The only remaining problem is that some rips were made against the one area of the game's background that shares a color with the character. For these, I can just zoom in and use the Color Replacer Tool or Flood Fill Tool on these pixels in most instances (screenshot). For a few instances where the background pixels make contact with same-colored pixels in the character, I just use the Paint Brush tool, as it's still clear which pixels belong to the character and which don't. Instead of doing this, you could re-rip those sprites in a better area if you aren't sure.

I noticed when working with the sprites that the game scaled the graphics up (and strangely so) on my system, since the Paint Brush tool set with a Size of 1 would only cover 1/4th or 1/6th of a "pixel" -- that is, each "pixel" was actually either 4 or 6 pixels depending on what row it was in. So I made another script to resize the images 50% with Pixel Resize (the other methods will make intermediate pixels between the character and the background, so never use those when working with sprites unless you want to do a lot of editing by hand). For this script, I selected it in the toolbar and pressed the Edit Selected Script button to make the action "Silent" rather than "Interactive" so that I won't keep getting the Resize dialog every time (screenshot). The sprites ended up looking pretty weird since some rows are doubled (as shown here). Especially troublesome is the hideous sword.

At this point, I have no need for all the green space. Normally, you'd want to leave it so that your sprites are aligned accurately in your SFF file, but my rips don't have the axis locked anyway (I'll just align them by hand using MCM), so I ran another script to crop all the images to the actual sprites (screenshot). For the "paste as transparent selection" operation, I pasted to the middle of the image so that nothing would be left out for the other sprites when processed. Then I removed all the redundant rows manually by selecting and moving selections with Ctrl+[Arrow Key] (example result). Took a few hours, but coming up with something to automate this would've taken me longer. (Thankfully, it's only 84 sprites; things could be worse.... and besides, it's not so bad when you've had enough to drink .) I used IrfanView to cycle through the sprites blown up afterward, spotting a few lines that I missed the first time around. It turns out that the sprites are about half as high as Kung Fu Man's, so we'll have a small character.

Now that I finally have the actual sprites, I'm ready to get all of the required sprites for a character, which is covered in Part 3: Sprites that are Required for MUGEN Characters.

[DavidGee]

• Part 1: Ripping from Windows Games with VMware Workstation
• Part 2: Cleaning Rips with PSP Scripts
• Part 3: Sprites that are Required for MUGEN Characters
• Part 4: Preparing a Character Palette with PSP
• Part 5: Making a Character SFF File with MCM
• Part 6: Making Character Animations with MCM
• Part 7: Making Collision Boxes with MCM
• Part 8: Squeezing out a Few More Sprites
• Part 9: Making a Character CMD File
• Part 10: Programming Basic Attacks

Part 3: Sprites that are Required for MUGEN Characters

This is the third part of my character creation walkthrough, where I'll be walking through the entire process of making Sou, the playable character from Blade Warrior.

This article deals with expanding the character's sprite set to include the sprites required by MUGEN.

Tools used: Paint Shop Pro, FastStone Image Viewer

When making your first character, it's best to start small. Make a simple character by modifying Elecbyte's Kung Fu Man to learn how everything's done. That's what I'll be doing in this walkthrough, and that's why I chose a pretty simple character with a small set of sprites. Before I get to that point, though, I have to have certain get-hit sprites that MUGEN requires characters to have that weren't in the game I ripped from. These sprites are commonly used for throws, so if your character doesn't have them implemented correctly, he'll disappear whenever another character throws him. A description of these sprites is found in docs\spr.txt, and docs\spr.gif is an image that shows all of KFM's required sprites with the axes in indices labeled. There's 23 sprites, but the character I'm making only had these in the game:

Forgot to do this before, but now I horizontally flip all the sprites that were facing left in my rips (in PSP, Image-->Mirror), since they need to face to the right in the SFF file. Now take a look at spr.gif from the docs. Here's one of the sprites from it:

The three crosses on each of the sprites each denotes an axis, and the numbers next to them denote the sprite's group number and sprite number in the SFF file. The group number and sprite number -- or simply, index -- is used to define your character's animations. In the picture above, 5000,0 is the sprite used for the first frame of the animation played when KFM receives a normal "high" hit while standing. 5001,0 is actually a clone of this sprite that can be used by other characters to position KFM by his midsection when throwing him. And 5002,0 can be used by other characters to position KFM by his head when throwing him. So every one of these sprites (aside from the "hit while crouching" ones) is repeated three times in the SFF file with an axis for ground level, an axis for the character's midsection, and an axis for the character's head. Just as an example, Sagat would have to position his target (the character on the receiving end of an attack) by its head for his throw, like so:

Now I'm going to make all the required sprites I'll need for my character, using spr.gif as a reference. I'll just use the one hit-while-standing sprite I have for all of the top two rows ("hit high while standing" and "hit low while standing"), since I don't want to actually draw new sprites. And I'll use the one hit-while-crouching sprite for the third row ("hit while crouching"). For the remaining sprites, I'll just mirror/flip/rotate the sprites I have to most closely resemble Kung Fu Man's, since KFM is the standard in MUGEN (just Elecbyte's KFM, not that guy you'll see posting on forums ). Keep in mind that you can only rotate sprites by 90? unless you also want to do a lot of editing by hand, since using a non-right angle will result in anti-aliasing between the sprite and the background color. I save all of the images I'll need as a number that will tell me where to put it when I get to making the SFF file. So I start by saving the hit-while-standing sprite as 5000-X.pcx and also as 5010-X.pcx, since I'll use it for all 18 sprites in these groups. Then I save the hit-while-crouching sprite as 5020-X.pcx and so on until I have everything covered. Here's an image showing what I ended up with.

Part 4: Preparing a Character Palette with PSP goes over making your palette and finalizing the sprites.

[DavidGee]

• Part 1: Ripping from Windows Games with VMware Workstation
• Part 2: Cleaning Rips with PSP Scripts
• Part 3: Sprites that are Required for MUGEN Characters
• Part 4: Preparing a Character Palette with PSP
• Part 5: Making a Character SFF File with MCM
• Part 6: Making Character Animations with MCM
• Part 7: Making Collision Boxes with MCM
• Part 8: Squeezing out a Few More Sprites
• Part 9: Making a Character CMD File
• Part 10: Programming Basic Attacks

Part 4: Preparing a Character Palette with PSP

This is the fourth part of my character creation walkthrough, where I'll be walking through the entire process of making Sou, the playable character from Blade Warrior.

This article deals with making the character's palettes and finishing off the sprites to make them MUGEN-compatible.

Tools used: Paint Shop Pro, PAL2ACT

Before making an SFF file (the file that houses all of the sprites, palettes, and axes), you have to have a palette applied to your sprites. My sprites currently have a 24-bit color depth (16 million colors). But within MUGEN, they need to have an 8-bit color depth (256 colors). This may sound limiting if you're making a character with a lot of colors, but 256 colors is usually plenty.

Let's find out how many colors the character I'm making uses, though. In PSP, I make a new image and paste several sprites from different animations to be sure I have every color the character uses in the image (like so). Now from the menu, Image-->Decrease Color Depth-->256 Colors (8 bit). In the Decrease Color Depth dialog, I choose Optimized Median Cut and Nearest Color. This applies a palette to the image, whereas before it didn't have a palette, but could use any colors the computer is capable of displaying. After this, Image-->Count Colors Used yields a message box that says, "The number of unique colors used in this image is 28." This is the total number of colors that the character will be using. Image-->Palette-->Save Palette, and I save it as a PSP palette (never use the Microsoft option; I have no idea why it even exists).

If you've noticed the "transparency" commands, this has nothing to do with transparency in MUGEN. That's just for putting transparency in an image to use on a webpage or something. In MUGEN, it's a certain index in the palette that's used for transparency, and your graphics software isn't aware of this. In this case (working with a PSP palette), your first index has to reference the background color of your sprites so that this color is not visible in MUGEN. (Note that if you're using Photoshop or working with an ACT palette, it's the last index rather than the first. I don't use Photoshop since PSP meets all of my needs.) All I have to do is swap the first index with whichever index PSP happened to place my pure green background color in. Image-->Palette-->Edit Palette yields the Edit Palette dialog. I double-click on the first color, which happens to be pure black, to get the Color dialog for changing the color. I copy the text in the HTML box (screenshot), change it to pure green (the leftmost green color in the 8 by 6 color grid), and click OK. Now I double click the green that's in the middle of the palette and change it to color that was originally occupying the first index by pasting the HTML value I copied (screenshot). As you can see, the colors were swapped in the image. I save the palette overwriting the old one.

Now that I've got my palette ready to go, I start a script recording and do Image-->Palette-->Load Palette to apply the palette I saved with Nearest color matching. (The Maintain indexes option is used when you want to replace the image's existing palette with a new one using the same order of colors, which we don't want to do here -- this is how the different ACT palettes of a character work though. And the Error diffusion dithering option should probably never be used for anything. ) I save the script and run it on all the sprites and also convert to PCX in the process (screenshot, and how to do this has been covered in my previous articles). The reason why the sprites were still in BMP format is that PSP doesn't batch process the PCX format for some reason, but I'm finally done working with the images at this point, so I can kiss those huge BMPs goodbye, and the image I was working with can be discarded, although you may want to save it for palette editing purposes. Now when I open any of the images and access the Edit Palette dialog, it's clear that the palette has been applied.

Now I just use Elecbyte's PAL2ACT tool to convert the palette to the ACT format that MUGEN uses. I guess there are easier ways to do it, but PAL2ACT has served me well over the years. I just copy the PAL2ACT.EXE file to the folder where my palette is (My Documents\My PSP Files\Palettes in this case). Then, I right-click on a blank area in the explorer window to get the context menu and select New-->Text Document and save the file as pal2act.bat. This is the Batch File file type, which is just a text file that issues commands to a DOS program (or you could use a command prompt, but that is so 1980s). I open the .bat file in a text editor (Notepad will do, but I happen to use Notepad++ for all of this stuff). All you have to do is type pal2act <infile> <outfile> -- or pal2act bw.PspPalette bw1.act in this case, save the file, double-click on it in Explorer, and you've got your character's first palette (screenshot).

I'll go ahead and make three more palettes so players 2 through 4 won't be left out. Very easily done by opening one of the sprites in PSP and using the Hue Map tool (Adjust-->Hue and Saturation-->Hue Map) to make hue shifts. If you have a character with a more complicated palette, it's not going to be so easy, but this is just a guy with blue clothes and a blue lightsaber beamsword. Then I just save the new palettes and use PAL2ACT on them too. And in the .bat file, I can run the program as many times as I like.

pal2act bw2.PspPalette bw2.act
pal2act bw3.PspPalette bw3.act
pal2act bw4.PspPalette bw4.act

At this point, when applying your new palettes to sprites to see what they'll look like, you'll need to apply them with Maintain Indexes, of course.

I make the SFF file in Part 5: Making a Character SFF File with MCM.

[DavidGee]

• Part 1: Ripping from Windows Games with VMware Workstation
• Part 2: Cleaning Rips with PSP Scripts
• Part 3: Sprites that are Required for MUGEN Characters
• Part 4: Preparing a Character Palette with PSP
• Part 5: Making a Character SFF File with MCM
• Part 6: Making Character Animations with MCM
• Part 7: Making Collision Boxes with MCM
• Part 8: Squeezing out a Few More Sprites
• Part 9: Making a Character CMD File
• Part 10: Programming Basic Attacks

Part 5: Making a Character SFF File with MCM

This is the fifth part of my character creation walkthrough, where I'll be walking through the entire process of making Sou, the playable character from Blade Warrior.

This article deals with making the character's SFF file.

Tools used: Mugen Character Maker (the "mcm20b-dev3.56.zip" link  ), SFFextract, Sprmaker
Update: Fighter Factory is much better than Mugen Character Maker.

The SFF file is composed of all your sprites, their indices ,their axes, and their palettes (although you should only use one palette, aside from the large portrait). The sprites must be in PCX format with the proper palette applied (from the previous article). A sprite's index is a group number and a sprite number; these are used to reference the sprites in the animations (the AIR file). A sprite's axis is the point (x- and y-coordinate) that is used to position the sprite in MUGEN when it's used, and the animations may include offsets from this point (just making note of this; I'm not going to cover animation until a later article).

What I'll do to make the SFF file is simply modify KFM's by swapping in my sprites. Docs\spr.txt lists which group numbers you should use for which sprites, but I don't even have to worry about this since I can see just by opening kfm.sff in MCM (screenshot). All of MCM's buttons have tooltips when you hover the pointer over them, luckily enough, that tell you what the deuce they do. The first thing I'll do is click the Change palette button to load the ACT palette I made in the previous article. Since the KFM sprites don't have this palette applied, they appear in all white now. Group 0 is plainly used for the character's standing sprites. KFM has several of them that are played in a loop in MUGEN, but my character only has one frame for this action. So I can click the Delete sprite button to delete images 1 through 5 of this group. Now when I go back to 0,0 (group, image), I click the Change sprite button and load my stand.pcx to replace it. The sprite appears just as it did before, only minus the green background color since I have Transparency checked (screenshot). The axis has remained at 18,93, which isn't going to work since the axis for all but some of the get-hit sprites that were covered in a previous article need to be where the ground level is. So if I left the axes as they are, the character would be floating in the air in MUGEN. Note that MCM mysteriously crops sprites incorrectly sometimes (cropping off part of the sprite), so I never have Crop image checked when adding or changing a sprite.

I'll adjust the axes for these sprites later, but for now, I'm just concerned about getting all the sprites in. If your rips are made with a locked axis, you'd definitely want to make an SFF file from scratch rather than modifying KFM's and having to adjust axes. You'd actually want to not even use MCM at all in this case, but just pipe a text file into sprmaker. What I do now though is just work my way through KFM's SFF replacing sprites, removing extra sprites, and adding sprites when necessary. Group 5 and group 6 are for turning and crouch-turning; my character doesn't have those, and they're not necessary anyway, so I just delete them. Obviously, you'll need to have standing, crouching, walking, jumping, and guarding sprites unless you're using MUGEN for some evil purpose like a space shooter (this has been done, actually, although I don't think it's available any more). I delete the entire group of 21 (walking back), since I'll use group 20 (walking forward) for that animation. Oh and it's actually much faster to use Add sprite and add a range of sprites (select the first sprite in the range, and then select the last while holding the Shift key) if you'd rather do that than replace them one by one. Just make sure you type in the right group number in the Add image dialog (and the axis if you don't want it to be 0,0). That's what I do for all the attack sprites after deleting all of KFM's. Once I get to 5000,0, which is where all those required get-hit sprites start, I just replace them all easily, since I had the files named accordingly. Keep in mind that KFM actually has non-required sprites here to give his hit animations more frames. You can tell the difference because the sprite number of a required sprite always ends in 0. And also, the group numbers that end with 0 use ground level for the axis, the ones that end with 1 use midsection for the axis, and the ones that end with 2 use head for the axis. Ground level, midsection, head -- from the ground up, get it!? Once I get to the large portrait, I deselect Shared palette to add that in, since this image uses its own palette. Of course, I did have to edit the palette so that the first index referred to the background color, just like every other sprite. I had neglected to include a small portrait before, so I make one now.



It uses 91 colors after I decrease to 8-bit color depth. If I applied the palettes I'm using currently, it would look pretty bad, so I'll just add the colors it uses to my palettes. I always hold on to my PSP palettes for making these kinds of modifications, although you could simply edit the ACT palettes (this isn't very stylish, of course). A PSP palette is simply a text file that lists all of the colors by their RGB values (red, green, blue). So I just save the portrait's palette, open that in a text editor, copy all of the lines that aren't "255 255 255" (not used). Now I just open my original bw.PspPalette and paste all of these lines at the end. Then I just remove as many "255 255 255" lines as I need so that there's only 260 lines ("JASC-PAL", "0100", "256", then 256 lines for the colors, and then a blank line at the end) before saving it. The status bar of text editors generally tells you what line the cursor is in. Now I can apply this palette to the portrait in PSP with Nearest color matching and it looks the same as it did with the old palette, because the new palette has all of those colors (screenshot). In the screenshot, the first two rows are from the original palette I made in the last article, and then there is a bunch of indexes that refer to white (these aren't used), and then there are several rows for the portrait. I have to repeat the process of adding those colors with my character's other palettes, and then make new ACT palettes from them.

Now that I've got all the sprites in, I need to adjust the axes. All you have to do is grab the image by holding down the left mouse button, and then drag it to change the axis. I start by putting the axis for 0,0 right in the middle of the body and right on the bottom-most pixel of his foot (screenshot). Then I click the Fix Image button, which places a monotone copy of the sprite behind whichever sprite I'm at. So this way, I can align other sprites with the standing one (screenshot). You have to have all your sprites aligned to have smooth animation between actions. And the Onion skin feature will put the previous 1 through 3 sprites behind your current sprite; very useful for aligning the rest of a group after aligning its first image with the standing sprite, the crouching sprite, the jumping sprite, or some other sprite. A trick I use so that I can toggle between a particular sprite and a sprite I want to align with it is Clone sprite. When you click that button, you get a clone of the sprite you're at. Then you can fill in a new group number and/or sprite number to place it before a sprite and scroll back and forth between the two to judge the alignment. Then you can delete the clone, or move it somewhere else to use on another sprite.

Now, I have finished aligning the sprites, so I'm all done, right? Close, but not quite. Because I set the small portrait's palette type to individual rather than shared, and also made it compatible with the character's palettes (they get applied to it during a match whether you like it or not), the portraits work fine in MUGEN. There is just one sprite (the stand-to-crouch transition one) that has an individual palette and always shows up as blue. MCM is great for editing SFF files, but it's not without its faults. It doesn't save SFF files quite the same way as Elecbyte's Sprmaker. And also, WinMUGEN is picky about character SFF files. This is why you'll find a lot of characters that will have a messed up small portrait, among other things. To fix the problem, I used SFFextract to extract the sprites from my SFF file and also generate a text for piping through Sprmaker (command: sffextract -d -i -o sou.txt sou.sff). I then moved the small portrait to the top and gave the stand-to-crouch sprite a shared palette before piping the file through Sprmaker (command: sprmaker -c -f -p < sou.txt). To use these console programs, I used a batch file, which I covered in part 4 of this walkthrough.

The rest of this walkthrough will mostly be about the coding. So if you've never made a MUGEN character and you are here to learn how, I suggest that you download the SFF file and palettes, and code the character yourself along with me. I just noticed that the character's name is actually Sou, by the way.

Now that the SFF is finished, I'll go over making the animations in Part 6: Making Character Animations with MCM.

[DavidGee]

• Part 1: Ripping from Windows Games with VMware Workstation
• Part 2: Cleaning Rips with PSP Scripts
• Part 3: Sprites that are Required for MUGEN Characters
• Part 4: Preparing a Character Palette with PSP
• Part 5: Making a Character SFF File with MCM
• Part 6: Making Character Animations with MCM
• Part 7: Making Collision Boxes with MCM
• Part 8: Squeezing out a Few More Sprites
• Part 9: Making a Character CMD File
• Part 10: Programming Basic Attacks

Part 6: Making Character Animations with MCM

This is the sixth part of my character creation walkthrough, where I'll be walking through the entire process of making Sou, the playable character from Blade Warrior.

This article deals with making the character's actions.

Tools used: Mugen Character Maker (the "mcm20b-dev3.56.zip" link  )
Update: Fighter Factory is much better than Mugen Character Maker.

The AIR file contains all of the character's animations. It's a text file that defines the animations as a sequence of sprites from the SFF file. In an animation, which I'll refer to as an action from now on, each sprite, which I'll refer to as an element from now on, is displayed for a certain number of ticks, and there are 60 ticks per second. An element of an action may optionally include an offset from the sprite's axis as well (this is usually 0,0 -- or no offset). For full documentation on actions, see docs\air.txt. This article is focused on the steps I take to actually make my AIR file.

At this point, I'd like to go ahead and see my character in MUGEN now that I have the SFF file ready. So I take the following actions:

• Make a copy of the chars\kfm folder and name it sou, which is my character's name.
• Copy my SFF file and palettes to this folder.
• Delete kfm.sff, intro.def, intro.sff, ending.def, ending.sff, readme.txt, and all of KFM's ACT palettes.
• Rename the remaining files (kfm.def, kfm.cns, etc.) to sou.def, sou.cns, etc.
• Open sou.def in a text editor and then remove the heading about KFM, remove the [Arcade] section, and change all the parameters to the new filenames. You can actually name the files however you want, but the def file must have the same name as the folder, and it ends up looking like this:

Code

[Info]
name = "Sou"              ;Name of character
displayname = "Sou"       ;Name of character to display
versiondate = 04,14,2002  ;Version date of character (MM-DD-YYYY)
mugenversion = 04,14,2002 ;Version of M.U.G.E.N character works on
author = "DavidGee"       ;Character author name
pal.defaults = 1,2,3,4    ;Default palettes in order of preference
 
[Files]
cmd = sou.cmd ;Command set
cns = sou.cns ;Constants
st = sou.cns ;States
stcommon = common1.cns ;Common states
sprite = sou.sff ;Sprite
anim = sou.air ;Animation
sound = sou.snd ;Sound
pal1 = sou1.act
pal2 = sou2.act
pal3 = sou3.act
pal4 = sou4.act

So if you do this, and then add sou to your data\select.def, you can now actually play as Sou in MUGEN. Since he's still using KFM's coding for everything, though, nothing actually works correctly, of course. There's still a lot of work to do. Obviously from the article's title, the next thing to do is make the AIR file, which I'll do simply by modifying KFM's in MCM. Like I mentioned, the AIR file is a text file, but MCM provides a nice user interface for making them. Something I want to point out is that MCM was not made for Windows XP. On my XP system, it's sprite viewer doesn't repaint to the display unless I run it in Windows 95 compatability mode. You can do this by right-clicking it's icon in Explorer, selecting Properties, and choose Windows 95 in the Compatability tab.

First I have to load sou.sff, then sou.air, and then switch to the AIR tab since we are working with the AIR file now (screenshot). The blue boxes you see are collision boxes (Clsn2, specifically), which tell the engine what space is actually occupied by the character for this particular element. Obviously it's wrong at the moment since it's just KFM's, but I'll fix that later. For now, I'm just going to give each action the proper elements.

MCM's AIR editor is different from the SFF editor in that the SFF editor has a single scrollbar for scrolling through all the sprites, but the AIR editor has a scrollbar for scrolling through the actions (in the Actions section) and then another scrollbar for scrolling through the current action's elements (in the Frames section). I'm currently at the first element of action 0, which has 11 elements. If I scroll beyond the first element, the sprite viewer is blank since my character only had the one sprite in the group that these elements refer to. So I delete all the additional elements by clicking the Delete frame button in the Edit section. Under that, there's a textbox labeled with T, which is the ticks for this element. I change it from 10 to 1 since there will be no animation. Now if I save the file overwriting the original, when I run it in MUGEN, Sou never disappears while standing as he did most of the time before. Actions 5 and 6 show up blank as well since I don't have those sprites either, so I click the Delete Action button to delete those.

From docs\air.txt, action 10 is "stand to crouch," action 11 is "crouching," and action 12 is "crouch to stand." KFM has two elements for action 10 whereas I have 1, so I delete the second. Interestingly, KFM's SFF doesn't follow the recommended group numbers for these sprites, placing them all in group 11. Since in the Blade Warrior game, my character didn't actually have a "crouch to stand" transition, I delete action 12. Presently, the only element of action 11 refers to a sprite I don't have, so I have to replace it with the correct sprite. You do this by switching to the SFF tab, scrolling to the desired sprite (11,0 in this case), switching back to the AIR tab, and clicking the Change frame button (screenshot). Then I do the same to replace action 10's element with sprite 10,0. The walking action (20) contains some extra elements, so I delete those. For the walk back action (21), I can just replace the Group textbox's 21 value with 20 since I don't have separate walk back sprites. Conveniently, KFM's action 21 already went from end to beginning of the group's sprites. Now if I click the Play button in the Play section, I can see that the walk forward and walk backward actions appear to be opposite. I continue as I've already done for the rest of the standard actions using docs\air.txt as a reference for what actions will be doing what. Something that annoys me about MCM is that you can only add new actions to the end of your file, so to get around this, whenever I add actions, I open the file in a text editor, move the actions to where I want them to be, and reload the file in MCM. I decided to add optional actions 44 through 46 for coming down after jumping

How I decide the timings for the actions (the ticks for each element) is by opening in VirtualDub the original capture videos I made. The frame rate was 25 FPS (Video-->Frame Rate). All the walking sprites are displayed for 2 frames each (and sometimes 1) in the video, so I give all the elements of that action 4 frames each since MUGEN is 60 FPS. All the attack sprites are displayed for 1 frame each in the video, so they get 2 ticks. And so on and so forth.

When I get to the require get-hit actions, I have to change a lot of things around. KFM has some extra actions, and doesn't include some actions I want (like 5060: "air fall coming down", for example). I refer to docs\air.txt and to my sprites to make all of these animations as good as I can. And now that I've got all my actions set up, I use the character as a punching bag in training mode against several well-made characters to see how it looks when he gets hit with various attacks. If you spot anything that looks bad, you should make adjustments until it looks as good as it can. The only problem with Sou is that when he falls, he goes through the floor when landing, and it looks pretty ugly. Most small-sized characters that people release do the same thing, unfortunately... I remedy that by overriding some falling and landing states, but I'll talk about that in a later article.

Part 7: Making Collision Boxes with MCM finishes off the AIR file.

[DavidGee]

• Part 1: Ripping from Windows Games with VMware Workstation
• Part 2: Cleaning Rips with PSP Scripts
• Part 3: Sprites that are Required for MUGEN Characters
• Part 4: Preparing a Character Palette with PSP
• Part 5: Making a Character SFF File with MCM
• Part 6: Making Character Animations with MCM
• Part 7: Making Collision Boxes with MCM
• Part 8: Squeezing out a Few More Sprites
• Part 9: Making a Character CMD File
• Part 10: Programming Basic Attacks

Part 7: Making Collision Boxes with MCM

This is the seventh part of my character creation walkthrough, where I'll be walking through the entire process of making Sou, the playable character from Blade Warrior.

This article deals with giving the character's actions the proper collision boxes.

Tools used: Mugen Character Maker, Notepad++
Update: Fighter Factory is much better than Mugen Character Maker.

A collision box is a rectangle defined by an upper left point (x- and y-coordinate) and a lower right point (x- and y-coordinate). These points are relative to the character's axis in the action element. There's two kinds of collision boxes, Clsn1 and Clsn2. For Clsn2 boxes, the area within this rectangle is space that the character will occupy. (The actual sprites have no control over this.) For Clsn1 boxes, the area within this rectangle is space where an attack will hit if it makes contact with another character, so Clsn1s are only used in attack actions. For full documentation on this, see docs\air.txt. This article is focused on the steps I take to actually give my character's actions the proper collision boxes.

Elecbyte provides a tool with a user interface for editing AIR files (Airedit), but I've been unable to get the DOS version to run on my Windows XP system. It used to work fine in Windows 98SE. Luckily, MCM works fine on my system (if I run it in Windows 95 compatability mode). After loading my SFF and AIR file in MCM, my character still has KFM's clsn boxes for the actions where I replaced sprites, and no clsn boxes for actions where I added sprites. MCM has three modes for working with AIR files, Edit frame, Edit Clsn1 boxes, and Edit Clsn2 boxes.


Regardless of which mode you're in, dragging in the sprite viewer with your mouse's right button moves the sprite and its axis simply for getting the view you want. In the Edit frame mode, dragging in the sprite viewer with your mouse's left button changes the element's offset from the sprite's axis. There will be no reason for me to do this with any of my actions (so the X and Y boxes in the upper-right corner should always remain 0 and 0.) In the Edit Clsn1 boxes mode, dragging in the sprite viewer with your mouse's left button in an empty area lets you draw a new Clsn1 box. And if you hover your mouse over an existing Clsn1 box, you can either drag it to a new location by grabbing an edge, or change the location of a corner by grabbing that. To remove a Clsn1 box, simply hover over it and hit the Delete key on your keyboard. The Edit Clsn2 boxes mode is the same, only for Clsn2 boxes, of course. If you can't see the collision boxes, make sure you have Clsn1 and Clsn2 checked in the View options section.

I start with the only element of my action 0 (standing) by deleting the box that was for KFM's head and adjusting the remaining box for my character. 


One box is all that is necessary here. And if I had more than one frame for this action, they should all have the same Clsn2 box. You can do that by clicking the Use previous Clsn's button. Annoyingly, MCM doesn't tell you what a collision box's points are or allow you to copy them between actions. But that's something that you have to do so that your collision boxes are consistent. Otherwise, you'll have oddities like an attack not hitting when it should or would have had your character been in another action. (I think Airedit lets you keep boxes while changing to different actions to facilitate doing this, but it's been a long time since I've used that.) So I open the AIR file in Notepad++. Note that for MUGEN code files, I use its M$ INI file language. The INI file type is a configuration file that has groups with parameters exactly like all MUGEN config files and code files. To get syntax highlighing for your MUGEN files in Notepad++, select Style Configurator from the Language menu, select the M$ ini file tab, and put "def cns air cmd" in the User ext box (without the quotes). You can also change the colors and fonts to suit your tastes. This shows how the actual AIR file was changed using MCM's user interface to modify action 0:


"Clsn2: 2" has changed to "Clsn2: 1" because there is now 1 Clsn2 box instead of 2. Each Clsn2 box is defined by four comma-delimited numbers (x-coordinate of the upper-left point, y-coordinate of the upper-left point, x-coordinate of the lower-right point, and y-coordinate of the lower-right point) on a line starting with "Clsn2[<index>]", starting at 0. In MUGEN (and all graphics programming), the y-axis is the reverse of that from traditional mathematics, so going up from 0 is negative, and going down from 0 is positive. Each action element (frame of animation) is defined on a line after all of its collision boxes. It's defined in order by: group number of sprite, sprite number of sprite, x-coordinate of offset, y-coordinate of offset, and ticks.

At this point, I copy the text for the clsn2 box I made and replace all of the other ones in the AIR file with that one. This way, in MCM, I'll see what the basic clsn2 is in every action. I do this by selecting Replace... from the Search menu in Notepad++. In the Replace dialog, I check Regular expression, put "Clsn2\[0\].+=.+" in the Find what box (without the quotes), put my clsn2 box in the Replace what box ("Clsn2[0] = -20,-53, 17,  0" in this case), and press the Replace All button. A great resource for more about regular expressions is regular-expressions.info, but what this does is replace every first clsn2 box in the file with my "basic" one to use as a reference (remember what I said about consistent clsn2 boxes?). I then replace both "Clsn1: [0-9]" and "Clsn1\[[0-9]\].+=.+" with a blank to remove all Clsn1 boxes. And I also replace "Clsn2\[1\].+=.+", "Clsn2\[2\].+=.+", etc. with a blank to remove the clsn2 boxes remaining from KFM. I don't worry about changing all the "Clsn2: n"s to "Clsn2: 1", because reloading the file in MCM and then saving it will fix that. You always have to reload your file in MCM after having modified it in a text editor. Also, after you've saved it with MCM, when you go back to Notepad++, Notepad++ will have detected the change and ask you to reload the file (MCM doesn't detect changes like this). Before moving on to using MCM, I now just copy and paste the crouching clsn2 to my crouch-hit and crouch-attack actions, and likewise for the air ones. That's because I'll use those clsn2s instead of the standing clsn2 as references for those actions.

At this point, I go through the AIR file in MCM editing the Clsn2 boxes (finally!). Actions like walking, hit while standing, and such should have the same clsn2s as the standing action (consistency!). For pretty much any character, one or two -- maybe three -- clsn2s per element is almost always enough. You never want to do something like this:


Two more things to remember. One, for attacks, the first frame of the animation shouldn't have a clsn1. Otherwise it would have infinite priority. Two, clsn1s should have matching clsn2s so that the character can be hit while attacking. Otherwise the attack is somewhat invincible.

At this point, I've finished implementing all of my clsn boxes, so that concludes the AIR file. There's now two downloads for anyone interested in making the character along with me: the SFF file and palettes, and the AIR file. Part 8: Squeezing out a Few More Sprites just shows how I add my own air attacks and come up with a move list before touching the code.

[DavidGee]

• Part 1: Ripping from Windows Games with VMware Workstation
• Part 2: Cleaning Rips with PSP Scripts
• Part 3: Sprites that are Required for MUGEN Characters
• Part 4: Preparing a Character Palette with PSP
• Part 5: Making a Character SFF File with MCM
• Part 6: Making Character Animations with MCM
• Part 7: Making Collision Boxes with MCM
• Part 8: Squeezing out a Few More Sprites
• Part 9: Making a Character CMD File
• Part 10: Programming Basic Attacks

Part 8: Squeezing out a Few More Sprites

This is the eighth part of my character creation walkthrough, where I'll be walking through the entire process of making Sou, the playable character from Blade Warrior.

This article is just kind of a tangent from the walkthrough where I add some more attack sprites before starting the actual coding.

Tools used: Paint Shop Pro, FastStone Image Viewer

I've got all my sprites and actions from the original game set up, but it's just not enough for me. The game I ripped from was just your standard side-scrolling beat-'em-up, and the character only had a few standing slashes, a couple air slashes, and a crouching slash -- no throws or anything else.? If I made a straight, accurate conversion, we'd have a pretty boring character, so I'm going to examine my sprite base and see how I can further expand its utility beyond what was in the game.

I decided to actually do some sprite edits to make all of Sou's ground slashes into air slashes as well, and the two original air slashes will just be used for special attacks. So that I won't have to worry about adjusting the axes again, I take all of these slashing sprites and make a new layered image with them in PSP. I copy each image, Paste as Transparent Selection, and position the sprite before making it a layer by selecting Promote Selection to Layer from the Selection menu (screenshot). Now I have every frame in one image that I can save as a .pspimage file and come back to later if I want to. To work with a particular layer, you have to have that layer selected by clicking on it in the Layer Palette (View-->Palettes-->Layers if it's not there). Whichever layer is selected is highlighted with blue, and you can click the eyeball icon (Visibility Toggle) to hide or show a particular layer. All I do is copy and paste legs from an air slash over the legs in the ground slash, like this:



Might look a little funky, but oh well, it works well enough. And after saving the sprites individually, I then just add the sprites to the SFF file, and then make actions from them like I already did with the existing sprites. So now I have this move list in mind to implement before I've touched any code:

X - forward slash
Y - cross slash
Z - lunging slash
air X - forward slash
air Y - cross slash
air Z - lunging slash
crouching X/Y/Z - crouching slash (would have looked too weird to add more croushing slashes)
close X/Y/Z - throw using Sou's fourth ground slash where he slashes upward
f,d,df + X/Y/Z - dragon punch type attack using one of the original air slashes
qcf + X/Y/Z - a slash where Sou actually lunges forward
air qcf + X/Y/Z - downward air attack with the other original air slash

So this article wasn't much of a tutorial. I had to stick it in here somewhere though, since I'm covering the whole process. The CMD file is covered in Part 9: Making a Character CMD File.

[DavidGee]

• Part 1: Ripping from Windows Games with VMware Workstation
• Part 2: Cleaning Rips with PSP Scripts
• Part 3: Sprites that are Required for MUGEN Characters
• Part 4: Preparing a Character Palette with PSP
• Part 5: Making a Character SFF File with MCM
• Part 6: Making Character Animations with MCM
• Part 7: Making Collision Boxes with MCM
• Part 8: Squeezing out a Few More Sprites
• Part 9: Making a Character CMD File
• Part 10: Programming Basic Attacks

Part 9: Making a Character CMD File

This is the ninth part of my character creation walkthrough, where I'll be walking through the entire process of making Sou, the playable character from Blade Warrior.

This article deals with making the CMD file, which processes player input.

Tools used: Notepad++

Now that I finally have all my sprites and actions, I can start working with the code. What I'll do is simply modify KFM's code, which is the best thing to do if you don't have experience making characters. The player constants (at the top of the CNS file) can mostly remain the same as KFM's, but don't let them all remain the same; that's a rookie mistake. These are the ones I change for Sou:

• data.liedown.time - Changed from 60 to 20 since one second is a pretty long time.
• size.ground.back and size.ground.front - You need to change these for every character. They should define the width of your character, not the width of KFM. Their purpose is for "pushing", or actually keeping other characters on the outside of your character, which clsn2 doesn't do. These values should be the same as your standing clsn2. From [Begin Action 0] in the AIR file, I have Clsn2[0] = -20,-53, 17,? 0. So I make ground.back = 20 and ground.front = 17.
• size.air.back and size.air.front - the same as the above, except for when the character is in the air. For Sou, his air clsn2 has the same width as his ground one, so I also make air.back = 20 and air.front = 17. If you don't set the back and front values right, you'll have ugly looking pushing behavior.
• size.height - Sou's height, from action 0, is 53, so I make size.height = 53.
• size.head.pos and size.mid.pos - I don't think these are commonly used for anything, but still, they should be set correctly. I get the values by positioning the standing action element's offset over the spot in MCM (screenshot). I make head.pos = 1,-55 (from the screenshot) and mid.pos = -1,-34.
• velocity.<whatever> and movement.<whatever> - These I'm not going to worry about now, but they will be adjusted to my liking as I make the character. If you're making an accurate conversion, there are techniques to get these values correctly.

I lumped the constants into this article about the CMD file, since I'm only giving that much explanation. But now that I've done that, it's time to make the CMD file. The CMD file is pretty simple (for a basic character, anyway). It just contains the commands that the character can execute and instructions for what happens when the character executes those commands. The above post has a pretty good description (from kfm.cmd) of what command strings mean to the engine. What I do is simply remove the extra commands from KFM, and put in all the commands I decided on using in the previous article. For a command that can be executed in multiple ways, you can give them the same name, like this:

Code

[Command]
name = "crouching_slash"
command = /$D,x ;press x when holding down, down-back, or down-forward
time = 1
 
[Command]
name = "crouching_slash"
command = /$D,y
time = 1
 
[Command]
name = "crouching_slash"
command = /$D,z
time = 1

A command's name is what's used to reference it in the CNS coding. And speaking of CNS coding, that's what I have to do now that I've got all the commands defined. Scrolling down past the commands to the "state entry" section in kfm.cmd, you'll see a line containing only [Statedef -1]. Everything below this line in the file is actually a state (state -1, of course). A state is a series of instructions (state controllers, or sctrls) that the engine evaluates whenever the character is "in" that state. For example, when the character's standing, he's in state 0, when he's crouching, he's in state 11, and he's in some other state for anything else he does. State -1 is actually a special state that the character is always in, and it's used for processing player commands. It's also commonly used for combo systems and custom AI systems, but that's beyond the scope of this article. In every tick of the game, the sctrls of state -1 are executed, then the sctrls of state -2 and -3 are executed if applicable, and then the sctrls of the character's actual state (like state 0 if he's standing) are executed. In a state, an sctrl is defined by an entry under the statedef line that looks like this:

Code

[State -1, Smash Kung Fu Upper]
type = ChangeState
value = 3050
triggerall = command = "SmashKFUpper"
triggerall = power >= 1000
triggerall = statetype != A
trigger1 = ctrl
trigger2 = hitdefattr = SC, NA, SA, HA
trigger2 = stateno != [3050,3100)
trigger2 = movecontact

That's the first sctrl in kfm.cmd. All you actually have to have for the first line is [State <anything>,<anything>] or [State <anything>] . There's two reasons why they have [State -1, Smash Kung Fu Upper]. First, so that the coder remembers what the sctrl is for, and second, for error messages. If I changed the sctrl so that it doesn't have correct syntax, MUGEN would give an error message like this telling me exactly what the problem is when attempting to load the character.

There's tons of available sctrls to use in MUGEN (see docs\sctrls.html for the list), giving you a great deal of control over your character's behavior. That's why it's so complicated, and that's why it takes so much practice to get comfortable with it. That's also why it takes so much time to make a good character. Here, we are only concerned about the ChangeState sctrl type.

------------------------------------------------------------
ChangeState
------------------------------------------------------------

Changes the state number of the player.

Required parameters:
  value = state_no (int)
    state_no is the number of the state to change to.

Optional parameters:
  ctrl = ctrl_flag (int)
    ctrl_flag is the value to set the player's control
    flag to. 0 for no control, nonzero for control.

  anim = anim_no (int)
    This is the action number to switch to. If omitted,
    the player's animation will remain unchanged.

Example:
  ; Change to standing state, and give player control
  type = ChangeState
  value = 0
  ctrl = 1

Every sctrl has required parameters that you must define, and also optional parameters that you can define if necessary. In addition to defining those parameters, you also have to define one or more triggers. A trigger parameter's value is an expression that can be evaluated either true or false. And MUGEN provides a great deal of "triggers" (which would better be referred to simply as functions) to use in trigger expressions (see docs\trigger.html for the list). Here is a flow chart showing how the Smash Kung Fu Upper sctrl from above gets interpreted in MUGEN:

Click here to view the diagram.
 
So there are only two possible outcomes:

True:

Change to state 3050, or in other words, perform the Smash Kung Fu Upper attack. This result can only be reached if all of the triggeralls were evaluated as true, and in addition, either (A) the trigger1 was evaluated to true, or (B) all of the trigger2s were evaluated to true. If this is the result, all of the remaining sctrls in state -1 are not evaluated, so you have to be careful about the order in which you place them. For example, if I had a basic attack where the command is "x" placed above the Smash Kung Fu Upper sctrl, the Smash Kung Fu Upper sctrl would never be evaluated, and therefore the character would not be able to perform that attack (he would end up doing the basic attack whenever the command was entered).

False:

Continue evaluating the remaining sctrls. This is the result reached if true wasn't reached. The ChangeState is not tiggered, and evaluation continues to the next sctrl of the state.

It's necessary to understand this kind of logic to code MUGEN characters. People already familiar with programming won't have much of a problem there, but others may have some difficulty if they lack exposure to the internal workings of computer software. Anyway, what I do to make Sou's state -1 is first come up with a list of attack states and the state numbers I'll use for them.

• 200, standing light slash
• 210, standing medium slash
• 220, standing strong slash
• 400, crouching slash
• 600, jumping light slash
• 610, jumping medium slash
• 620, jumping strong slash
• 800, throw
• 1000, light uppercut special
• 1010, medium uppercut special
• 1020, strong uppercut special
• 1100, light thrusting special
• 1110, medium thrusting special
• 1120, strong thrusting special
• 1200, light air special
• 1210, medium air slash special
• 1220, strong air special

Some of these attacks will require more than one state, which is why I leave a lot of room for more states between each attack, and it's also a good idea to group states by their type (2XX for standing basic punches, 4XX for crouching basic punches, etc.). Now, I simply add the necessary ChangeState sctrls to my state -1 to finish sou.cmd. You can use kfm.cmd as a reference or base, of course. I actually removed all of KFM's sctrls except for these, so that Sou can run:

Code

[State -1, Run Fwd]
type = ChangeState
value = 100
trigger1 = Command = "FF"
trigger1 = StateType = S
trigger1 = ctrl
 
[State -1, Run Back]
type = ChangeState
value = 105
trigger1 = Command = "BB"
trigger1 = StateType = S
trigger1 = ctrl

All of my sctrls looks like this:

Code

[State -1, standing medium slash]
type = ChangeState
value = 210

And of course, they are in proper order to avoid "hiding" certain attacks (specials at the top, and basics at the bottom). The one above triggers when the player presses y while standing and with control ("control" means that the player has control; he doesn't have control during a hit pause, during a throw, and such). The only one of my sctrls that has an additional trigger is this one:

Code

[State -1, throw]
type = ChangeState
value = 800
triggerall = Command = "throw"
trigger1 = StateType = S
trigger1 = P2BodyDist X < 1
trigger1 = ctrl

The P2BodyDist X < 1 expression means that the opponent (refered to as "p2") is within a pixel to the front of the player. So this ChangeState is only triggered when Sou is right next to his opponent.

Well that concludes Sou's preliminary CMD file. It uses pretty inefficient coding, because I want it to be as understandable as possible. Normally, I would condense the whole thing down to not more than a few sctrls, but to do so would require advanced coding techniques. Next is Part 10: Programming Basic Attacks.

Downloads: sou_sff_act.rar, sou.air, sou.cmd

[DavidGee]

• Part 1: Ripping from Windows Games with VMware Workstation
• Part 2: Cleaning Rips with PSP Scripts
• Part 3: Sprites that are Required for MUGEN Characters
• Part 4: Preparing a Character Palette with PSP
• Part 5: Making a Character SFF File with MCM
• Part 6: Making Character Animations with MCM
• Part 7: Making Collision Boxes with MCM
• Part 8: Squeezing out a Few More Sprites
• Part 9: Making a Character CMD File
• Part 10: Programming Basic Attacks

Part 10: Programming Basic Attacks

This is the tenth part of my character creation walkthrough, where I'll be walking through the entire process of making Sou, the playable character from Blade Warrior.

Tools used: Notepad++

This article deals with programming basic attacks, and just to recap what I've done up to this point, here's a checklist of all the character files:

• sou.def - Definition.
  
• sou.sff - Sprites.
  
• sou.air - Animation.
  
• sou1.act, sou2.act, sou3.act, sou4.act - Palettes.
  
• sou.snd - Sounds.
  
• sou.cmd - Commands, State -1.
  
• sou.cns - Constants, other states.

As for sou.snd, I'll just record a few sounds from the game using GoldWave and put the SND file together using SouNDs Good (see here for links). The SND file has group numbers and sound numbers for referencing sounds (which are in WAV format) in the coding just as the SFF file. (Thought I'd mention that somewhere in this thing.) And that just leaves sou.cns. Before going on to coding a character, you should have an understanding of how the CMD file works (see the previous article if you don't). Also, the player constants were covered in the previous article.

The CMD file had State -1 for processing player input, and the CNS file will have all the other states (aside from states that are common to all characters, which are contained in data\common1.cns). These states are defined the same way as State -1 with a [Statedef <stateno>] line followed by the sctrls, which is short for "state controllers." In every tick of the game, all of the sctrls of whatever state the character is in are executed in order from first to last by MUGEN. Although you don't do this for State -1, states have optional parameters that are defined before the sctrls, like this:

Code

[Statedef 200]
type = S     ; this is a standing state
movetype = A ; this state is an attack
physics = S  ; this state has standing physics
anim = 200   ; this state plays action 200
; there can be more parameters defined if necessary
 
[State 200, 1]
type = Null
trigger1 = 0

When the character enters state 200 here via a ChangeState in State -1, MUGEN sets the Statedef parameters as I defined them. So, the character is now standing, the character is able to execute an attack, the character now uses standing physics, and the character's action is changed to 200. You usually have to set all of these for each state, and there are other parameters that you can set optionally (see docs\cns.html for the list and other documentation). And then, now that the character's in state 200, my Null sctrl is evaluated every tick (that's 60 times per second). The Null sctrl is just an sctrl that does nothing when triggered, and since trigger1 = 0, it actually never triggers, since it's always evaluated to false. If I wanted it to be evaluated as true, I could make trigger1 = 1, but it still wouldn't do anything. The only reason I have it here now is that every state has to have at least one sctrl, and every sctrl has to have at least one trigger (MUGEN will give you an explanatory error otherwise). The null sctrl is good for disabling an existing sctrl. For example, you can change 'type = ChangeState' to 'type = null ;ChangeState' to "turn off" the sctrl. Everything after the semicolon on a line is a comment, which is ignored by MUGEN, if you haven't noticed.

At this point, what I'll do is make statedefs for each one of my attack states. I just type out a template like this:

Code

;------------------------------------------------------------------------------
[Statedef XXXX];                       name
;------------------------------------------------------------------------------
type = 
movetype = A
physics = 
anim = 
juggle = 5
poweradd = 20
ctrl = 0
sprpriority = 2
 
[State XXXX, PlaySnd]
type = null ;PlaySnd
trigger1 = Time = 0
value = 0,0
 
[State XXXX, HitDef]
type = HitDef
trigger1 = Time = 0
attr = ,
hitflag = MAF
guardflag = MAF
;animtype = Light
;air.animtype = Light
;fall.animtype = Back
;priority = 4,Hit
;damage = 0,0
;pausetime = 0,0
;guard.pausetime = 0,0
;sparkno = 
;guard.sparkno = 
;sparkxy = 0,0
;hitsound = 
;guardsound = 
;ground.type = High
;air.type = High
;ground.slidetime = 0
;guard.slidetime = 0
;ground.hittime = 0
;guard.hittime = 0
;air.hittime = 20
;guard.ctrltime = 0
;guard.dist = 
;yaccel = 0
;ground.velocity = 0,0
;guard.velocity = 0,0
;air.velocity = 0,0
;airguard.velocity = 0,0
;ground.cornerpush.veloff = 
;air.cornerpush.veloff = 
;down.cornerpush.veloff = 
;guard.cornerpush.veloff = 
;airguard.cornerpush.veloff = 
;airguard.ctrltime = 0
;air.juggle = 0
;fall = 
;fall.xvelocity = 
;fall.yvelocity = -4.5
;fall.recover = 1
;fall.recovertime = 4
;fall.damage = 0
;air.fall = 
 
[State XXXX, ChangeState]
type = ChangeState
trigger1 = AnimTime = 0
value = 0

• I make movetype = A, which is necessary so that the attack can hit the opponent.
• I make ctrl = 0 so that the character can't do another attack while doing an attack (ctrl = 1 is a trigger for all of my ChangeStates in sou.cmd).
• I make sprpriority = 2 so that the character will appear in front of the character he's attacking.
• The other statedef parameters will vary for different attacks, but will always need to be defined.
• I know that every attack will need a HitDef sctrl, and the trigger for that will generally be Time = 0 (triggers when the state is entered). I also include the commonly used HitDef parameters (with the optional ones commented out), since these will vary for different attacks. I used MEE to insert those, and the ones that already have parameters are using the default values that MUGEN assumes if there is no value defined.
• Every attack will also need a ChangeState sctrl to end the attack, and the trigger for that will generally be AnimTime = 0 (triggers when the action has finished playing).
• I also include a disabled PlaySnd sctrl because the attacks will all need to play a slashing sound effect that I don't have yet.

Now I just copy and paste my template 17 times for each attack I decided on having in the previous article. And then I just go through the file and type everything in. Here's a couple examples:

Code

;------------------------------------------------------------------------------
[Statedef 200];                   standing light slash
;------------------------------------------------------------------------------
type = S
movetype = A
physics = S
anim = 200
juggle = 5
poweradd = 20
ctrl = 0
sprpriority = 2
 
[State 200, PlaySnd]
type = null ;PlaySnd
trigger1 = Time = 0
value = 0,0
 
[State 200, HitDef]
type = HitDef
trigger1 = Time = 0
attr = S, NA
hitflag = MAF
guardflag = MAF
; (snipped optional HitDef parameters)
 
[State 200, ChangeState]
type = ChangeState
trigger1 = AnimTime = 0
value = 0

Code

;------------------------------------------------------------------------------
[Statedef 600];                  jumping light slash
;------------------------------------------------------------------------------
type = A
movetype = A
physics = A
anim = 600
juggle = 5
poweradd = 20
ctrl = 0
sprpriority = 2
 
[State 600, PlaySnd]
type = null ;PlaySnd
trigger1 = Time = 0
value = 0,0
 
[State 600, HitDef]
type = HitDef
trigger1 = Time = 0
attr = A, NA
hitflag = MAF
guardflag = MAF
; (snipped optional HitDef parameters)
 
[State 600, ChangeState]
type = ChangeState
trigger1 = AnimTime = 0
value = 50

When a ChangeState sctrl is triggered, as I explained in the previous article, the change is immediate and the remaining sctrls of that state don't get evaluated because the character is now in a different state. Every other sctrl in MUGEN (aside from SelfState) doesn't have that effect, because no change in state gets made. The most important sctrl in MUGEN is HitDef. What it does, of course, is define a hit. When a HitDef is triggered, it becomes "activated." A character can only have one active HitDef at a time (projectiles and helpers have their own HitDefs, though). Whenever one of the character's clsn1s overlaps another character's clsn2 while he is in an attack-type state (movetype = A) and while he has an active HitDef, then the hit defined by that HitDef is exectued, and thus the opponent gets hit. No single sctrl has as many parameters as HitDef, and all those parameters let you define exactly what happens to the opponent when he receives the hit. You can read the HitDef entry in docs\sctrls.html for an explanation of each parameter.

For the HitDef of Sou's standing light slash, I make attr = S, NA, which means "standing, normal attack." I make hitflag = MAF, which means that the hit can be executed on standing, crouching, jumping, or falling characters. I use that same value for guardflag as well. These (and several others) are parameters that should be defined for every hit. Like for Sou's crouching slash, I make attr = C, NA, because it's a different type of hit.

For Sou, I'm using Time = 0 as the only trigger for his basic HitDefs. Although the HitDef becomes activated on the tick that Sou enters an attack state, it can't be executed on an opponent until he has a clsn1, which doesn't happen until the middle of his attack actions. That is pretty much standard for MUGEN characters. Anyway, unlike Sou, some characters will have basic attacks that can hit twice. In that case, you'd use two triggers if both of the hits should have the same effect, and AnimElem is a good function for that. For example:

Code

[State blah, blah]
type = HitDef
trigger1 = Time = 0
trigger2 = AnimElem = 3

There, the HitDef would be reactivated on the first tick of the third element of the action, so it could hit the same opponent twice. You could also have any number of trigger2s, trigger3s, and so on as well. A triggerall is like a gateway to the actual triggers, as no trigger will be evaluated unless all of the triggeralls were true. If you have, say, 3 lines for trigger1, all 3 lines get evaluated separately, and evaluation jumps to trigger2 (or to the next sctrl if there is no trigger2) when a trigger1 is false. So if you had:

Code

[State blah, blah]
type = Null
triggerall = Time
trigger1 = 1
trigger1 = 0
trigger1 = 1
trigger2 = 1
trigger3 = 0
trigger4 = 1

The Time trigger represents the number of ticks that have passed since the state has been entered. Hopefully it's not too confusing that a value-returning function like Time is referred to as a "trigger" when a trigger could actually be some big expression like ((Vel Y > 0) && (Pos Y > 0)) || Time = 5, but I always thought it was stupid. You'll just have to know the difference. The triggerall is true, assuming that Time isn't 0 (0 is interpreted as false, and any nonzero value is interpreted as true). And the first trigger1 is true, but the second trigger1 is false, and so the third trigger1 is never evaluated. But then the trigger2 is evaluated, and the sctrl is triggered since it's true. Trigger3 and trigger4 don't get evaluated since the sctrl has already been triggered.

Well, I guess that should do it for basic attacks... I haven't actually coded them all, since it takes a lot of time playtesting and adjusting accordingly to get them working how I want. One thing I know for sure is that I'll only give the opponent (not Sou) a hitpause for the slash attacks, because the sword needs to keep moving or else it will look really ugly. I'll get to more advanced attacks in the next article, which is "coming soon."

EDIT: No, actually, the next article is never coming! Muahahahaha!!!!