Smash science

[A Pimp Named Slickback]

the purpose of this is actually to provide clarity rather than just abstract concepts of priority

I'm not sure how or even if this would work but it would be fascinating to see, as it could probably have applications in other games.

 

[Signia]

Well, falling speed, weight, frame data on attacks, those are constants, not variables. A 7 frame jab will always be 7 frames.

% is a variable, it changes when players get hit.

Position is a variable. It's also important to define position as it relates to something else. If your reference frame is your character then they are never moving. Position has to be distance between two objects. Maybe that's obvious though, I don't know. I emphasize it though because position in relation to the distance between two characters is very important and something that players are always consciously judging.

Is priority a variable? I'm not sure about this one. Priorities are constant, marth's uptilt will always out prioritize Fox's dair because a disjointed hitbox, but that priority's existence is dependent on other constants, such as frames for up tilt to come out. So, priority's existence is a formula dependent on constant such as frames and fall speed, but also based on the variable of position.

Just some thoughts...

Hold on there... those are all variables, dependent on character, move or what have you. You may hold variables constant given certain conditions, like if character = marth, weight = x, so that you can determine values of other variables based on those. That's what science generally does, is determine relationships and algorithms for finding values of variables given the values of other variables. Essentially, everything is variable until you hold it constant for a situation that you define. Since you haven't defined what you're looking for, you have no constants, as defining the situation is essentially just declaring conditions, which is basically holding variables constant. But we are assuming the situation of playing a match, where already means that characters selected and attributes are constant so ... yeah you're ok. Let's try defining what we're looking for, though. You know, so we know what we're actually doing.

I'll start with something simple. As you may already know, priority is just the distance the hitbox extends past the hitbox in a given direction. Those variables are easily defined by number of pixels, so we can model the "abstract" concept of priority with numbers! (again, this is science: modeling concepts into clear mathematical definitions). I propose that priority is defined as

Priority vector = dot product of (pixels of hitbox vector - pixels of hurtbox vector) and (direction of priorty you're talking about)

If anyone is actually good at math, it'd be nice if the conceptual implications of the dot product were verified as being accurate for what I'm trying to define.

This is a pretty good example of how one would go about "making smash a science," I think.

 

[forward]

I'll look into that eventually, but there is something else I wanted to discuss. Physical phenomena is any observable event, and I think it is a good way to describe hit and hurt boxes. Now, another phenomena is being hit. This occurs when a hit box overlaps a hurt box.

So, is that the same way we define priority? As when a hit box overlaps a hurt box? I've always defined that scenario as "hitting."

Now, priority might possibly be what happens when two hit boxes overlap each other, which one takes effect over the other. But, that might be the "clanking" of attacks. If they both hit is that trading hits?

Can anyone verify that when two attacks approach each other the person who gets hit is simply the first one whose hurt box comes in contact with the opponent's hit box? This is what my intuition tells me.

If not, then we could define priority as one hit box taking effect before another hit box. It's plausible.

But, I like to think of priority as "potential to hit." In my other example, when marth was underneath fox I would say that marth has priority, because his potential to hit is greater than foxes due to the hit/hurt box placement for each character.

In any case, I agree that we need to define what we are looking for. I think that we can just observe any occurrence during a match and define it to be some thing. There are basic things such as distance between two points and moving between two points. If you go a little deeper you can look at shielding. A shield is a special property that reacts to the environment around it in a unique way. There is also character "status," meaning, is the character crouching, in the air, running, double jumped, special fall, etc. I think those are important to take into consideration because the status of a character determines a lot of other things. For example, if a character has used their double jump it gives a reasonably limited area of where they can move afterwards (except jigglypuff).

 

[Signia]

Sorry, I should have specified that I was talking about the hurtbox and hitbox of the same character. "Hitting" is indeed when one character's hitbox overlaps another character's hitbox.

The degree of disjoint between the hurt and hit box of the same character IS it's "potential to hit" (if you mean "potential to beat the other attack"). However this is the way it works for normal fighting games, I am sure. But if the same is true for smash I have no idea how to justify how many aerial trades there are. A trade SHOULD occur when both character's hitboxes hit each other's hurtboxes on the same frame, but that shouldn't be occurring that often, right?

Btw "clanks" can only occur when both characters are using ground attacks. Which mystifies me even more, as how can attacks "outprioritize" when both attacks stop as soon as the hitboxes come in contact?

(im gonna bait a name-search: Magus Magus420 shanus project m -- these guys would know)

Also keep in mind that when talking about priority, we assume both attacks are in their active frames at the same time and are approaching each other. Obviously, attacks that connect before the active frames of other attacks win, and attacks that miss the hurtbox get beaten by attacks that are on target.

 

[FoxLisk]

Hold on there... those are all variables, dependent on character, move or what have you. You may hold variables constant given certain conditions, like if character = marth, weight = x,

it's much simpler to think of these things as constants.

I'll start with something simple. As you may already know, priority is just the distance the hitbox extends past the hitbox in a given direction. Those variables are easily defined by number of pixels,

no they're not, because different TVs have different resolutions. there has to be a true distance measurement, but pixel is not it

so we can model the "abstract" concept of priority with numbers! (again, this is science: modeling concepts into clear mathematical definitions). I propose that priority is defined as

Priority vector = dot product of (pixels of hitbox vector - pixels of hurtbox vector) and (direction of priorty you're talking about)

a) priority doesn't exist in smash. as you explain later, a move having good 'priority' is just how far the move's hit box extends past the character's hurtbox. also this is hard to deal with because of dragging hitboxes.

b) the dot product of two vectors is a scalar, not a vector

