Jump to content

[ CLASS CC1 ] ~ Characters: Creation 1 (Beginner)


RobotMonkeyHead

Recommended Posts

--- Sophmore Course

CLASS 5 ~ Stage Creation:  Core Concepts

CLASS 6 ~ Stage Creation:  Beginner

CLASS 7 ~ Character Creation:  Core Concepts
CLASS 8 ~ Character Creation:  Beginner


Yay!  You made it across the moat!  Fresh meat for the grinder!
:relax:










They should work.

------------------------------------------------------
MISSION: CHARACTER CODING

REQUIREMENTS: GRAPHICS
------------------------------------------------------

 

__________/ TABLE OF CONTENTS DEPTH 1

LEVEL 1 - How Mugen Works
LEVEL 2 - Common Code
LEVEL 3 - Commands
LEVEL 4 - First Attack
LEVEL 5 - Types of Attacks
LEVEL 6 - Helpers and Strikers
LEVEL 7 - Technical
LEVEL 8 - Finishing Touches
LEVEL 9 - Wrapping Up

 

__________/ TABLE OF CONTENTS DEPTH 2

LEVEL 1 - How Mugen Works
 - STAGE 1. Mugens General Flow of Code
 - STAGE 2. Introduction to StateDefs
 - STAGE 3. Introduction to State Controllers

LEVEL 2 - Common Code
 - STAGE 1. Common State Controllers
 - STAGE 2. Common Statedef Details
 - STAGE 3. Common States

LEVEL 3 - Loading Sprites
 - STAGE 1. Preparing Sprites
 - STAGE 2.  
 - STAGE 3. Loading

 


LEVEL 3 - Commands
 - STAGE 1. Overview
 - STAGE 2. Specifying Commands
 - STAGE 3. Applying Commands

LEVEL 4 - First Attack
 - STAGE 1. Attack States
 - STAGE 2. HitDef State Controllers
 - STAGE 3. Considering the Context

LEVEL 5 - Types of Attacks
 - STAGE 1. Basics
 - STAGE 2. Specials
 - STAGE 3. Hypers

LEVEL 6 - Helpers and Strikers
 - STAGE 1. Helpers
 - STAGE 2. Strikers
 - STAGE 3. Alternate Uses

LEVEL 7 - Technical
 - STAGE 1. Common Technical Moves
 - STAGE 2. Throws
 - STAGE 3. Parry / Alpha Counter

LEVEL 8 - Finishing Touches
 - STAGE 1. Intros
 - STAGE 2. Win, Lose, Draw
 - STAGE 3. Taunt

LEVEL 9 - Wrapping Up
 - STAGE 1. Portraits
 - STAGE 2. Intros & Endings
 - STAGE 3. Release Advice

 

 

_____/ LEVEL 1 - How Mugen Works

STAGE 1. Mugens General Flow of Code
         - Processing
         - Ticks
         - Code chunks

STAGE 2. Introduction to StateDefs
         - Basic description
         - Normal States
         - Changing States
         - Negative States

STAGE 3. Introduction to State Controllers
         - Basic description
         - Triggers (time, animelem)
         - ChangeState

 

_____/ LEVEL 2 - Common Code

STAGE 1. Common State Controllers
         - PosAdd / PosSet
         - VelAdd / VelSet

STAGE 2. Common Statedef Details
         - Type
         - Movetype
         - Physics
         - Anim

STAGE 3. Common States
         - Standing
         - Walking
         - Crouching
         - Jumping

 

_____/ LEVEL 3 - Commands

STAGE 1. Overview
         - .cmd File
         - Input
         - Ghost Keys

STAGE 2. Specifying Commands
         - Command Name
         - Command Symbols
         - Command Defaults

STAGE 3. Applying Commands
         - State -1
         - Triggering State Change
         - Ctrl / State Type
         - Canceling

 


_____/ LEVEL 4 - First Attack

STAGE 1. Attack States
         - Movetype
         - Clsn boxes

STAGE 2. HitDef State Controllers
         - triggering
         - Attr
         - Hitflag, guardflag
         - Variable defaulting

STAGE 3. Considering the Context
         - Fairness
         - Frame Advantage
         - Priority
         - Infinites

 

_____/ LEVEL 5 - Types of Attacks

STAGE 1. Basics
         - Standing
         - Crouching
         - Ariel

STAGE 2. Specials
         - Projectiles
         - Charging
         - Full Screen / Ground Hits
         - Explods

STAGE 3. Hypers
         - Hyper BG
         - Superpause
         - Power Meter
         - Multiple Hits

 

