Essentially what I've been doing on and off for what I think might be the past 2 years (I honestly lost track of time, it could be as long as 4) is "converting" Buriki One's system for characters. I started thinking about this after playing Buriki One a while back and thinking about how much I loved the game because of how different it was. While I think Garou and The Last Blade are the best fighting games made, Buriki One is very close to my heart and is my all time favorite, and I actually am surprised it hasn't been done yet. It's remarkably deep in how unorthodox it is, and I feel that unless someone invests a large amount of time into it, they don't understand the nuances. It's really easy to make generalizations concerning Buriki One's gameplay because it seems like very few people actually have hands on experience with the game. I've had about 8 hours of hands on time with it in my life, and it can't be emulated very well yet, mostly to do with the lack of Hyper64 utilities available if I recall (there's a guy at the Neo-Geo forums called SNKdan who was apparently working on dumping Hyper64 bios, but that was in '10 so I'm not sure where that's gone by now), so I feel lucky that I have had so much time to absorb the system.

Maybe that intro was a bit too long winded and filled with useless personal anecdotes, but hey, that's why I started.

Buriki One is essentially the opposite of a normal fighter. Buttons dictate movement and the 8 way joystick dictates attacks and the like.  The mechanics are much more deep than just the controls, but in my opinion the controls of a game always reveal what kind of game it is (pacing wise). Not all characters are slow in Buriki One. You do have Ryo as well as several "quick" fighting forms like Taekwondo and Muay Thai, but it is the WORLD GRAPPLING TOURNAMENT, and many grappling styles aren't the most mobile forms of fighting.

If you need more detail on the system, check out log v0.9 below.

also here are videos : )

Note that I don't think I can import every mechanic. Some are dropped for different reasons: sometimes there's not as much room on the joystick because commands had to be moved around, some were really buggy even after I spent extended sessions editing them (mostly because I thoughtlessly screwed up certain things when I started), etc. A couple mechanics are still up to debate based on how much work they require (see the v0.9 log entry, which covers my questioning of certain mechanics and their implementation)

Buriki One Mechanics

   --Joystick and Buttons--
   Button A: Walk to the Left      Added
   Button B: Walk to the Right          Added
   Press button A twice: Forward Dash   Added
   Press button B twice: Back Jump      Added
   Press button A and B: Block          Added --Tweaked-- Back on the Stick

   Tap Down-Forward: Low Strike         Added
   Tap Forward: Middle Strike      Added
   Tap Up-Forward: High Strike          Added

   Tap Down: Low Guard                  Added --Tweaked-- Back while crouching
   Tap High: High Guard                 Voided
                  
   Tap Down-Back: Low Dodge      Added --Tweaked-- Down, Back
   Tap Back: Middle Dodge      Added --Tweaked-- Back, Back
   Tap Up-Back: High Dodge      Added --Tweaked-- Up, Back

   Balance Gauge         To Be Added -- currently being coded
   Judges Decision         Added

(wow forum code for tables confuses me. Who actually uses that stuff?)
Also now my nicely formatted list from the txt is ruined : ((((((((((((

This file covers the states used in the Buriki One system. These states are listed there because they
are non-fluctuating. NEVER EVER give one of these states a number outside of it's designated range
because those ranges are hardcoded into both the Judges' Decision and Balance Gauge system. Without
these correct it won't line up with the system and it will be ignored in the system states.

Basic attacks = [200-499]
Throw = [800-899]
Special attacks = [1000-1999]
Super attacks = [3000-3999]
Grappling = [6000-6999]

Special State number groups that should never be used:

Judges' Decision = [-2]
Balance Gauge = [8000-8999]


Notes:
- The Special attack section is reserved for non-grappling special attacks. The grappling attacks have
their own section because the balance gauges changes into the grappling gauges when these states are
entered, and the grappling states directly affect the grappling gauges.


Reserved animation numbers for Balance Gauge
8000 = Gauge P1
8001 = Gauge P2
8002 = Bar P1
8003 = Bar P2
8004 = Arrow P1
8005 = Arrow P2
8006 = Grapple Gauge P1
8007 = Grapple Gauge P2
8008 = Grapple bar P1
8009 = Grapple bar P2


Reserved state & animation numbers:
(These are for when you are within a grappling situation)

Struggling to break grapple = 6000
Break Grapple type #1 = 6001
Break Grapple type #2 = 6002
Lost grip on target = 6003
Reaction to target breaking grapple = 6004
more to come...

Unlike Judges' Decision, the Balance Gauge's effects are only active when fighting other Buriki One
styled characters. This is mostly to prevent variable overlap, but I'm not too sure how much it could
leak over. I've written about 4 failsafes in this system (p2name, targethelperid, animexist, authorname)
to minimize the chances of variable overlap.

I can say with 95% confidence (percent error of plus or minus 10%) that it should work smoothly; however,
extra precautions can be taken by voiding the trigger in the state if the player does not feel that it is
safe enough. Data fluctuates, I can never be 100% certain it will always be safe, but I firmly believe
I've minimized the chance of variable overlap to the greatest extent.

This file lists the mandatory variable values for the system as well as an explanation of how the bars
function in-game
--------
Gauge Values

While not totally useful for the player (and VERY useful for me), these are the standards for the bar
values. Reading this data provides insight into how the bars work and what causes what. If you're into
the technical aspects of system mechanics and need to know everything inside and out to do well, by all
means check this out.
--------
Max Balance Gauge var numbers
Large bar = 200
Medium bar = 160
Small bar = 120

Balance Gauge refill rate = 2/sec

Attempted grabs lower the filler slightly (maybe about 1/6th, depending on the size of the bar), throws
deplete the bar by around 1/3rd of the original value.

Grabs are successful or not based on two variables, the size of the attacker's bar as opposed to the
defender's (with an additional randomizer) and how much the opponent resists the grab (joystick wiggling)

Attacks only lower the value of the gauge if they cause the opponent to lose balance. Losing balance is
equivalent to 1/8th, falling down is equivalent to an attempted grab (1/6th).

When the round ends, the balance gauge is reset as I assume you would have time to regain your balance
in between rounds.

Grapple Gauge
Amount of filler in the players' gauges is equivalent to the amount currently available in their Balance
Gauge when they enter the grapple.

The grapple gauge is active until the defender breaks out, the attacker runs out of bar, or the defender
runs out of bar.
The grapple gauge for both players drains mid grapple at a rate of = .2/sec

When the players recover from the grapple their balance gauge is set at a value of = 60
-----------------
How the bar moves
-----------------
The bars move based on your balance & movement. Walking and running move the bar in the direction you're
moving. Attacks will move the bar depending on the character's center of gravity in the current attack.
Attacks like light kicks will only move the bar if they cause you to shift your weight.
An example in Silber:
A: light kick - there is very little weight being shifted, so the bar does not move.
B: small uppercut - No weight shifted, you are still on two feet.
C: striking with the arm - Silber's entire body weight shifts when he moves in this attack, so the bar
follows suit.

Balance only applies to moves where you are on the ground. Aerial attacks (which exist as entering the
air from standing, not attacking from the air) DO NOT affect balance because when you are in the air
balance technically does not exist for you. You still possess a center of gravity, but it has to do with
heading straight down as opposed to falling over in one direction.

When hit the bar shakes because your balance is compromised for a short amount of time. If an attack
launches you, your aerial body is under the same criteria as that of aerial attacks and the bar resets
itself.

If you are in a state where your balance is shifted (based on the bar of course), you will be an easier
target for someone trying to grab you, similar to how it worked in Buriki One.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
About positions and resolutions
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

The bars are formatted to work with 640x480 only!

You will not see them if you play in HD!

I chose Silber as my first conversion because:
A) It's his home game
B) He isn't a grappler so I could tweak the basics of the system without having to deal with the balance gauge just yet
C) Outside of Gai Tendo and Ryo he's the only Buriki One character to appear in other games and actually play more like a grappler than the other two (read: Slow, sturdy, and powerful)
http://mugenguild.com/forum/topics/buriki-one-silber-now-1-0-compatible-146919.0.html

Silber
- Slow
- Hits like a train
- No grapples
Gai
- Quick
- Easily chainable combos
- a few grapples

Later?
Hanzo Hattori?
- Moderate speed
- Mostly grapples
(Izuna drop, Anti-air Izuna drop, armbreaker, backbreaker, skullcracker)
- Not a real ninja
Tizoc
- Slow
- Hard Hitter
- a few grapples
Kunagi
- Quick
- Momentum based (Anti-grappler)
- one or two submissions
Bret Hart
- Slow
- SUBMISSIONS
(SHARPSHOOTER GENERAL)

But I'd really like to make a Greco-Roman Wrestler or a Brazilian Jiu-Jitsu character because I used to do both
*wink* *wink* *nudge* *nudge*

Small system update dealing with the balance system. I've split the CNS into three types: Small, Medium,
and Large. This has to do with how big of a bar characters have based on fighting style and size. Gai and
Silber both have medium sized bars. Smaller characters and or those less based on grappling will feature
small balance values whereas larger characters and those entirely dependant on grappling will have larger
values.

Known (somewhat rare) bugs:
- That "disappearing" thing with the bar when you hold back still exists. Like I said before, go figure.
The AI can use this to make the bar flicker.
- When C hits a target the base bar reappears
- Recognition of side switching is buggy

While I'm compiling Gai's sprites I've been working at fixing a few of the annoying bugs that are in
the system.

First, I've fixed guarding. You can now guard when holding back, just as you normally would in a fighting
game. Crouching guard is still Downback on the stick though, because I figure it's more natural to press
downback than pressing the back button while crouching (that's a bit silly).

Second, I've fixed up a bunch of balance bar animations, making sure I find all of the ones that get
stuck in hitstates and the like to return prior to returning to the idle state. This means being hit into
the air while running for example.

Third, I've fixed the bar not shaking during combos. It was the easiest fix that took me hours to realize
because I didn't think about it. There are certain characters who will put you into states where the
bar won't exist (i.e. Kurai Naito's Mr. Karate). These are incompatabilities and I cannot foresee all of
these or undergo the effort to fix them all.

Fourth, I've fixed the grapple gauge not always appearing when you're walking and then grab. I've also
made sure you cannot grab while walking. There is a natural bug in the bar where if you hold a button
(it seems to usually be up or right), it will cause the bar to be stuck in the walking forward animation
until it is destroyed and another explod is made. This is something the AI might exploit, but otherwise
it's easy to avoid.

Fifth, I've fixed the bar getting stuck in motion loops when you're moving and then enter another state.
It'll still get stuck when you hold down a stick motion when you let go of walking, but this has to do
with command buffering messing with the

Next, I'm splitting all system settings (-2 and the like) separate from the character cns for easier
editing of the system files and being able to make universal ones I can copy over to characters without
having to edit everything manually when I make updates to the system. I can also release system updates
on their own so no one has to redownload the same characters every time I make a minor system updates.
Both the Balance Gauge and Grappling States will have their own files for easier editing on my part.

I also used this to generate a widescreen (720?) version of the bars, seeing how that resolution is
starting to get a fair amount of content. I'm not a huge fan of widescreen because it's too squashed for
my tastes, but I should make the system compatible so everyone can enjoy it.

In order to use the bars, just change un-; the 720 balance gauge and grappling states CNS files and ; the
standard ones.

Known (somewhat rare) bugs:
- That "disappearing" thing with the bar when you hold back still exists. Like I said before, go figure.
The AI can use this to make the bar flicker.
- When C hits a target the base bar reappears
- Recognition of side switching is buggy

Work on Grapple gauges FINALLY underway after a very long hiatus. The gauge states are made up of three
sections: The first is the transition gauge, followed by the removal of the transition gauge, and then
the states for the gauge itself. Both transition sections include the states for entering and exiting
grappling.

Building this took an immense amount of time not because it was difficult. The way of doing it was
actually really simple, what made it take so long was that I recompiled animations 3 times and recoded
everything every time I changed something. Originally the disappearance of the balance bar and appearance
of the grapple gauge was one animation, but because both required different scaling and positions I
couldn't set it up without messing up the other and modifyexplod had already proven it was useless for
this kind of on the fly stuff. What also proved to be an issue was that because it existed in the -2
state I couldn't specify the explod animation to be changed so there was no way to work around it.

What I did instead was make an animation for the balance bar to disappear and then edit the grapple gauge
animation so the gauge came in and then looped at the current location. The grapple gauge was coded in
the -2 states with the other bar states, but the transition animation plays separately within states 6998

and 6999 which are transition states for both attacking and being attacked. These states exist to allow
the animation to play and change the bars and then feed directly into the rest of the grappling states.

The states flow in this order:
Transition states (6998-6999)
Grappling state/held by grapple state (6000/6050)
Attacking/Being Hit states (6001-6049/6051-6099) - Return to 6000/6050 if grapple not broken or finished!
Broken Grapple states (6101-6103) - If target breaks grapple
Standing state (0)

Another thing I changed was the filler for the grapple gauges. They scaled terrible because I forgot the
arrow would look terrible scaled because it would just push in. Therefore, I've split the arrow into two
sections with the bar part being affected by scaling and the point to exist purely for cosmetic reasons.

Now with that, there's some limitations. Since I can't scale the arrow, the bar threshold for the grapple

state ending is higher than it is in the actual game. In the source, it ends once the bar depletes

completely, which is 0. If I have the bar scale to 0 in this, it goes beyond the gauge and looks bad. In
order to make amends because the scaling isn't that sophisticated, the threshold is when the stem of
the bar reaches the arrow, which is around 50-70.

Bar replenishment was an issue because it was coded in that the bar would not rise in any hitstates, but
I realized it would rise during grappling states for the attacker because his bar would naturally fall as
it is meant to, but would also replenish because he was not in a hitstate. It actually took two months to
mull this over when I later realized that all I had to do was but an XOR expression between the hitstates
and the grappling states.

Grabbing is now separated into two kinds: a standard hitdef for when fighting non-Buriki One characters,
and a Buriki One specific one that has p2name and authorname failsafes. What happens is that grabbing
takes both characters to my favorite kind of state: an inbetween where the differences are examined.
There are three sections to the inbetweens: Buriki One character & success, Buriki One character &
failure, and Non-Buriki one character. If you are a Buriki One character, it looks at their variables and
determines if it is a successor not, either sending you to a grappling breaking state or the inbetween to
enter grappling mode. If you are not a Buriki One character, it skips the grappling mode inbetween state
and goes straight to a normal grappling attack state.

Thanks to my brother for some help on certain things, but really mostly some workarounds for the
transition animations and bouncing off logical expressions that I was having trouble thinking about
without a second opinion.

Known bugs:
- That "disappearing" thing with the bar when you hold back still exists. Like I said before, go figure.
The AI can use this to make the bar flicker.
- When C hits a target the base bar reappears
- Recognition of side switching is buggy
- Bar hit anim only plays once for a combo of hits (i.e. if hit by a light attack canceled into a medium,

only the light shaking anim will play and the medium shaking anim will not)
- When walking/running forward and then grabbing, the grapple gague will sometimes not appear.

Small (or large, if you think it was a huge issue) bug fix having to do with the AI compatability with
the balance bars. The AI was duplicating them because it was bypassing the state checkpoints for the
explods. Big mistake on my part because I didn't realize that the AI completely ignores states and
freely flows between them. I fixed it by adding explod number checkpoints for each part of the bar so it
would prevent the AI from duplicating the explods whenever it moved. Also works as a failsafe in general
for the system.

Known bugs:
- That "disappearing" thing with the bar when you hold back still exists. Like I said before, go figure.
The AI can use this to make the bar flicker.

- When C hits a target the base bar reappears
- Recognition of side switching is buggy
- Bar hit anim only plays once for a combo of hits (i.e. if hit by a light attack canceled into a
medium, only the light shaking anim will play and the medium shaking anim will not)

The Balance Gauge system is now 100% complete. It actually took much longer to make it than I originally
hoped. I spent about half a day coding the original system, BUT what I discovered was that "modifyexplod"
doesn't work as it should and I had to change everything and use a new system to use the bars (requiring
me to create hundreds of animations for every type of movement within the bar's system).

What hurt me more was that I had to do these animations because in my opinion bindtime does not work as
it should. If I put bindtime to 1 it activates after 1 tick. So if I say "trigger1 = stateno ="blah blah"
I expect the explod to move while you're in that state. But that's not what happens. Bindtime activates
AFTER you leave that state, which makes no sense. If the trigger is that you're in that state then
bindtime should be active IN that state. If explods were coded efficiently at all it would be much easier
to actually move them, and that's REALLY unfortunate.

I've added several new states to the common as inbetweens for movement to make sure the bar moves
smoothly along with you. They literally just exist as states so the bars don't double up and overlap as
it returns to the original position.

---------------------------
breakthrough - 1/23/13
I noticed my algorithm for the scaling was actually incorrect!
i.e. I screwed up my parentheses and didn't realize it!

So instead of it being
0.00+(0.3*(var(47)-160)/160)
it was actually
0.00+(0.3*(var(47)-160/160)
which, if you know your basic algebra and order of operations means that var(47) isn't subtracting 160
first, but 160 is actually being divided by itself first, screwing up the entire formula.
WHOOPS!

If you're curious, the final correct function is:
0.00+((0.3*(var(47)))/160)

----------------------------
Updates - 2/21/13
Implemented facing and switching. The grapple bars are the only things incomplete because Silber does
not have any grappling moves. This will be patched in the future.

Switching as it is may still be a bit buggy. I know that when you switch sides it does not completely
register the change until the code recognizes another input. I'm looking into a solution for this, but
at the moment it's one small bug.

In other news, the bars will never be constant. I've written in exception for being hit, but you can't
always count on it being perfect. Custom hitstates will always be taken into account in my characters,
but I can't keep track of every character's custom hitstates, it's just impossible. Players will have
to live with the fact that if you fight non-Buriki characters the bars will be buggy.

Bugs:
- When C hits a target the base bar reappears
- Recognition of side switching is buggy
- Bar hit anim only plays once for a combo of hits (i.e. if hit by a light attack canceled into a medium,
only the light shaking anim will play and the medium shaking anim will not)

Added Dodging. It's funny how you're so against something at one point, but end up giving in at the end.
I originally didn't want dodging because I believed it was a mechanic that didn't fit in MUGEN. Then I
picked up one of those cool new characters and, playing Silber, I learned that maybe it wouldn't be too
bad to have a dodge after all. High dodge takes the place of guard for air attacks, since I looked
through the common again and I just don't think I can make a standing guard for air attacks because I'm
assuming the whole guard thing is hardcoded into the system and only activates within those states in
the common.

On fixing movement:
I'm not sure how this happened, except that it happened slowly. First, we need to understand that a large
amount of things within the common pertaining to movement and guarding were changed over the last couple
of years. Most it it turned out to be counter productive, because all it did in reality was screw with
everything. This was the calculated step-by-step process I underwent to fix the mess:
--------
Part 1 - Realize what caused the problem
--------
Right away, the first thing we needed to do was reactivate run and make it and hop back double tap. That
was easy, though it required wading through the common and figuring out what I changed was actually
stable in practice. I had muddled the lines between "FF" & "BB" with "holdfwd" & "holdback," which made
it hard to figure out which one was actually correct. Much of my facing states that dealt with control
mapping swapping when you changed sides fell into this (though movement was double tap at the moment,
if I edited something that said "holdfwd," it messed up the moment completely)

--------
Part 2 - Carefully make changes to all the conflicting commands
--------
First off, all "holdfwd"s and "holdback"s in the state 100 in the common were changed to the respective
commands "FF" and "BB" to make sure nothing was twisted with the hold commands. And I fixed that problem.
I did it by overriding what the game wanted by making a -1 state for it. I fixed the first part, but what
remained frustrated me the most.

--------
Part 3 - How the hell do I deal with broken animations?
--------
In the 4 times I tried fixing this before, what stopped me from finishing wasn't that I didn't know how
to sovle it. I knew how to solve the problem. What stopped me was the fact that when I changed everything
back to normal, it was more screwed up than it was BEFORE when you couldn't use all the movements. What
I essentially had to deal with was the animation starting, and the character moving, but after about 3
ticks the animation would stop in place and the character would still be moving toward the opponent.
To make matters worse, when you double tapped for run, it lasted 1 tick and then brought you back to the
standing animation.

The question was more like "why is it like this" than "how do I fix this garbage?" What the true issue
was in that common was in the statedef for walk:
[Statedef 20]
type    = S
physics = S
anim = 20
sprpriority = 0

When I first changed movement, I had added "anim = 100" so that when you held down a, it would make
walk run. I don't even remotely know why I kept it there, because I later voided the walking state and
just changed the "FF" command to hold a so that it would go to the run state, which I changed the
animation to 20 (go figure why I wrote stuff like this years ago, I was being really stupid). You
wouldn't believe it, and this is generally why I'd tell people NOT to screw with the common even though
I did that for 2 years, but adding that little "anim" section in the walk statedef ruins EVERYTHING. All
movement is compromised when you add that because MUGEN somehow cannot comprehend that one line of code.
(I swear all the "teaching vs first hand experience" lectures I recieved from my uncle are starting to
ring in my head right now).

--------
Part 4 - How I learned to stop worrying and love the common
--------
BUT I WASN'T DONE YET! WHERE'S RUN AND HOP BACK? MIA? KIA? POW? WHAM?
Well, there's a story for that too.

So I had solved the walking dilemma and went down to Run and Hop Back. I cross-checked my common with
the Vanilla common and found nothing was different except for my facing changestates for control
swapping. The same was true for Run Back. This generally meant it was a command error, so I went back
to double check the new "walk fwd" and "walk back" commands to see if they might be interfering (and to
see if I even needed them anymore)

AND WHAT HAPPENS?

It turns out that if I void the walking commands I made, the running commands work fine, but walk no
longer works. If I turn on the walking commands, then run no longer works and I have walk in perfect
condition once again. It was almost as if MUGEN and I had reached an impasse; it wasn't about to give me
what I wanted, and I almost just wasn't willing to try anymore. But I had to because I had already
invested at least an hour in this shit.

But why couldn't they exist together? It didn't make any sense? Was walk meant to be hardcoded in and
run meant to have a command, and it wouldn't work any other way? I didn't believe it, that's far too
counter-intuitive, so I did the same thing to Kung Fu Man, and well... It canceled the run.

All I have to say is "fuck Elecbyte." The goddamn truth is stranger than fiction.

--------
Part 5 - The solution arises
--------

After 2 hours of sitting around thinking about how to solve it, I had the idea to override walking over
time. If I couldn't have run normally, I'd force the common states to use it, so no matter what the
active commands were, I could still get my way.

The first thing I was able to do was get the hop back working. I doubt this was the best code, BUT it
got my back hop working 100%
[state 20 change to hopback]
type = changestate
triggerall = anim = 21
trigger1 = command = "BB"
value = 105

A similar code was applied to walking for the run, and I could see the change it made. Run phased in for
1 tick and then became walk again. I didn't have it yet, but I was 100% on the right path.

I voided state 20 (walk) because I felt it was too tied to the engine's system. In order to override it
I created state 99, which was the intermediate state between running and standing. When you press back or
forward, you enter state 99. From state 99 you can double tap either to enter the correct state.

THEN the one thing you had to do was go to state 100 and set ctrl = 0 to the statedef so it wouldn't
break from the running animation.

I must be a genius because that's literally the only way anyone could have solved this mess I created.
But now, it's done! One of the last important base mechanics of the Buriki One system is done!

Judges' Decision has now been added (with much thanks to Cyanide for pointing out my variables' trigger
problems). It takes the form of two variables: 40, which calculates P1's score, and 41, which calculates
P2's score. The system is only active for one character to prevent it from overriding itself if two
characters with it fight. It's always active for the home team (P1), but there's an optional trigger
in the varset state (located in the -2) that's for if you wanted to play arcade as a Buriki One
character. (In arcade mode the AI is home team, so you just need to make sure your void the first
trigger and activate the second for teamside = 1)

When the Judges' Decision is active, you gain points for each attack. All attacks are worth 100 points,
except for grabs and grapples, and are scaled based on the type of attack. Grabs always give 300 points,
and grapples give 400 times the hitcount of the grapple (which is how long you hold the grapple before
your gauge runs out or your opponent breaks it. Grapples are based on a system where you input follow up
commands during the grapple. Each follow up command counts as one hit and lowers the grappling bar each
time. When your bar is out the grapple ends.)

At the end of the round by time out, the scores of the variables are compared. If var(40) is higher, then
P1 wins. If var(41) is higher, then P2 wins.

IMPORTANT INFORMATION ABOUT COMPATABILITY
The Special Custom States file (name is sorta misleading, it's just a file of mandatory state numbers)
lists the states that affect the score system. These are non-fluctuating, meaning attacks in Buriki One
characters with both the Judges' Decision and Balance Gauge must always be within those boundaries.
If they're not, this happens: www.youtube.com/watch?v=fx2gK1Mv8BU

The Judges' Decision system is designed around these states, meaning that if you fight against characters
that break the rules set down in the Special Custom States file, there's no guarantee the variables will
calculate correctly.

To be done:
- Debugging while I figure out where to get balance gauges made for me

Fixed the walking in place when you press Up bug. Pressing up will now return you to the standing anim,
so if you press it in movement now it will no longer catch you in an animation loop.

All guard bugs have been fixed. The major problem was that when I originally edited the guarding section
of the common, I changed commands around so that when I went back to fix them I forgot what the
original commands were. It only took reading the vanilla common to find my errors (half of the
"holddown" commands that are standard were changed to "holdguard" (which is really just "holdback" with
another name because "holdback" was already changed and in use for movement), so I just had to fix those
and the bugs were fixed).

In other news, this is pretty much 99% of the system. The remaining is mostly additional things that I
could add later. I'm treating high guard as an extra thing until I figure out how to edit the air guard
code so that it allows you to guard air attacks while on the ground. In my opinion, the movement is fine
as it is and I won't be looking to add the two voided sections there. Dodge is extraneous in my opinion,
so I'm leaving it out. There isn't much demand for a dodge in MUGEN because the whole "meta" shit
behind a lot of fighting games makes dodging useless. Dodging was good in Buriki One because it was a
game filled with grapplers and a few normal fighters, and it was a good way to escape the clutches of
Sokolov so you wouldn't be submissioned so early. But I wouldn't even say Dodge played a huge role where
the game was broken without it, because the balance gauge did more to even out grabs than dodge would.

When it comes to the last few mechanics, it depends on how I feel. The balance gauge has a 50% chance of
actually being implemented, but it would only matter in grapplers, which is where it hits the wall.
All the balance gauge does is track how easy or hard it is to grab and be grabbed. I would explain it,
but I'd do it terribly so I'd rather quote The_Chosen_One (undisputed king of Buriki One) from the
Neo-Geo forums:

"Balance Gauge-
Every character has a balance gauge shown on the bottom of the screen. This balance gauge effects three
different things from what I have found.

First, it impacts how easily you are thrown, countered, or shaken(shook) off from grapples.

Second, when performing submission holds you repeat the joystick direction then back to neutral, the
amount of times you can repeat (and thus the damage done) depends on how full your balance gauge is.

Third, if you are the receipient of a submission hold it is SOMETIMES possible to lessen the damage or
return some of it by pushing the joystick left to right repeatidly. This is done a variety of ways
from pulling yourself across the mat to kicking your opponent while they are performing the move.
The amount of times you can do this is determined by your balance gauge.

As well, I also wanted to note that the size, starting point, and rate at which the balance gauge will
fill up will difer according to which character you have.

That should help a bit. When your balance gauge is empty they can throw you around like a rag doll
unless you counter. Whether or not you can counter will depend on the the grapple they attempt on you
and which character you have.

When they begin to grapple you (Ivan for instance) you can shake the joystick back and forth and
sometimes you will shake them off. That again depends on how much balance your character has as compared
to how much your opponent has. Some characters have a huge advantage in this area such as Ivan [Sokolov]
who has a huge balance gauge, while Takato has a rather small one."
                  -- The_Chosen_One, 8/25/2005

The deal with the balance gauge is that it requires a ton of work. I'm not converting Buriki One
characters, I am just converting the system. This means for every Buriki One character I'd make, I'd
have to create balance specs for them depending on their fighting style, which goes beyond just normal
character conversion because I'm now adding something entirely new which requires balancing every time
I make a new character as the standards would change as more are made.

The second problem is the main one: what does this mean in MUGEN? The hardest thing about converting
systems to MUGEN is figuring out how they'll affect characters in other systems. If a Buriki One
character had a Balance Gauge, would that make it so he could break out of custom states of non-Buriki
One characters? And if it didn't, what's the point of even making such a system if it's just there so
the system ends up being more accurate to the source. Accuracy is fine and all, but it really depends
if it's worthwhile to actually apply the system to the game. It's the same reason why I believe Dodging
shouldn't be converted; it really has no place in MUGEN. I could always add the bar for aesthetics, but
I'm not a flashy aesthetics kind of guy, I'm a tight system type of guy and I'd rather make sure the
system works fine than waste my time making Balance Gauges for every character.

Lastly, Judges Decision. In Buriki One Judges Decision only comes into play if time runs out. It would
be easy to make a variable that tracks your score based on what moves you land and how often you are hit
or grabbed. It's very simple and could easily be implemented, but what it requires is to completely
override the time out system already established, where if at the end of the round, even if you have
lower health you could have more points because you grappled your opponent out the wazoo, therefore
making you the winner. I can do this, but is it right to override the time out system in order to do
it?

Anyway, this was a lot longer than it should be, but I feel like v.9 is jsut about the final phase of
the system. Everything after this is just debugging and deciding whether to add the aforementioned
extraneous mechanics. When I first started making this system in late 2008 it was an idea that I didn't
even start coding until about 2009 or 2010. I'm surprised it actually took me less time than I thought:
only about two weeks because I made it in conjunction with Silber. However, I'm really glad I was able
to get this done, and I'll always look back on this being the most important and best thing I've ever
made (mostly just because I'm shit at making characters).

Bugs:
- Pressing Up while moving will cause you to walk in place (I'm almost going to argue that maybe I can't
fix this because it's hardcoded into MUGEN for jump to be Up. Too bad.)

I believe I've solved the hopping back while guarding sprite/animation hiccup. For some reason the game
didn't like that if you guarded you could hop back, and I'm pretty sure the ability to do that was
completely my fault when I rewrote sections of the common. HOWEVER, knowing that block is somehow
bound to the back of the joystick by the engine makes it easy to solve, and all I really had to do was
write a command using the back of the stick to deal with this and then create an exception for hopping
back being invalid when that command is applied.

Other changes:
- Readded crouching, due to A) it IS in the realm of possibility for grappling, I'm just stupid and
didn't want it even though I actually grapple and wrestle, and B) it allows for crouch guarding, which
is VERY important. However, crouching is purely for guarding and there are no attacks while crouching.
There is still no method for guarding air attacks, and there might never be, which is unfortunate.
The good thing is that once all debugging is done with guarding, the system will essentially be complete
outside of the miscellaneous systems (balance gauge & judges decision).

Bugs:
- Guard animation spasses out and gets caught in a strange stand to crouch loop
- Pressing Up while moving will cause you to walk in place

Important change regarding applied movement. Switching sides will now proc a movement change depending
on what side you face, similar to how MUGEN treats the directional keys. To illustrate:

Normal P1
a = forwards
b = backwards

Normal P2
b = forwards
a = backwards

When you switch sides, these two will change with you, P1's controls ending up as P2's and visa-versa.
Thus, it becomes:

P1 opposite side
b = forwards
a = backwards

P2 opposite side
a = forwards
b = backwards

Other changes consist of:
- Normal walking is now voided, After guarding if the player held down hop back and guard the character
would move back. Voiding this removes the issue (but voiding things isn't that good of a solution)
- Guarding bugs concerning getting stuck MIGHT have been fixed, the results are unknown as of now
-

Bugs:
- Guarding is still holding back on the joystick
- Pressing Up or Down while moving will cause you to walk in place

The system is rough at the moment, mostly full of messy code and voided sections, unrefined and
most likely comparable to patching up a large gash with a band-aid (read: the common is a mess, don't
look at it). However, it is still 100% compatible and runs fine, just be aware.

Changes made:
- The a and b buttons are Forwards and Backwards, respectively. Walking is currently FUBAR until I
take a detailed look over the bugs afflicting it, so they're voided at the moment and run is replaced
with walk. For backwards movement there is a hop back. Walking backwards is voided because it's
uneeded and redundant to have it when hopping back is a better way to disengage.

- Attacking relies on an 8-way joystick. Downforward, Forward, and Upforward and Weak, Medium, and
Heavy attacks, respectively. Special moves are combinations of these with Up and Down, and Super moves
are combinations of these as well as Downback, Back, and Upback. This is the mandatory template and no
characters will/should break it.

- There is no jump or crouch. This is not to promote a disadvantage whatsoever, but to adhere to the
notion of grappling as a ground only form of combat. Crouching as a mechanic itself MIGHT be reapplied
to the system in the future, but as of now it overrides the 8-way joystick when you press any form of
Down and I don't want to deal with it at the moment.

Known Bugs/To-Be-Fixed Shit (you can't expect me to do it all just yet):
- Walk doesn't exist until I figure out why
- In a recent cmd & common editing session the guard was returned from holding b (backwards) to holding
back on the joystick. I'm not sure how this happened, so bear with me for the moment.
- Crouching overrides 8-way joystick for Down movements (crouch is voided for this sole reason)
- Either people will have to get used to a & b being constant (i.e. unlike with arrow keys, a will
always be forwards, EVEN IF you've switched sides with the opponent), or I will try to force a change
of commands everytime you end up on the other side. Honestly I don't think it's a big deal (nor do I
think I can override this thing), but if it ends up being very bothersome I will "fix" it.
- Pressing Up or Down while moving will cause you to walk in place