Guys in this point of development I would appreciate feedback and suggestions a lot more then critiques. I’m trying to build a good product for all of us here!
I always though that was the case (what you said above about frame rate), I am glad you were able to confirm that notion for me.
No, take the “frame advantage” option out as with it, the engine is just plain broken.
Although I agree its not the most reliable, I don’t think its plain broken.
But to be honest I don’t think I can discuss it without the aggressive tone going any lower lol
It does not account for move cancels, but I think we can leave at that.
Small question guys: What sounds more familiar to you? Hit stun in seconds or in frames?
frames!
it would be great if the program itself could program in terms of hitstun/blockstun, and then translate it into theoretical earliest frame advantage and display it using the typical way of calculating it [stun - (earliest active frame - time until it recovers from earliest active frame)]
I believe the issue is that having “frame advantage” as a static number contradicts the idea that it’s simply the difference of block or hit stun and the recovery frames of a move.
This can be expressed as:
x - y = z
where:
x: block/hit stun frames
y: recovery frames
z: frame advantage
Take note that this doesn’t even take into account when the move hits (hitting earlier or later could result in more or less recovery) and where (distance is also a factor).
Now, by adjusting z, the system will have to tweak either x or y. Now from your example, it seems that the system tweaks x. The issue we’re seeing from your example is that the system seems to vary the hit/blockstun depending on when a move hits to satisfy the set value of z as seen in your example.
Here we see the system giving a move 6 frames of hit stun to satisfy the set frame advantage value of +2 and I’m assuming that it’ll vary the hitstun to always make it +2. This sort of goes against how this thing traditionally works. For one, it takes away the players ability to adjust their timing to hopefully make things safer.
Now if we did this traditionally, say the same 20 frame move. From the values given, we can assume 6 frames of hitstun from 4 frames of recovery from frame 16. However, consider that the move has more active frames than just frame 16. If the move hits at frame 14, then the frame advantage goes down to 0. If the move hits at first active frame, then the move is now at -6. The move now then goes from a pretty, for lack of a better term, “YOLO” that always has 2 frames of advantage to an unsafe move that good player would time right to hit within frames 15 to 16 to get frame advantage.
This becomes even more important when it comes to chip and block strings. With set frame advantage, it becomes a bit too easy to set up long blockstrings and lockdown tactics, even with pushback since the blockstun remains constant regardless of timing and distance.
EDIT: I also realize that said 20 frame move would be a bad move in any traditional 2D fighter. This is why outside of stuff NRS makes (which in no shape and form should be looked at as an example of good 2DFG design from a technical POV), you rarely see moves that take up that much time, and any such move usually has multiple hits or really long reach.
I appreciate why it shouldn’t be that way in existing fighting games and honestly can’t think of a reason I would use it myself, BUT we shouldn’t be trying to stifle options that other people may want to use (possibly even to good effect). As long as the current way of doing things (ie., the engine NOT setting frame advantage and it being a natural effect of hit/block stun) is available, then there’s no harm in keeping the additional method.
I still have my misgivings about it and think that it can lead to some jankyness. I mean, what’s to stop the system from coming up with a solution that leads to 0 or negative block/hit stun (i.e. a move with 4 frames of recovery being set to -4 or even -5). Thought I guess it’s really not the engine’s job to prevent people from creating BS situations.
I understand. As I said I can’t really think of a use for it, but that doesn’t mean someone won’t.
Also assuming the two methods are interchangeable it might be useful for some specific moves without the whole game being like that. I dunno, maybe some kind of Focus/CD/Alpha-counter/catch-grab/etc. situation.
I love fighting games and I like SRK but there is a lot of resistance to anything outside the box just because it’s different. One of the joys of fighting games for me is exploring the systems and how varied they can be; I am very glad we are past the SF2 clone era of fighting games but I feel like some people want to go back and stay there.
Maybe nothing good will come from that specific option, but no bad will come from it being included (people will make shitty games/mechanics/decisions regardless).
I’d rather games stick to what makes SF2 so good rather than introduce a bunch of stupid game mechanics just because. SF2 is a far superior game to most of the crap out these days.
aren’t you a mod here or something? where do you get off being this big of a tool. you have not even tried this program out yet
it still does 85% of the ground work for you, and a tiny bit of coding would fix this. chill out.
I must admit, as a developer I was very surprised by the reception in that sense. Not all of you of course.
Btw the tool now accepts raw hit stun. Its all documented here:
http://www.ufe3d.com/doku.php/move:activeframes
Universal Fighting Engine has been released!
http://forum.unity3d.com/threads/202223-W-I-P-2-5D-Fighting-Game-Framework
Well, we’re a community that is very, very passionate about fighting games, and since that passion involves competition, we do tend to spend alot of time studying and dissecting them to figure out how they work.
New video!
Can things like the jump physics and camera angle be adjusted? Those jumps look mad floaty (even worse than SFIV) and the camera angle seems off somehow. I think the latter needs to be slightly lower to the ground and at a slightly different angle.
The problem I think is that the camera has the characters at the center, with a good amount of the floor visible. Compare with how the camera is set here.
Where the characters are more or less in the lower half of the screen no matter how far or close the zoom is. More importantly, you can see by looking at the floor that the camera isn’t set that high.
EDIT: Also, the hitstop, can this be adjusted as well? There seems to be way too much in that vid.
Everything can be adjusted. Literally everything =)
I often tell people this:
As you can clearly see, not even I, the creator of the engine, can do a good job at editing the moves and combos. That’s where you guys come in.
Take a good look at www.ufe3d.com and see all the things that can be done.
I believe I linked the hitbox editor page here before, but just for the sake of it:
http://www.ufe3d.com/doku.php/character:hitbox
All prices reduced and pro (non core) version released!
Pro Version - $95,00
Pro Source Version - $179,00
Soon another version (basic) for $55
Few updates guys:
Input Leniency added to UFE.
http://forum.unity3d.com/attachment.php?attachmentid=80305&d=1388201526
For more on Input Leniency, check out this link:
http://www.eventhubs.com/guides/2010/jan/11/understanding-input-leniency-street-fighter-4/
Also, playable demo should be coming tomorrow! I’ll share the link with you guys as soon as its up!