Gravity Mod / Brawl+ Competitive Code Suggestions and Analysis

MookieRah said:

I'm willing to bet some personal pride that over time, Brawl+ will overtake Brawl as a true competitive game. Brawl will still have tournaments, but I think it would be for a more casual audience such as anime conventions and the like, but as more and more people try Brawl+, and the fact that it will be a far deeper game when it's completed (hell it's already far deeper), competitive players will continue to drift over.

Click to expand...

This is pretty much the feeling of the crew of smashers I hang out with. We had all quit Brawl after playing around 6-7 hours a day for the first few months after release... we gave the retail mode a shot and it was our opinion that the game was bad (just our opinion of course, it's great others can find it fun and all). We all went back to melee, and I didn't check the boards for ages... till a friend told me about brawl+. All day every day we would comment how MAD and hitstun in brawl would easily be enough for us to commit back to brawl playing. So, this was just a huge hit with all of us, and I expect it to catch on like wild fire with most the community once they try it out.

All 12 of the people in my group can no longer play brawl due to this lol. I honestly can't see ever playing past 1 stock again myself.... we went back to compare the difference and didn't make it through a match.

It's a bit crazy to think smash would be on modded sets, but man is this soft mod easy to do. I expect it wont be a issue like having to put a chip in would have been. I can see a few people bringing a modded wii each tourney no problem. The only issue now is rule set, and continued modding. Just the MAD vs BAD thing may take a while, but then there is also what hitstun is best (I am a fan of 10% now). Also there is the whole grav + damage side... personally I love it, but I could see it being a little too far from the original game (queue the omg it's more melee clone hacks here, cause it sure feels more like melee with it).

I would like to see a sticky for some official codes soon that a SBR group could vote on and maintain/update as they see fit. Having one text file we all would use is a nice idea. I'd really like to start pouring time into practicing, but if the codes change a lot this may be useless. If something like MAD or lag cancel form changes that would be a huge impact on all the practice. We all expect this to become the normal mode of brawl in the competitive scene after 2-3 years, so it was nice to see one of the older board members post that.

Since the current formula is for the vertical velocity, I made part of the formula for displacement. It goes like this

-(gx)^2 + ix - x while (i - gx) > g
4

If i - gx < g then ???

Once again, we should look at the example

x0 = you're on ground
x1 = 9 - 2 * 1 = 7 (TD = 7)
x2 = 9 - 2 * 2 = 5 (TD = 12)
x3 = 9 - 2 * 3 = 3 (TD = 15)
x4 = 9 - 2 * 4 = 1 (TD = 16)
x5 = 9 - 2 * 5 = -1 (TD = 15)
x6 = -2 by default (TD = 13)
x7 = etc.

so if we want to jump to frame 4 and see the TD then we use the TD formula

-(2 * 4)^2 + 9 * 4 - 4
4

-(8)^2 + 36 - 4
4

-64 + 32
4

-18 + 32

16

example 2

-(2 * 3)^2 + 9 * 3 - 3
4

-(6)^2 + 27 - 3
4

-36 + 24
4

-9 + 24

15

If you look back at the chart, it matches perfectly both times

x0 = you're on ground
x1 = 9 - 2 * 1 = 7 (TD = 7)
x2 = 9 - 2 * 2 = 5 (TD = 12)
x3 = 9 - 2 * 3 = 3 (TD = 15)
x4 = 9 - 2 * 4 = 1 (TD = 16)
x5 = 9 - 2 * 5 = -1 (TD = 15)
x6 = -2 by default (TD = 13)
x7 = etc.

Define the variables, please. I'm sure I could understand it if I took the time, but I'm too lazy.

If anyone could provide an accurate example of this (complete with frame data) from the game, I would love them forever.

look at previous posts

@problem2: Cool, although I was gonna do that eventually, myself, for when I finally cracked the game's units. Right now it's kinda pointless =(

Also, your formula pretty much just explodes once you start plugging in large numbers, which we will have to do. Try plugging in 17 for the jump force, 5 for gravity, and solving for displacement on the 5th frame. Your formula produces 48.75. The number should be 18. I don't care how you round it, but 48.75 isn't ever going to be 13.

Almas said:

Define the variables, please. I'm sure I could understand it if I took the time, but I'm too lazy.

If anyone could provide an accurate example of this (complete with frame data) from the game, I would love them forever.

Click to expand...

K. Well, I don't have data from the game yet. I will sometime soon (hopefully), but at this point in time I only know that mario takes 21 frames to complete a short hop and that he falls at a rate of about 1/12 of a stage builder block per frame. I suppose I could turn this into some type of makeshift arbitrary unit for the sake of example, though.

Alright, so first off, I really have no idea how problem2 derived his formula, but there's probably a much easier (and more correct) way to get a displacement formula (it really looks a lot more complicated than it is). The formula for a character's velocity on a particular frame can be given by:

v(f) = v0 - g*f

Where v0 is the initial velocity, g is the force due to gravity, and f is the number of frames since the character was airborne (or they performed whatever action you're calculating, but note that this will then only give you an answer relative to your start point if you don't add the number of units high you were to the final displacement calculation). Of course, the velocity on a particular frame is the same thing as how many units the character traveled on that frame, so to find total displacement, we can just use a summation formula.

<Sum from i to n> c + an = c * n + (a * ( n * (n + 1) / 2))

If you're not familiar with summation notation or the summation formulas, it doesn't matter. What matters is that the position equation plugs into it as follows:

(v0 * f) - (g * (f * ( f + 1) / 2))

Which then simplifies down to:

x = f * (v0 - ((g/2) * (f + 1)))

So just plug in whatever value of f you want, and calculate. Unfortunately this doesn't work after the frame given by:

f = math.ceiling (v0 / g)

So to find the displacement of a character after this point, we can use the formula:

x = (math.ceiling (v0 / g)) * (v0 - ((g/2) * ((math.ceiling (v0 / g)) + 1))) - (g * (f - (math.ceiling (v0 / g))))

You've just gotta test whether the frame you want is before or after v0 has been completely negated.

edit: I'm pretty sure I messed up somewhere in here, but once I figure out where, this will be correct. This currently produces 285 for the values I mentioned above in the second paragraph, which is obviously wrong. I hate working stuff out on the computer, because I always screw something up compared to working it out on paper. I'll get back to you on this.

edit again: No, I did not make any error, and this indeed would come out to give a displacement of 13 units for a 17 jump force, 5 gravity, 5 frames into the jump.

Regarding Mario's Shorthop. Does that 21 frames include startup/landlag? I would guess not because it seems extrmely low as it is.

That's from the point that he's in the air to the point at which he hits the ground. It does not include startup/landlag.

Anyway, I worked out the displacement formula in government today (loleasyclass). The raw formula would be:

x = f * (v0 - (g * (f + 1) / 2))

Which only works for values of f equal to or less than

f = math.ceiling (v0 / g)

So for values greater than that value of f, you can use

x = (math.ceiling (v0 / g)) * (v0 - (g * ((math.ceiling (v0 / g)) + 1) / 2)) - (g * (f - (math.ceiling (v0 / g)))

And for simplicity's sake:
x is the displacement in units from your starting point
v0 is your initial velocity, or the jump force
g is force due to gravity
f is the number of frames since the start of the calculation
math.ceiling is just a rounding notation telling you to round the result up (so 3.1, 3.5, and 3.9 all become 4)

I need to figure out a reliable way to work this backwards, though. The rounding function really screws this up.

edit: Ok, I have no idea what happened, but the formula in my above post is identical to the one I just posted. I must have made a major error when evaluating it or something, which led me to believe I made an error in the initial calculation. Oh well. This version is prettier, at least. Right?

v=u+at

s=ut+at²/2

(Standard equations of motion)
I expect you just did some funky factorisation on these?

I think Mario's shorthop may be more than 21 frames, though. That's 1/3 of a second, isn't it? Unless the game doesn't use 60fps... What means of calculation are you using? I've been doing basic counting using a Gecko's pause/next functions, and honestly it doesn't feel -right-, though I've only had it for a day or so. I get about 18 with increased grav in this case.

I'm personally thinking how Brawl stores launch data. Are launches from attacks and from jumping stored as different variables? I'm thinking maybe the game uses polar coordinates to provide a character's overall velocity at any given moment, so by freezing on the frame a throw is executed one could find the memory position that holds current velocity magnitude. Then a code could apply a scalar multiple to it.
Then, we decrease knockback from attacks and increase gravity to counteract the effect of all launch speeds being increased. Provided my theories are correct. Which they probably aren't, since I know next to nothing about gamewriting.

I actually tried using the standard equations at first... and it didn't work out for some asinine reason.

x = (1/2)(a)(t^2) + v0t + x0

Or in the terms I've been using:

x = (1/2)(g)(f^2) + v0f + x0

And then in the final version for values greater than f = math.floor(v0 / g):

x = (1/2)(g)((math.floor(v0 / g))^2) + v0(math.floor(v0 / g)) + x0 - (g * (f - (math.floor(v0 / g)))

Would produce the following if I plugged in g = 5, v0 = 17, f = 5, and x0 = 0:

x = (1/2)(- 5)((4))^2) + 17(4)) + 0 - (5 * (5 - 4))

x = -40 + 68 - 5 = 23

And if you remember from before, the value should be 13. Remember how I said before that there is no acceleration due to gravity in brawl? This is pretty much what I mean. The game simulates gravity by subtracting a constant value from your current vertical velocity each frame. Obviously, this isn't how real gravity works, which is why I needed to use a summation formula.