c) what you actually need is a region of the plane, not a vector, anyway, which would just be the set of all points in the hitbox that are not also in the hurtbox.

If anyone is actually good at math, it'd be nice if the conceptual implications of the dot product were verified as being accurate for what I'm trying to define.

i think i just did that?

I'm pretty sure the dot product is actually used in melee for computing DI, though. like, if a move sends you along the vector u and you are holding a direction corresponding to the vector v, i'm pretty sure the vector of the direction you actually move in has a factor of u dot v.

it might just be vector addition along with a scalar multiple, though. i wish i had AR so i could just test it. it might well be that the direction you are sent in is of the form

.5(u + v)

where the .5 is necessary because you don't actually travel farther than the original mvoe would have sent you. in general.

wait, no, that can't be true. it's probably more like

r = |u| * (u + v/|u + v|).

that might be the correct formula.

although some moves are weird on DI. Like... at least in my experience it seems like Fox's upsmash sends you directly up, if you DI it away you go like, really far away, but if you DI in the effect of your DI is much less noticeable.

@Signia:

yeah all you're saying there is that 'priority' (which terminology i'm still uncomfortable with) of a move is a function of time, which would also have to be taken into account.

 

[forward]

Your formula makes sense but there are probably some properties of DI that need to be taken into consideration. For example, in your formula if you DI v is in the direction u then your unit vector doesn't change from the original direction of u, in that case DI with the direction the move hits you would not send you any further then the move originally hits you. This is not the case though, when we DI away from moves we can see our character get sent further than they normally would.

r = u + v

Where r is the vector of your flight path after being hit, u is the vector the move sends you and v is the vector your di creates. What creates the magnitude of v though I am not sure, because it seems like as you said, some moves have the ability to be DI'd in one direction very strong and very weak in another direction.

 

[Signia]

i think i just did that?

that's exactly the criticism I was looking for, yeah.

As far being able to DI more a certain direction for some moves, maybe you guys have the wrong idea of the original trajectory of the move. If you DI fox's upsmash in you go straight up but if you DI away you go off to the side... that looks to me like the original trajectory is off to the side a bit, and not straight up as you might think. Same with other moves... they don't all have the same 45 degree trajectory so that might make one think that DI is more effective in a certain direction (of the two perpendicular ones, I mean) sometimes when really the two possible DI'd trajectories are still centered around the original.

But I could be wrong, or missing something. Maybe SDI has something to do with it?

 

[FoxLisk]

Your formula makes sense but there are probably some properties of DI that need to be taken into consideration. For example, in your formula if you DI v is in the direction u then your unit vector doesn't change from the original direction of u, in that case DI with the direction the move hits you would not send you any further then the move originally hits you. This is not the case though, when we DI away from moves we can see our character get sent further than they normally would.

r = u + v

Where r is the vector of your flight path after being hit, u is the vector the move sends you and v is the vector your di creates. What creates the magnitude of v though I am not sure, because it seems like as you said, some moves have the ability to be DI'd in one direction very strong and very weak in another direction.

okay i assume i'm just misunderstanding you, but it sounds like you'er saying parallel DI affects trajectory? This is very well known to not be true. DIing along (or opposite) your regular trajectory does not affect your movement at all. Like, if you get uthrow'd (by marth or someone who sends yous traight up) and you DI either straight up or straight down, it is as if you did not DI at all.

 

[Signia]

concerning

'priority' (which terminology i'm still uncomfortable with)

Priority, in the sense of a quantity, where some attacks beat other attacks because one attack has more priority value than another, indeed does not exist. Attacks don't directly have priority values. Instead the illusion of priority is caused by the distance between hurt and hit boxes of the same character. This is the way it works in every fighting game, that's why instead of saying that priority doesn't exist, I say that the notion of a priority value/quantity as an intrinsic value is just a common misunderstanding of the true nature of priority -- as something IS deciding which attack wins when they collide. I'm saying one could talk about priority as if it was a quantity, if one used the equation I listed, so that it's modeled after what actually happening here. The dot product was a failed attempt to attach a direction to priority, as an attack's distance between hurt and hitbox is not necessarily the same in all directions. For example, Puff's bair hitbox extends far further behind her than anywhere else.

So I guess it would just be

Priority vector = (hitbox displacement vector - hurtbox displacement vector)

Where you'd draw vector lines starting from anywhere inside the hurtbox, in the direction of priority you're talking about. This would only be priority for one specific frame of the move, so it would not depend on time unless you wanted some kind of average or other generalization for the move itself.

A picture to illustrate what I mean would be helpful, let me see what I can do.

 

[forward]

Ok, I looked over this, and while I agree that your formula is true but I think there is something that it doesn't take into account. Either that, or i'm just seeing an illusion.

When you DI horizontal and in the direction to a move that hits you at a 45 degree angle, in my experience and thinking about the game, then the magnitude of your direction is greater than the magnitude of a no DI direction. Things that come to mind are Marth's f smash, peach and samus d smash.

This could be an illusion of the space though, I'd be willing to accept that. Or like you said, it could just be the properties of some DI. Like, the + or - (x,y) for V just vary from move to move, which would create different unit vectors...

That sounds accurate.

V = (Vx,Vy)
Vx and Vy are functions of the position on the joysstick.

If one direction grows more rapidly than the other then that means that holding the stick parallel to the direction of U does not fail to effect R, your hit trajectory.

So, in conclusion, the direction of the joy stick is not always the same as the direction of DI.

Weird.

 

[forward]

Priority vector = (hitbox displacement vector - hurtbox displacement vector)

This is actually really cool.

Something to take into consideration though is that priority covers area. So, you'd have to take the sum of all the priority vectors to to find your total area of priority. Nice, now we're getting into calculus.

 

[Winston]

What's the point of describing priority as vectors and then integrating to get an area?

Priority is naturally best described as areas to begin with.

Also, isn't it a known fact that DI doesn't change the magnitude of the initial velocity from the hit?

 

[Signia]

I was thinking of applying it more for specific situations. Area doesn't seem as important as length of priority in the direction of an opponent in a match. For example, we could say that a Ganon SH fair, assuming he is oriented in such a way that the move comes in at a 45 degree angle, will have X priority at the frame where the active hitbox is in range, but Marth utilt only has Y priority at 45 degrees, and Ganon fair will win or trade because Marth utilt's max priority occurs at 75 degrees.

With vectors showing how disjointed the hitboxes are for every in certain directions, we'd have a clearer idea of what beats what at certain approach angles. And I'd say it's pretty important to know what beats what...

 

[forward]

Also, isn't it a known fact that DI doesn't change the magnitude of the initial velocity from the hit?

I would 100% agree if it wasn't for the above examples that I posted earlier. Otherwise, I 98% agree.

If priority is best described as area, then what best describes area?

 

[FoxLisk]

What's the point of describing priority as vectors and then integrating to get an area?

Priority is naturally best described as areas to begin with.

Also, isn't it a known fact that DI doesn't change the magnitude of the initial velocity from the hit?

there is none. i think he just likes the word vector, it's very clearly a matter of area.

and I think that's true, and generally when it seems like distance is increased it's secretly because of fall speed, etc. if a move hits you sort of diagonally and you DI it horizontally you feel like you went further because it's tragically horrible for you, but it's not really true.

 

[Dark Sonic]

Okay, time to bring up some points about DI that many people might not know.

1. In melee, D can affect your trajectory by no more than 18 degrees in one direction or another(this is with full perpendicular DI).

2. DIing in parallel with an attack has no affect on trajectory. (some people still don't know this)


3. Very few moves have a 0 degree angle or a 90 degree angle (I actually can't think of any off the top of my head). So even with moves that look like they generally send you up, it's still better to DI in one direction than another (things like DIing Fox's upsmash away from him instead of towards him).


4. Gravity affects trajectory at lower launch speeds. This is a point a lot of people forget. Gravity is a constant force in the game that works against the vertical portion of knockback caused by a move, while launch speed is only an initial force. So while the horizontal component is maintained, the vertical component is constantly getting weaker.


That last part is actually what causes things like Sheik's fair, or Link's up B, or even Pikachu's tail spike send downwards. Their angles are actually above 0, but your character's gravity is enough to override the vertical knockback for a very long time (till percents that you'd never see in a match ).


It should be noted that hitstun is not affected by fall speed, nor is launch speed (all that happens is they travel less vertical distance from the same initial force, so they're in range to be hit again).


The more you know


edit:Forward actually brings up an interesting point about control stick input that's worth looking into.

 

[forward]

4. Gravity affects trajectory at lower launch speeds. This is a point a lot of people forget. Gravity is a constant force in the game that works against the vertical portion of knockback caused by a move, while launch speed is only an initial force. So while the horizontal component is maintained, the vertical component is constantly getting weaker.

So, this technically means that for the same knock back of a move, the closer the angle is to 90 degrees then the shorter distance that move will actually send you because the vertical force of gravity will affect a larger portion of that knock back.

Also, I was wondering if newton's 1st law comes into affect in this game. I wonder because if a character is launched at an angle, we can see that it is the gravity that causes them to stop moving up, but what force stops them from moving horizontally?

Of course, this is a game program and it doesn't have to follow nature's rules of physics. So there is no reason that it must be a horizontal force that slows them down.

 

[Fly_Amanita]

None of Newton's laws make sense in the context of smash since there isn't a nice notion of mass. Pretty much any notion of mass you could assign to a character would end up violating the second or third law, which isn't surprising since there isn't any reason to expect them to hold in the world of smash in the first place.

Back on the topic of priority:

There are a few decent measurements, although all have their faults.

You could take the supremum over the duration of a move of the supremums of the distances between points in a move's hitboxes at a given time and points in the intersection of the hitboxes and the character's hurtboxes (assuming this set is non-empty, which it likely is with just about every non-projectile). This would essentially tell you the maximum disjointedness of a move, which may be good to know every now and then. If you wanted to, you could find a set of vectors associated with this distance that would more or less tell you in what directions the move attains its greatest disjointedness.

A problem with that approach is that it only tells you stuff about the maximum disjointedness and nothing about the move's "priority" over the course of its duration. You could also look into things like the average distance over the course of a moves duration of the maximum distances between points in the moves hitboxes and the intersection of a moves' hitboxes and the character's hurtboxes if you want some to look into some sort of notion of net of disjointedness.

There are a ton of different ways of representing some idea of priority; which one is best depends on the context.

 

[FoxLisk]

Back on the topic of priority:

There are a few decent measurements, although all have their faults.

You could take the supremum over the duration of a move of the supremums of the distances between points in a move's hitboxes at a given time and points in the intersection of the hitboxes and the character's hurtboxes (assuming this set is non-empty, which it likely is with just about every non-projectile). This would essentially tell you the maximum disjointedness of a move, which may be good to know every now and then. If you wanted to, you could find a set of vectors associated with this distance that would more or less tell you in what directions the move attains its greatest disjointedness.

this made me want to die. what good will this do aynone?

also everyone is throwing out these ideas as if the goal of this conversation is obvious. What is the goal? Where is all this going? What do you actually want to do with this?

Why is it any good at all? What science does in situations like this is create a model of the system under observation. but how does that help us? we already have a perfect simulation of the game, because it's a game, and we can test anything we need to know in that. Having the equations of motion or whatever wouldn't even be that useful, because it's easier to fire up your copy of the game and see what direction you go in when you get hit with a particular move than it would be to calculate it.

 

[Fly_Amanita]

Yes, it probably wouldn't do any good. I just found it to be an amusing thought experiment.

 

[Mahone]

lol... internet players

 

[forward]

this made me want to die. what good will this do aynone?

also everyone is throwing out these ideas as if the goal of this conversation is obvious. What is the goal? Where is all this going? What do you actually want to do with this?

Why is it any good at all? What science does in situations like this is create a model of the system under observation. but how does that help us? we already have a perfect simulation of the game, because it's a game, and we can test anything we need to know in that. Having the equations of motion or whatever wouldn't even be that useful, because it's easier to fire up your copy of the game and see what direction you go in when you get hit with a particular move than it would be to calculate it.

Yea, this probably won't do any good. We don't have a clear we goal, either. With that said it's hard to tell where this is going, and I don't know what I want to do with this. Again, I don't know why it is any good, nor do I know how it will help us. I agree, it is easier to turn on the game to observe things than to calculate things.

With all that said, I'll continue to ponder the answers to such questions, and I'll be sure to post any more thoughts I have on the subject in this thread.

 

[Signia]

this made me want to die. what good will this do aynone?

also everyone is throwing out these ideas as if the goal of this conversation is obvious. What is the goal? Where is all this going? What do you actually want to do with this?

Why is it any good at all? What science does in situations like this is create a model of the system under observation. but how does that help us? we already have a perfect simulation of the game, because it's a game, and we can test anything we need to know in that. Having the equations of motion or whatever wouldn't even be that useful, because it's easier to fire up your copy of the game and see what direction you go in when you get hit with a particular move than it would be to calculate it.

What good will it do ? Don't you want to know what beats what instead guessing all the time??

If I actually knew the hit/blockstuns, recovery, and priority of the moves at certain frames, I could come up so many traps and strategies easily because of specifically knowing WTF is going on. Like if I hit with fast-falled Marth tipper fair against a crouch-cancelled opponent at low enough percent, which follow-up attacks will beat their followup attacks? Will Dtilt combo? Or will their jab clank with everything? How many frames do I have to spare to run up and grab? Since I don't know, I end up ****ing GUESSING. How can you play a game like that?

We can test everything we need to know ? HOW? There is no record command feature in the training mode! I would need to get a friend to test stuff out for HOURS trying figure everything out AND we'd need to executing everything perfectly. If we had frame data (no, frame data does not just comprise of attack execution frames) anyone could map out any situation on their own.

I can't assume this is actually going anywhere, but a good place to be would be where we have the tools to correctly predict what will happen when we know what both players will do, and so players can understand their options, their opponent's options, and what beats what. Unless you guys are satisfied with playing with your eyes closed...

 

[Grim Tuesday]

What good will it do ? Don't you want to know what beats what instead guessing all the time??

If I actually knew the hit/blockstuns, recovery, and priority of the moves at certain frames, I could come up so many traps and strategies easily because of specifically knowing WTF is going on. Like if I hit with fast-falled Marth tipper fair against a crouch-cancelled opponent at low enough percent, which follow-up attacks will beat their followup attacks? Will Dtilt combo? Or will their jab clank with everything? How many frames do I have to spare to run up and grab? Since I don't know, I end up ****ing GUESSING. How can you play a game like that?

We can test everything we need to know ? HOW? There is no record command feature in the training mode! I would need to get a friend to test stuff out for HOURS trying figure everything out AND we'd need to executing everything perfectly. If we had frame data (no, frame data does not just comprise of attack execution frames) anyone could map out any situation on their own.

I can't assume this is actually going anywhere, but a good place to be would be where we have the tools to correctly predict what will happen when we know what both players will do, and so players can understand their options, their opponent's options, and what beats what. Unless you guys are satisfied with playing with your eyes closed...

Quote for truth.

 

[FoxLisk]

that was a good post aesthetically, but a very bad one informationally.

you will not ever be good enough to need that kind of knowledge. no one will. if you and a friend can't make it work when you're practicing, you wont be able to do it in tourney, whether or not it technically works. The only options you need to know are the ones your opponent can actually execute. it's like when fox hits your shield, he has some options:
1) shine grab
2) shine retreating aerial
3) just nairshine pressure
4) crossover aerial
5) waveshine crossover
6) waveshine back

and so on. you pick an option of yours that will cover the largest fraction of those, or the one that you predict he will do.

The way you're talking now, though, you'd have to pick an option that also covers multishine perfectly until your shield breaks.

tl;dr the kind of information you want is not valuable because it is not relevant to human play.

 

[Dark Sonic]

that was a good post aesthetically, but a very bad one informationally.

you will not ever be good enough to need that kind of knowledge. no one will. if you and a friend can't make it work when you're practicing, you wont be able to do it in tourney, whether or not it technically works. The only options you need to know are the ones your opponent can actually execute. it's like when fox hits your shield, he has some options:
1) shine grab
2) shine retreating aerial
3) just nairshine pressure
4) crossover aerial
5) waveshine crossover
6) waveshine back

and so on. you pick an option of yours that will cover the largest fraction of those, or the one that you predict he will do.

The way you're talking now, though, you'd have to pick an option that also covers multishine perfectly until your shield breaks.

tl;dr the kind of information you want is not valuable because it is not relevant to human play.

No, he's not going to need an option that covers continuous perfect multishining (and actually, you can just drop your shield to get hit by one of the shines in that scenario, since shine->shine is not a true blockstring).

All he's saying is that frame data can tell you what is technically possible. FROM THERE you can infer what is reasonable. You look at what's possible, rule out what's improbable, and now you have a list of options that both you and your opponent should probably be practicing to use against each other.

You know what frame data can tell us?

Spoiler

I've mentioned this a few times to different people, but I haven't really carefully explained it, so I decided to make a thread about it.

Keep in mind that the only way I have of capturing these images is photographing the TV screen with a digital camera, so the quality isn't Magus level, but they get the point across, I think.

Basically I'm showing what Marth's dtilt looks like against Sheik's shield, then what happens when Marth holds away while Sheik grabs on the soonest possible frame.

This one is just to show the spacing. I don't know what the minimum safe range is. Jumping forward a bit...

This is the final frame of Sheik's shield stun.

This is the frame before Sheik's grab hits. I wonder what will happen...?

HEY WHERE'D YOU GO?

Same image as above with hitboxes/hurtboxes shown. As you can see, Marth could start the dtilt even closer and still be safe.

Like I said, this demonstration assumes perfect timing on Sheik's part and a simple directional input on Marth's part. It's extremely practical and easy to do.

This works even better against characters with smaller grabs (Fox, Falco, Peach).

I hope somebody can find some utility in this.

Now don't tell me that isn't practical.

It's true that playing the game can teach you these kinds of things eventually, but having the data just speeds up this process. While not all of it will be immediately applicable (since you may lack the techskill do do certain things), but at least it gives you something to work towards.



And even though some data isn't directly useful (such as knowing exactly how DI works) there is absolutely nothing with just obtaining knowledge for entertainment.

 

[ZoSo]

Wow what an amazing post.

 

[FoxLisk]

no, there's nothing wrong with doing it, i just want to see some sort of motivation for a project like this. that is actually a very useful and interesting tidbit. however, i suspect that in the course of studying the game in this manner, most of what you would find out is 'this combos on most DI with perfect execution,' which is rarely useful, or 'this move can counter this move with perfect timing,' which is rarely useful, etc. cases where the execution is actually relatively easy are valuable, but i would venture that most of the relevant cases of this have been discovered through the years and years of competitive play we have gone through.

I'm sure you could study, like, roy vs yoshi and find loads of valuable little tricks, but for the important matchups they're mostly known already.

 

[KAOSTAR]

Subscribes. Will read u nerd's thoughts after I watch this urltv.tv rap battle lol.
/being cool

 

[BigD!!!]

foxlisk, youre sitting here complaining about motivation when a bunch of other people are already participating

if youre not motivated, just let them do it

also, im sure theres tons of stuff like that dtilt trick waiting to be discovered

dark sonic/zoso that **** is hot, im playing marth vs a sheik next chance i get

signias scenario doesnt really fit, however, because you dont know ahead of time that the fox will crouch cancel and i dont think human reaction time would allow you to change your plan based on seeing it and still be efficient frame-wise, so youre already guessing if you act on that possible outcome

you dont have enough frames to spare to grab/dtilt though, if they cc marths fair youre better off dashdancing back then forward or, if you are really far away, maybe you can just grab through any of their moves

 

[FoxLisk]

no one has contributed anything concrete except that marth dtilt thing which was discovered independently, and through a method no one here has mentioned being interested in.

And I'm not sure you understand what I mean by 'motivation' here. I don't mean motivation like, when a student says "I'm not motivated to do my homework." I mean motivation like... what's the plan, what's the ideal outcome, where is this project going; what benefit will we receive if we were to complete this project?

 

[forward]

I started this thread for entertainment more than anything else...

 

[MarioMariox2]

So I was wondering what other people's opinion on this matter is. Can we turn smash into a science? Can we express this game in mathematical formulas?

If we furthered the research that M2K has already done then yes. This can be very data based. I would hate to play a "Sadaharu Inui" of Smash though... (Prince of Tennis ref.)

 

[Fortress | Sveet]

If you did you would be cunningkitsune.

"tech left, 100%"

Spoiler

<3 PoT

 

[MarioMariox2]

"tech left, 100%"

Spoiler

<3 PoT

"Your recovery was nice, but you're short 1 Marth's length."

GAME!

 

[Fortress | Sveet]

ckit doesn't need a notebook and computer, his brain is a giant database. I think he wears individual finger weights when he practices his tech skill tho...