In Progress Street Fighter Initial Impact

The project is currently under development.
After thinking about @NED's suggestions for the portraits, they are great ideas. There's one got me thinking of adding a new (picture) frame over a portrait which would be cool to see. I don't know which one to choose.
NED said:
-try to remove them.
-Or make thicker white borders
Click to expand...
Some character portraits I have don't have borders at all. Don't mind the white parts around Yang 'cause it's just a temporary concept which I will change. I know that needs to be edited.

My Mod - 0917.png

I can add a frame on the portraits. This is just a concept for now.

My Mod - 0917 with frames.png

I made something that had been bothering me to fill in the unused symbols with characters' faces for the whole time, since no one attempted to bother it. It was something I discussed earlier. I was working on the bottom fonts for the symbols of commands in the continue screen. Plus, I gave some advising quotes like the Japanese version of SF2 had after the player loses a match. However, there are some stuffs left to fix on the font side. As of now, I'm satisfied with the result, despite some fonts being places in two blank spaces in between instead of none.

My Mod - 0958.png

My Mod - 0955.png

My Mod - 0959.png

Video will be up later.

Yes. In the continue screen, there will be animation that will make the player get up to continue after pressing start.
 
Last edited:
Both are ok, just be sure to have the same color for everybody and avoir the white antialiasing thing is you go for a black BG.
About the purple frame, why not but it's a bit too different of the SF2 classic style.
You decide :)
 
maxman said:
Just made this pushback corner stable, I guess.
Click to expand...
Looking good. If I may add something, in fighting games the slide back after hit happens after the hit pause (on the target), not together with the hit.
Sometimes, the slide is a bit too big, both in normal attacks and on the corner push - mainly, the crouched upper.

And one last note: I feel there is a missin friction here, as the characters looks to slide on the same velocity during all the move, where it should gradually the reduced.
OpenBOR doesn't have a native friction, but fighting engines like mugen/ikemen does, where the crouch fritction is even greater than the standing one.

other than that, looks cool
 
O Ilusionista said:
Looking good. If I may add something, in fighting games the slide back after hit happens after the hit pause (on the target), not together with the hit.
Sometimes, the slide is a bit too big, both in normal attacks and on the corner push - mainly, the crouched upper.

And one last note: I feel there is a missin friction here, as the characters looks to slide on the same velocity during all the move, where it should gradually the reduced.
OpenBOR doesn't have a native friction, but fighting engines like mugen/ikemen does, where the crouch fritction is even greater than the standing one.

other than that, looks cool
Click to expand...
I had the exact same feeling.
We know where we come from... ^^

also, perhaps getting a wait to avoid getting so close from opponent. (depending on the size of characters.)
In this exemple, I fee like Ryu and Ken can get a little too close from each others.


But Excellent progress!!
I like where the project goes!
 