_____/ LEVEL 6 - Helpers and Strikers

STAGE 1. Helpers
         - How they Work
         - State Controller
         - Some Possible Uses

STAGE 2. Strikers
         - Initiating (command, trigger, etc)
         - Relationship to Triggers (target etc)
         - Interacting with Players

STAGE 3. Alternate Uses
         - Items / Objects
         - Clsn Boxes
         - Data Storage

 

_____/ LEVEL 7 - Technical

STAGE 1. Common Technical Moves
         - Dash
         - Roll Recover
         - Wall Jump / Double Jump

STAGE 2. Throws
         - Custom States
         - Target Binding
         - Avoiding Pitfalls
         - Tech Escape

STAGE 3. Parry / Alpha Counter
         - NotHitBy
         - HitRedirect

 

_____/ LEVEL 8 - Finishing Touches

STAGE 1. Intros
         - Designing / Labeling
         - Triggering
         - Round States  
         - Custom Intros    

STAGE 2. Win, Lose, Draw
         - Designing / Labeling
         - Triggering

STAGE 3. Taunt
         - Designing / Labeling
         - Triggering
         - Alternate Taunts
         - Custom Taunts

 

_____/ LEVEL 9 - Wrapping Up

STAGE 1. Portraits
     - Large Portrait
     - Small Portrait
     - Custom Portraits, Per SP
     - Hyper Portraits

STAGE 2. Intros & Endings
     - Def File
     - Storyboard Overview
     - Redirection to Storyboard Mission

STAGE 3. Release Advice
     - Hosting
     - Forum Etiquette
     - Feedback

 

Link to comment
Share on other sites

_____/ LEVEL 1 - How Mugen Works
   Imagine all of a characters code laid out in a single text file.  All of that code breaks up into separate chunks called States.  Every State has a number that defines it, and that number is called the State Def.  Your character is only ever in one State at a time.  At some point, something in the State will tell your character to change to a different State number.  This is basically how your character's behavior is determined.  Here's what a State looks like:

; Stand
[Statedef 0]
type = S
physics = S
sprpriority = 0

[State 0, 1]
type = ChangeAnim
trigger1 = Anim != 0 && Anim != 5
trigger2 = Anim = 5 && AnimTime = 0 ;Turn anim over
value = 0

[State 0, 2]
type = VelSet
trigger1 = Time = 0
y = 0

[State 0, 3] ;Stop moving if low velocity or 4 ticks pass
type = VelSet
trigger1 = abs(vel x) < Const(movement.stand.friction.threshold)
trigger2 = Time = 4
x = 0

[State 0, 4] ;Are you dead?
type = ChangeState
trigger1 = !alive
value = 5050
ctrl = 0
 
   As you can see, the code inside a single State breaks up into smaller chunks.  These chunks are called State Controller (sometimes abbreviated Sctrls).  Each State Controller performs a specific task.  For example the thing inside a state that tells your character to change to another state is a State Controller.  Another State Controller might cause your characters position on the screen to change, or one might change the animation they're running, and another might make the screen shake.  Basically every individual thing your character does is caused by a State Controller.  Here's what one looks like on its own:

[State 0, Personal notes or a number]
type = ChangeState
trigger1 = time > 5
value = 20    

   Each State Controller has a trigger.  The trigger is basically an equation that turns out to be either true or false.  If it's true, the State Controller does its thing.  If it's false, the State Controller does nothing.  For example, if a State Controller had a trigger that was "2 + 2 = 5", that state controller would never do anything.  If it was "2 + 2 = 4" it would always preform its task.  If the trigger was "time >= 10" it would only perform it's task after 10 Ticks had passed since your character entered their current state.  

    When Mugen is running during a match, the way it handles all that is actually pretty simple.  It runs 60 loops or "Ticks" per second.  On each loop it jumps to the State your character is currently in and checks every State Controller in that state in order.  For each State Controller, it checks the trigger to see if it's true, and if it is, the State Controller "activates", meaning it does its thing.  Once Mugen is finished with all the State Controllers in your characters state, it does the same thing for the opponent.  That's assuming you're P1 of course.  It's pretty much that simple.  Let's take another look at the original example.  It's an example of a Kung Fu Mans standing state:

; Stand
[Statedef 0]
type = S
physics = S
sprpriority = 0

[State 0, 1]
type = ChangeAnim
trigger1 = Anim != 0 && Anim != 5
trigger2 = Anim = 5 && AnimTime = 0 ;Turn anim over
value = 0

