YesNoOk
avatar

Help me do my math in Mugen :D (Read 6462 times)

Started by WastedCoder, May 01, 2023, 03:12:21 pm
Share this topic:
Help me do my math in Mugen :D
#1  May 01, 2023, 03:12:21 pm
  • **
    • Ukraine
So, I am making AI for a character, and he has the move where he charges at the enemy very fast.

He has physics set to S, which means that .85 friction is applied and this controller:

Code:
[state 0]
type = veladd
triggerall = time > 22
trigger1 = 1
x = 2

I am bad when it comes to maths, though I understand how friction is applied, but I want to calculate beforehand how many ticks will it take him to reach the enemy that is falling. I already have my Yacceleration formula and I need to insert something like this there:

Code:
p2bodydist x / vel x

How do I do the vel x math here if it takes number 2 from veladd, multiplies by friction thing, which results in 1,7, then it takes 1,7 multiplies it by friction thing again and adds it to the previous number, which results in 3,145? How do I make these calculations before the character even starts moving, so it charges only if he can reach in time?  :neutral: 

Pls help  :help:

Re: Help me do my math in Mugen :D
#2  May 01, 2023, 03:51:08 pm
  • ******
    • Portugal
    • network.mugenguild.com/pots/
I'd really have to clear out the dust in my brain to answer your actual question ;D, but I can provide some advice instead. First thing is that using both acceleration and friction is very uncommon in a fighting game. The second thing is AI doesn't have to be a calculator. You can empirically check how many frames the move needs to hit properly and just use that time in your calculations (that said I'm guilty of making it a calculator at times).

If you want to figure out how to calculate it for the fun of it, then go right ahead, of course.
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Re: Help me do my math in Mugen :D
#3  May 01, 2023, 04:09:40 pm
  • **
    • Ukraine
I'd really have to clear out the dust in my brain to answer your actual question ;D, but I can provide some advice instead. First thing is that using both acceleration and friction is very uncommon in a fighting game. The second thing is AI doesn't have to be a calculator. You can empirically check how many frames the move needs to hit properly and just use that time in your calculations (that said I'm guilty of making it a calculator at times).

If you want to figure out how to calculate it for the fun of it, then go right ahead, of course.

Thank you for your answer.
I've already spent like hours and hours and I figured that this thing is called geometric sequence or something, but I ultimately failed to solve it xd
I am super bad at maths... it seems almost impossible, so, yeah, I will probably try to figure something like you're saying for some general distances.
But I'd still appreciate it, if anyone took the time and explained me, what should have I done in order to calculate it. Because for fixed velocities of projectiles and stuff I'd just go with (p2bodydist x / 20) for example, and even though that would result into a super long formula, I still like how it looks in game, for the hardest AI difficulty. 
Re: Help me do my math in Mugen :D
#4  May 02, 2023, 02:45:20 am
  • *****
  • Shame on you!
    • USA
How do I do the vel x math here if it takes number 2 from veladd, multiplies by friction thing, which results in 1,7, then it takes 1,7 multiplies it by friction thing again and adds it to the previous number, which results in 3,145? How do I make these calculations before the character even starts moving, so it charges only if he can reach in time?  :neutral:   

So I've done some pretty complex calculations in the past. Wolfram Alpha was always on my list to test out when I was totally stuck. It always sucked and could never make anything that got me closer. ChatGPT has.

BUT, your math comes down to 2 things. How fast P2 is estimated to hit the ground, and how fast you're willing to let P1 move.

I'm imagining 3 different ways that your move could work. Which could be coded multiple ways each.
Is it a custom combo kinda set up? Almost like a throw. Where you hit p2, they pop up, then P1 runs over and hits them a 2nd time?
Is this just a random special that targets P2's location and fires off toward that position?
Do you want P1 to have a set speed all the way through, or do you want it to slow down when it gets close enough to P2?

As far as I know, speed 1 moves 1 pixel per tic, speed 17 moves 17 pixels per tic.
So if P2 is 55 pixels up moving speed 8 down, and you're 175 pixels away;
55/8=x
175/x=y
So
Vel X = "175"/"55"*"8" ;55 is player 2 height, 8 is P2's vel y,  175 is p2 dist x
This might get you close to what you want


----
Also, you mentioned something that you wouldn't want this to trigger unless you were going to be able to hit P2 before they land. You'd just set this up as a trigger to check if a known value was greater or less than "55"/"8". Cuz if it's only going to take 2 tics for P2 to hit the ground there's no reason to run for it.
vVv Gouken718 vVv
Last Edit: May 02, 2023, 02:48:41 am by Odb718
Re: Help me do my math in Mugen :D
#5  May 05, 2023, 05:24:32 am
  • ******
  • If you’re gonna reach for a star...
  • reach for the lowest one you can.
    • USA
    • network.mugenguild.com/jmorphman
Can you provide more information about the move? When does the velocity kick in? Does the acceleration begin immediately, or does it wait one tick after the velocity starts (as is usually the case for most coders)?

Anyways, I'm not sure that determining the velocity here is the right way of going about this. The math gets tricky, and I was never the best at recurrence relations (this is all assuming that velocity begins at time = 0, and that acceleration and friction kick in at time = 1):



But, after some manipulation of these equations, a pattern starts to form...



And we can determine the general form of the formula needed to calculate the x-distance travelled in this move at any arbitrary point in time. It's not pretty, and each singular point in time uses a different formula. So while it is certainly possible to calculate the distance traveled given the velocity, friction, and accel, and time, it's something that doesn't seem very worthwhile in this situation.

I think instead your best bet might be to determine the average velocity of the entire move (it'd be easiest to experiment with the character and figure out the total x-distance traveled and divide by the number of ticks it takes to reach that distance, rather than calculating it yourself) and use that in your calculations. The result won't give you 100% accurate results, but it should be good enough (I would also advise taking the ceiling of p2bodydist x/average x-vel, to ensure you always overestimate the amount of ticks it would take to travel close enough to the opponent).
Re: Help me do my math in Mugen :D
#6  May 05, 2023, 10:30:08 am
  • ****
u need to tell the detail of the move

how the character move in x and y and when
how the emey will move in x and y and when
Re: Help me do my math in Mugen :D
#7  May 06, 2023, 10:22:29 am
  • **
    • Ukraine
How do I do the vel x math here if it takes number 2 from veladd, multiplies by friction thing, which results in 1,7, then it takes 1,7 multiplies it by friction thing again and adds it to the previous number, which results in 3,145? How do I make these calculations before the character even starts moving, so it charges only if he can reach in time?  :neutral:   

So I've done some pretty complex calculations in the past. Wolfram Alpha was always on my list to test out when I was totally stuck. It always sucked and could never make anything that got me closer. ChatGPT has.

BUT, your math comes down to 2 things. How fast P2 is estimated to hit the ground, and how fast you're willing to let P1 move.

I'm imagining 3 different ways that your move could work. Which could be coded multiple ways each.
Is it a custom combo kinda set up? Almost like a throw. Where you hit p2, they pop up, then P1 runs over and hits them a 2nd time?
Is this just a random special that targets P2's location and fires off toward that position?
Do you want P1 to have a set speed all the way through, or do you want it to slow down when it gets close enough to P2?

As far as I know, speed 1 moves 1 pixel per tic, speed 17 moves 17 pixels per tic.
So if P2 is 55 pixels up moving speed 8 down, and you're 175 pixels away;
55/8=x
175/x=y
So
Vel X = "175"/"55"*"8" ;55 is player 2 height, 8 is P2's vel y,  175 is p2 dist x
This might get you close to what you want


----
Also, you mentioned something that you wouldn't want this to trigger unless you were going to be able to hit P2 before they land. You'd just set this up as a trigger to check if a known value was greater or less than "55"/"8". Cuz if it's only going to take 2 tics for P2 to hit the ground there's no reason to run for it.
Thank you for your answer!
The move is Chidori. Sasuke Uchiha uses it. He charges it for 23 ticks and on 24th he starts moving.
This is the formula I am using. 8.5 is vel x, which is ofc just a average speed.
Code:
p2bodydist y = [-49-(enemynear(var(59)), movetype = H)*floor((23+floor((p2bodydist x / 8.5)))*(enemynear(var(59)),Vel Y)+((23+floor((p2bodydist x / 8.5)))*((23+floor((p2bodydist x / 8.5)))+1)/2)*fvar(20)),0-(enemynear(var(59)), movetype = H)*floor((23+floor((p2bodydist x / 8.5)))*(enemynear(var(59)),Vel Y)+((23+floor((p2bodydist x / 8.5)))*((23+floor((p2bodydist x / 8.5)))+1)/2)*fvar(20))]
Re: Help me do my math in Mugen :D
#8  May 06, 2023, 10:31:57 am
  • **
    • Ukraine
Can you provide more information about the move? When does the velocity kick in? Does the acceleration begin immediately, or does it wait one tick after the velocity starts (as is usually the case for most coders)?

Anyways, I'm not sure that determining the velocity here is the right way of going about this. The math gets tricky, and I was never the best at recurrence relations (this is all assuming that velocity begins at time = 0, and that acceleration and friction kick in at time = 1):



But, after some manipulation of these equations, a pattern starts to form...



And we can determine the general form of the formula needed to calculate the x-distance travelled in this move at any arbitrary point in time. It's not pretty, and each singular point in time uses a different formula. So while it is certainly possible to calculate the distance traveled given the velocity, friction, and accel, and time, it's something that doesn't seem very worthwhile in this situation.

I think instead your best bet might be to determine the average velocity of the entire move (it'd be easiest to experiment with the character and figure out the total x-distance traveled and divide by the number of ticks it takes to reach that distance, rather than calculating it yourself) and use that in your calculations. The result won't give you 100% accurate results, but it should be good enough (I would also advise taking the ceiling of p2bodydist x/average x-vel, to ensure you always overestimate the amount of ticks it would take to travel close enough to the opponent).

Thank you for your answer!
Of course.
Move is Chidori form Naruto.
Velocity kicks in on the 24th tick after activation. And on 25th tick he gets his first 1.7 velocity.
The formula I need to slap the vel x in, looks like this:
Code:
p2bodydist y = [-49-(enemynear(var(59)), movetype = H)*floor((23+floor((p2bodydist x / 8.5)))*(enemynear(var(59)),Vel Y)+((23+floor((p2bodydist x / 8.5)))*((23+floor((p2bodydist x / 8.5)))+1)/2)*fvar(20)),0-(enemynear(var(59)), movetype = H)*floor((23+floor((p2bodydist x / 8.5)))*(enemynear(var(59)),Vel Y)+((23+floor((p2bodydist x / 8.5)))*((23+floor((p2bodydist x / 8.5)))+1)/2)*fvar(20))]
Yeah, actually, that's the conclusion I've come to. That's too complicated, and I've already spent too much time trying to figure that out.
Oh, that's what I decided to do. XD
Re: Help me do my math in Mugen :D
#9  May 11, 2023, 01:58:25 am
  • *****
  • Shame on you!
    • USA
So I'm trying to sort that last long line of code you posted.
One thing that jumps out at me is
enemynear(var(59)), movetype = H
is scattered throughout the line. I'd personally make 2 of whatever you're making. 1 for the hit reaction, and 1 for the not hit reaction.
BUT I thought this was FOR the hit reaction.
So Why's it there??

One other thing,
23+floor((p2bodydist x / 8.5)))
is something else I'd reduce down. You can set the value as a variable and the code will be a LOT easier to read.
 
    p2bodydist y = [-49-(enemynear(var(59)), movetype = H)*floor((23+floor((p2bodydist x / 8.5)))*(enemynear(var(59)),Vel Y)+((23+floor((p2bodydist x / 8.5)))*((23+floor((p2bodydist x / 8.5)))+1)/2)*fvar(20)),0-(enemynear(var(59)), movetype = H)*floor((23+floor((p2bodydist x / 8.5)))*(enemynear(var(59)),Vel Y)+((23+floor((p2bodydist x / 8.5)))*((23+floor((p2bodydist x / 8.5)))+1)/2)*fvar(20))]

vs

    p2bodydist y = [-49-(enemynear(var(59)), movetype = H)*floor((Var(718))*(enemynear(var(59)),Vel Y)+((Var(718))*((Var(718))+1)/2)*fvar(20)),0-(enemynear(var(59)), movetype = H)*floor((Var(718))*(enemynear(var(59)),Vel Y)+((Var(718))*((Var(718))+1)/2)*fvar(20))]


But even with all that, when I plug in arbitrary numbers, I'm getting a crazy span in the results. Like say P2 is 89 away from P1.
23+floor((89 / 8.5)  = ‭33.470588235294117647058823529412‬

Code: (Easier to read with the return)
p2bodydist y = [-49-  1*floor((33)*(enemynear(var(59)),Vel Y) + (33*34/2)*fvar(20))  
, 0-(enemynear(var(59)), movetype = H)*floor(33*(enemynear(var(59)),Vel Y)+(33*34/2)*fvar(20))]
33 times 34 divided by 2 is 561. how small of a fraction is fvar(20)????

At this point I'm not even sure what you're trying to code with the
p2bodydist y =
starting things off.
It seems like you want your range to be 0 to 49, so maybe just code for that??

I think you're making the code WAY more complex than it needs to be.
vVv Gouken718 vVv
Re: Help me do my math in Mugen :D
#10  May 12, 2023, 10:46:08 pm
  • **
    • Ukraine
So I'm trying to sort that last long line of code you posted.
One thing that jumps out at me is
enemynear(var(59)), movetype = H
is scattered throughout the line. I'd personally make 2 of whatever you're making. 1 for the hit reaction, and 1 for the not hit reaction.
BUT I thought this was FOR the hit reaction.
So Why's it there??

One other thing,
23+floor((p2bodydist x / 8.5)))
is something else I'd reduce down. You can set the value as a variable and the code will be a LOT easier to read.
 
    p2bodydist y = [-49-(enemynear(var(59)), movetype = H)*floor((23+floor((p2bodydist x / 8.5)))*(enemynear(var(59)),Vel Y)+((23+floor((p2bodydist x / 8.5)))*((23+floor((p2bodydist x / 8.5)))+1)/2)*fvar(20)),0-(enemynear(var(59)), movetype = H)*floor((23+floor((p2bodydist x / 8.5)))*(enemynear(var(59)),Vel Y)+((23+floor((p2bodydist x / 8.5)))*((23+floor((p2bodydist x / 8.5)))+1)/2)*fvar(20))]

vs

    p2bodydist y = [-49-(enemynear(var(59)), movetype = H)*floor((Var(718))*(enemynear(var(59)),Vel Y)+((Var(718))*((Var(718))+1)/2)*fvar(20)),0-(enemynear(var(59)), movetype = H)*floor((Var(718))*(enemynear(var(59)),Vel Y)+((Var(718))*((Var(718))+1)/2)*fvar(20))]


But even with all that, when I plug in arbitrary numbers, I'm getting a crazy span in the results. Like say P2 is 89 away from P1.
23+floor((89 / 8.5)  = ‭33.470588235294117647058823529412‬

Code: (Easier to read with the return)
p2bodydist y = [-49-  1*floor((33)*(enemynear(var(59)),Vel Y) + (33*34/2)*fvar(20))  
, 0-(enemynear(var(59)), movetype = H)*floor(33*(enemynear(var(59)),Vel Y)+(33*34/2)*fvar(20))]
33 times 34 divided by 2 is 561. how small of a fraction is fvar(20)????

At this point I'm not even sure what you're trying to code with the
p2bodydist y =
starting things off.
It seems like you want your range to be 0 to 49, so maybe just code for that??

I think you're making the code WAY more complex than it needs to be.

Oh, thanks for answering once again.
I've changed the entirety of that, limiting the whole thing to work only if p2bodydist x = [0,100]
I used then different values. And I don't use vars, because I don't have many spare ones.
Now for the acceleration formula I have this in AI helper:
Spoiler, click to toggle visibilty
And this in -2 state:
Spoiler, click to toggle visibilty
So, yeah, I solved the issue and made it work.
If u need, I can explain how this works, but I suppose the above code will be enough. This thing isn't mine, obviously. I found it on some old forum, as well as the tuto on how to use it, and there I am, using it. It works perfectly, but if enemy isn't hit, he may evade a special or super, which will result in a waste of meter.