O Ilusionista said:
in fighting games the slide back after hit happens after the hit pause (on the target), not together with the hit.
Click to expand...
Yeah. I couldn't tell whether there's a pause time on the hit or not when it comes to attacks. Even with the shake, used with offsets (I have no time to add offsets for frames, but I just found out that using looper is the best solution for me to avoid frame redundancy. That way, I wouldn't add many frames with offsets for/in any animation). However, I was suggested to use a pause time for each hit, but I don't have time until there's a moment that I will make a release, like an alpha or beta. Not sure, though.

O Ilusionista said:
Sometimes, the slide is a bit too big, both in normal attacks and on the corner push - mainly, the crouched upper.
Click to expand...
I wasn't very certain how fast/slow I would change the speed for the pushback of each attack. Also, I forgot to remove unnecessary parameters I previously made for the pushback animation function which were for range attacks on screen boundaries, specifically from crouch/duck + heavy punch. I'm not using range attack of distance in animation script for the screen edges anymore. Now it's only with velocity in animation script, but it's reliable on doattack script. The ondoattack script was a lot more challenging than animation script because of the screen edges and the velocity movement together. So, I started creating an entityvar for a smooth movement.

O Ilusionista said:
And one last note: I feel there is a missin friction here, as the characters looks to slide on the same velocity during all the move, where it should gradually the reduced.
Click to expand...
If you only mean attacks on the velocity, I use velo001 for moving smoothly backwards in anim pain.

Code: 
anim    pain #L Get Hit Normal
    delay    8
    offset    336 292
#    platform 336 292 0 0 50 50 10 50
    bbox 316 194 39 101
    drawmethod fillcolor 255_0_0
    frame    data/chars/ken/cvs2_ken_558.png # 0
    @cmd velo001 -2 0 0
    frame    data/chars/ken/cvs2_ken_559.png # 1
    drawmethod fillcolor 255_0_0
    frame    data/chars/ken/cvs2_ken_559.png # 2
    @cmd stop
    frame    data/chars/ken/cvs2_ken_558.png # 3
    @cmd beidle
    frame    data/chars/ken/cvs2_ken_558.png # 4
    @cmd velo001 -2 0 0
    bbox 314 226 44 68
    frame data/CHARS/Ken/CVS2_Ken_567.png #5
    frame data/CHARS/Ken/CVS2_Ken_568.png # 6
    frame data/CHARS/Ken/CVS2_Ken_568.png # 7
    frame data/CHARS/Ken/CVS2_Ken_567.png # 8
    @cmd stop
    frame data/CHARS/Ken/CVS2_Ken_567.png # 9
    @cmd    keyint2 "ANI_DUCK" 2 "D" 0
    @cmd    keyint2 "ANI_FOLLOW6" 0 "D" 1
    bbox 0 0 0 0
    frame data/CHARS/Ken/CVS2_Ken_570.png # 8

This is the attacker's:
Code: 
anim attack #STAND LP
    offset 97 177
    delay 2
    bbox 84 79 39 98
    sound data/sounds/common/punch.wav
    @cmd    attack1 0 50 0 "ANI_ATTACK4"
    #@cmd attack1 0 50 0 openborconstant("ANI_ATTACK4")
    @cmd randSoundSF "Ryu" "SND_PL00_4.wav" "SND_PL00_5.wav" NULL()
    frame data/CHARS/ARyu/idlelp01.png
    attack 101 84 68 23 0 0 0 0 23 0 # 7 - damage
    @cmd antiscreen 3
    frame data/CHARS/ARyu/idlelp02.png
    frame data/CHARS/ARyu/idlelp03.png
    attack 0
    frame data/CHARS/ARyu/idlelp04.png
    bbox 81 80 37 97
    #@cmd stop
    frame data/CHARS/ARyu/idlelp05.png

Funnily enough, I put velo001 in the first frame of Ryu's anim pain, while I have it in the second frame of Ken's anim pain. But I will change and put it in the first frame, as well as the pause time.

Code: 
anim pain #Face 1-2-1
    offset 97 177
    delay 4
    #IDLE PAIN
    bbox 71 81 37 96
    @cmd    velo001 -2 0 0
    frame data/CHARS/ARyu/gethit00.png
    delay 7
    frame data/CHARS/ARyu/gethit01.png
    delay 5
    frame data/CHARS/ARyu/gethit01.png
    frame data/CHARS/ARyu/gethit00.png
    @cmd beidle
    frame data/CHARS/ARyu/gethit00.png
    #DUCK PAIN
    bbox 75 112 42 68
    @cmd    velo001 -2 0 0
    frame data/CHARS/ARyu/duckhit1.png
    frame data/CHARS/ARyu/duckhit2.png
    frame data/CHARS/ARyu/duckhit2.png
    frame data/CHARS/ARyu/duckhit1.png
    @cmd    keyint2 "ANI_DUCK" 2 "D" 0
    @cmd    keyint2 "ANI_FOLLOW6" 0 "D" 1
    #@cmd    keyint openborconstant("ANI_DUCK") 2 "D" 0 0
    #@cmd    keyint openborconstant("ANI_FOLLOW6") 0 "D" 1 0
    frame data/CHARS/ARyu/duckhit1.png

I checked and tried with the running brake script in another mod for practice, but I worry about adding the brake here because I'm using a nearly ten-year-old build and I don't know if it can work or not. There needs to be some velocity-related script to be reduced gradually with real time, along with screen edges, but I don't know if elapsed time can work. 🤨 What I have so far for the ondoattack on its velocity, is something I can't gradually reduce its speed in time. It's tricky. I don't know which animation should be reduced. It's either anim pain after a hit or the attacker being pushed back. Or it could be both. (How much speed should I reduce and which animation?)

O Ilusionista said:
OpenBOR doesn't have a native friction, but fighting engines like mugen/ikemen does, where the crouch fritction is even greater than the standing one.
Click to expand...
I know, but if you take a look at the original Final Fight arcade game, each player has a friction which both players can't pass through each other. DC is right on the money for saying it's scriptable.

NED said:
also, perhaps getting a wait to avoid getting so close from opponent. (depending on the size of characters.)
In this exemple, I fee like Ryu and Ken can get a little too close from each others.
Click to expand...
Something like being a bit distant away from getting way too close to each other, right? I use platform(s) as a blockade, mostly in anim idle. I've tried. It's the closest thing I've got as a friction in a one-on-one system, but the push-forward motion isn't implemented yet. There will be, though it's very challenging. ;)

Mr.Q! said:
Looking awesome, dude!
Click to expand...
Thanks, dude. Didn't expect you'd stop by here. :D Hahah. You can tell that the pushback looks like a real fighting game, though some speed will need to be adjusted. ;)

Thanks, guys.
 
  • Like
Reactions: NED
maxman said:
If you only mean attacks on the velocity, I use velo001 for moving smoothly backwards in anim pain.
Click to expand...
Checking your code, I saw that you use a negative velocity first

@cmd velo001 -2 0 0

Then you stop the character

@cmd stop

then apply the same velocity again

@cmd velo001 -2 0 0