[State 0, 2]
type = VelSet
trigger1 = Time = 0
y = 0

[State 0, 3] ;Stop moving if low velocity or 4 ticks pass
type = VelSet
trigger1 = abs(vel x) < Const(movement.stand.friction.threshold)
trigger2 = Time = 4
x = 0

[State 0, 4] ;Are you dead?
type = ChangeState
trigger1 = !alive
value = 5050
ctrl = 0

    Here you can see the State Def up top, followed by four State Controllers.  Each State Controller has a "type" which tells Mugen what task that state controller will preform.  Below the type is the trigger.  Each trigger is numbered, and it's common for a State Controller to have multiple triggers.  If all the triggers with the same number are true, the State Controller will carry out its task.  So if there's multiple trigger1's and multiple trigger2's, then either all of the trigger1's or all of the trigger2's would have to be true for it to activate.  There's also triggerall's which apply to all numbers.

    After the type and triggers, there are the Variables that will be set if the triggers activate it.  What Variables there are depends on the State Controller type.  For example, if "type = VelSet" as seen above (short for Velocity Set), the only Variables it can set are X and Y.  These change the characters velocity on the X and Y axis.  If the type were ChangeState, the only variable would be "value" which would be the number of the state to change to.  Also notice up top that the State Def itself has some of its own Variables.  It also has no trigger.  Those variables are set once, as soon as the state is entered.  

    The last piece of the puzzle here is Negative States.  Your character has 3 Negative States, -3, -2 and -1, which are read by Mugen in that order on every single Tick, with one exception.  State -3 is not read if your character has been put into a "custom state" by the opponent.  That means your character is actually in a state in the opponents code for a minute (this happens during throws and on other random occasions).  If that's the case, your characters state -3 will be skipped.  Other than that, all 3 Negative States are read on every Tick.  State -1 is used for joystick / keyboard input.  Usually it's a bunch of Change State type state controllers triggered by certain commands.  State -2 is just for code you want to happen every tick, and same for -3 mostly.  

    And that takes care of the core concepts.  Everything in character coding builds on that framework.

 

 

Link to comment
Share on other sites


-----------------------------------------------------------------------------------------------------------

LEVEL 2: COMMON CODE

-----------------------------------------------------------------------------------------------------------
 - STAGE 1. Common State Controllers

   Now that we understand the basic structure of a characters code, let's take a look at some common state controllers, and how they work.  The single most necessary state controller is the ChangeState controller.  Without it, your character would never leave their initial state, unless they were hit.  Not only is it responsible for changing from one state to another, but it's also responsible for changing from an idle / standing state to an attack state when a button is pushed.  So it's really the core of your characters input controls.  ChangeState is literally everywhere.  So how does it work?

   We know it has to be triggered somehow in order to actually work, so when your adding one into your code, the first thing to consider is when do we want the state were in to change?  Let's say our character is in the air, in a jumping state.  We want them to change to their landing state when they hit the ground.  So the trigger for our ChangeState controller might look something like:

trigger1 = pos y >= 0

Seeing as the characters pos y value is 0 when they're on the ground (negative numbers are upward), if your characters pos y is greater than 0 you would want it to go into a landing state.  So all together that controller would look like this:

[State 0, Go to landing state]
type = ChangeState
trigger1 = pos y >= 0
value = 60
ctrl = 1

You can tell by this ChangeState that the Statedef number of the landing state is 60.  We know this because value = 60.  There are only two variables for a ChangeState.  "Value" tells Mugen what state to put your character in, and "ctrl" tells Mugen whether or not they have keyboard / joystick control while in that state.  1 = yes and 0 = no for just about everything in Mugen.  

One last thing about changing states.  When Mugen is reading your character's state top to bottom, and it encounters a ChangeState, it will immediately jump to the new state and continue reading, starting at the top of it on the same tick.  It doesn't wait till next tick to start on the new state.  That's pretty much all you need to know about the ChangeState controller, aside from different ways to trigger it.

Let's take a look at another state controller: Velset, short for Velocity Set.  Obviously, this sets your characters velocity.  Here's how it looks in action:

[State 0, Change the velocity]
type = VelSet
trigger1 = time > 5
x = 0
y = -2

This would set your characters x velocity to 0 and y velocity to -2 (upwards) on every tick after the 5th tick since the state was entered.  Thats because it uses the time trigger.  And 0 counts for time, it's the first tick.  So ticks 0 - 5, nothing.  Tick 6 and up, velocities are set, until a ChangeState is triggered.  That's VelSet.  

Another common state controller is ChangeAnim.  It looks like this:

[State 0, Change the animation]
type = ChangeAnim
trigger1 = vel y < -1
value = 100
elem = 1

Value is the animation number to change your character's animation to.  Elem is the frame number to jump to.  You can leave this out if you want, and it will just start at the beginning.  In the example, the trigger would cause ChangeAnim to activate if your characters y velocity dropped below -1 (which again is upward movement).  On the same tick that was true, your character's animation number 100 would begin, without waiting for the animation they're currently in to finish.  It would also re-trigger on every tick the trigger was true, so your anim 100 would actually just keep starting over as long as their y velocity was less than -1.  Animations also loop by default, remember.

So those are some common state controllers.  You should now have a decent feel for how they work.  

 


 - STAGE 2. Common Statedef Details

   Next up is the actual StateDef itself.  This marks the beginning of any state, and give the state its number.  Here's a look at one:

; Stand
[Statedef 0]
type = S
physics = S
movetype = I
anim = 40
ctrl = 0
sprpriority = 1

I'm sure you've noticed there's no trigger.  That's because it triggers once, on the first tick the state is entered, and that's it.  There's actually a lot of variables that can be set here, but you'll usually only see a few, and any values it does set can also be set later by other state controllers.

The first thing being set here is type.  The options for that are S, C, A, L, or U which mean Standing, Crouching, Air, Lying down, or Unchanged respectively.  It defaults to S, so if you don't want it to change from the last state, make sure to add type = U.

The second one is physics.  The options there are S, C, A, N, or U.  Again, meaning Standing, Crouching, Air, None, or Unchanged.  Same goes here for Unchanged.  If you leave the Physics variable out, it will automatically set itself to S.  So if you want it to remain unchanged from the last state, you're going to have to add physics = U.  The physics variable will effect the friction the character experiences, which basically means if they're on the ground, and their velocity gets set to something, they'll slow down automatically.  

The third variable is movetype.  Options there are I, A, H or U.  Idle, Attacking, Hit or Unchanged.  Hit as in "got hit" not "hit the opponent".  This tells Mugen what your character's doing as far as attacks go.  Idle obviously means not attacking or getting hit.  Attacking and Hit are pretty obvious.  If you're character's punching or kicking, they're going to be in an attack state.  If they just got punched or kicked, they're probably going to be in a Hit state.  If you leave the variable out all together, it automatically goes to Idle.  Another way to say that is the variable "defaults to Idle".  So again, if you want it to remain unchanged from the previous state, you gotta add movetype = U.

Those 3 variables are the main 3 you're going to see in just about every single Statedef.  Even tho you can change them with the StateTypeSet controller, it's really a good idea to mark all that stuff at the beginning of the state, as you'll see once you get to coding.

As for the other variables, anim sets the animation, ctrl determines whether or not that state can take input from your keyboard or joystick, and sprpriority (short for Sprite Priority) tells Mugen which layer to put your characters sprite on, between -5 to 5.  They normally hang out around 0.  So that's Statedefs.   

 

Link to comment
Share on other sites

 - STAGE 3. Common States

Ok so at this point we know what a state is.  We know some of the common state controllers that make them up, and we know what the statedef itself is.  Now let's talk about some common states.  You might remember from the Graphics Mission that a characters sprites and animations have a numbering standard.  Sprite group 20, and animation 20 for example are commonly used for walking forward.  Well, as you might have guessed, so is state 20.  State's should share the same basic numbering standards as sprite groups and animations.  And for good reason.  Having all of them numbered the same makes your coding life a fuck of a lot easier.  You'll see.

So where can you find such a list you ask?  Here. (link)  That's a list of the suggested animation and sprite group standards anyway.  It gets a little slippery when you start coding because there isn't a single state for every animation, so you're going to have to use your best judgement at some point.  That being said, it's well worth the effort to keep it all synced up.  It's also true that not all characters have the same abilities.  Some characters don't dash, some parry, some don't super jump, so you're obviously going to have to go outside the suggested standards at some point.  And they're not a hard fast rule at all, this is totally fine, they're just there as a guide.  The most important thing is that you keep consistency between sprite groups, animations and states within your own numbering system.  

And that's the last part of the prep talk before we dive into actually coding a character.  From here on out we'll be moving out of the conceptual and into the actually doing it part.  So get ready.  And feel free to take a minute to revisit anything you didn't fully understand before we get started.
   

 

Link to comment
Share on other sites

×
×
  • Create New...