And that is the problem: you are using just one single velocity, where you should reduce it in every frame (if you want to be more precise, over time, so you aren't tied to frames)

I've wrote a half baked* function that I use to simulate friction

C-like: 
void bmtFriction(float fX, float fY, float fZ)
{
// Reduces the actual velocity, simulating friction.
// Douglas Baldan - 13/01/2014
// http://www.brazilmugenteam.com
void self = getlocalvar("self");
float Xvel = getentityproperty(self, "xdir");// x velocity
float Yvel = getentityproperty(self, "tossv");// y velocity
float Zvel = getentityproperty(self, "zdir");// z velocity
changeentityproperty(self, "velocity", Xvel/fX, Yvel/fY, Zvel/fZ);
}

Usage:
@cmd bmtFriction 2 1 1
Your velocity will be reduced (divided) by each value. And then I use it on every frame I need.
There is a trick: if you have a frame with delay 20 and want it to be a smooth friction, divide your frames in smaller numbers.

So instead of using 1 frame with delay 20

delay 20
@cmd bmtFriction 2 1 1
frame bla bla bla
Click to expand...

use 4 frames with delay 5

delay 5
@cmd bmtFriction 2 1 1
frame bla bla bla
@cmd bmtFriction 2 1 1
frame bla bla bla
@cmd bmtFriction 2 1 1
frame bla bla bla
@cmd bmtFriction 2 1 1
frame bla bla bla
Click to expand...

*I say half baked because I haven't added any security check to it, so if you add 0 as any value, you would get a division by zero which probably will trigger a shutdown.

Also, I won't stop moving by using stop() function. velo001() function changes the entity velocity, while stop() change both velocity and speed:

C-like: 
void stop()
{// Stop hero's movement!
    void self = getlocalvar("self");
    changeentityproperty(self, "velocity", 0, 0, 0);
    changeentityproperty(self, "speed", 0); //Stop moving!
}
Most of time, I use stop only in projectiles, not on players/enemies. If I need to make a player to stop, I just set velo001 to 0:

@cmd velo001 0 NULL() NULL()
Using NULL() will not affect the other velocities, like your Y velocity.
 
  • Like
Reactions: NED
O Ilusionista said:
Checking your code, I saw that you use a negative velocity first

@cmd velo001 -2 0 0

Then you stop the character

@cmd stop

then apply the same velocity again

@cmd velo001 -2 0 0

And that is the problem: you are using just one single velocity, where you should reduce it in every frame (if you want to be more precise, over time, so you aren't tied to frames)

I've wrote a half baked* function that I use to simulate friction

C-like: 
void bmtFriction(float fX, float fY, float fZ)
{
// Reduces the actual velocity, simulating friction.
// Douglas Baldan - 13/01/2014
// http://www.brazilmugenteam.com
void self = getlocalvar("self");
float Xvel = getentityproperty(self, "xdir");// x velocity
float Yvel = getentityproperty(self, "tossv");// y velocity
float Zvel = getentityproperty(self, "zdir");// z velocity
changeentityproperty(self, "velocity", Xvel/fX, Yvel/fY, Zvel/fZ);
}

Usage:
@cmd bmtFriction 2 1 1
Your velocity will be reduced (divided) by each value. And then I use it on every frame I need.
There is a trick: if you have a frame with delay 20 and want it to be a smooth friction, divide your frames in smaller numbers.

So instead of using 1 frame with delay 20



use 4 frames with delay 5



*I say half baked because I haven't added any security check to it, so if you add 0 as any value, you would get a division by zero which probably will trigger a shutdown.

Also, I won't stop moving by using stop() function. velo001() function changes the entity velocity, while stop() change both velocity and speed:

C-like: 
void stop()
{// Stop hero's movement!
    void self = getlocalvar("self");
    changeentityproperty(self, "velocity", 0, 0, 0);
    changeentityproperty(self, "speed", 0); //Stop moving!
}
Most of time, I use stop only in projectiles, not on players/enemies. If I need to make a player to stop, I just set velo001 to 0:

@cmd velo001 0 NULL() NULL()
Using NULL() will not affect the other velocities, like your Y velocity.
Click to expand...


I actually wrote a space library, though mine is pretty custom, so I can't just dump it here and it work for you. What I would suggest is **not** setting velocity every frame from the animation. Instead, place the behavior in the entity’s update logic and use an entity var to toggle it on or off.

Multiply the velocity by roughly 0.9 each update. You may need to experiment a little to get the exact slowdown rate you want, then force the velocity to 0 once it drops below a small threshold. That is basically how friction systems handle movement, and it is also similar in concept to how OpenBOR handles gravity. Once tuned, it feels butter smooth and becomes fire-and-forget.

Notice I said multiply, not divide. This is a general programming rule, not an OpenBOR rule. Depending on the CPU and runtime, multiplication is often a little faster than division - and at minimum it's just as fast, so whenever you need fractional adjustment, prefer multiplying by a decimal factor instead of dividing. It's only a tiny optimization, but it's free. :)

DC
 
DCurrent said:
Notice I said multiply, not divide. This is a general programming rule, not an OpenBOR rule. Depending on the CPU and runtime, multiplication is often a little faster than division - and at minimum it's just as fast, so whenever you need fractional adjustment, prefer multiplying by a decimal factor instead of dividing. It's only a tiny optimization, but it's free. :)
Click to expand...
ah yeah I am aware of this. Keep in mind that I made that funcion back in 2014, I was more stupid back then (I am just a little less, but still haha)
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom