Cool!
Make it 2.5D
Hold back to block. Dont implement a blocking button
What type of game are you aiming to make? Team based like the vs series? 3v3 via KOF? 1on1? 2v2 Tag? Variable size like Skullgirls?
Most importantly, get together with a good artist or two, and start hashing out some character concepts/playstyle achetypes. Even if your mechanics are solid, the game will flop in the long run if the characters are of a boring design. Terrible characters was death blow number 2 for Fighter Within. If the game wouldnt have been on Kinect in the first place, the characters wouldve gotten the game laughed out of the genre.
Are you making some sort of template engine for a fighter in UE4?
At this moment in your plan, how much input do you want from us? A lot of us have our own ideas for what the perfect fighting game system is(I just saved a .txt). It’d probably be better if we started with yours. If you’re looking to create a system completely through democratic means, I can see this easily becoming an incongruous hodge-podge of mechanics.
What is your most favorite fighting game and what do you like most about it? What characters do you tend to play? What aspect of fighting games do you find the most fun? The most skillful? Do you feel the depth added(if any at all) by execution barriers outweighs the increased player base due to easier inputs(ranging from SF4 leniency to Smash Bros inputs)?
Who the hello disagrees with a suggestion for holding back to block?
We already have stuff like this with EF-12 (for 3D) and UFS for Unity (for 2D/2.5). However, these don’t seem to be taking the MUGEN route and seem to be geared more for making complete games than just adding in fighters.
Guilty Gear X-rd was made on the unreal engine, it may be noteworthy to look into how they made it.
Please please please, do not use Street Fighter 4’s 60 fps gameplay as a framework for game speed and frame data. Instead, why not go for fast and fluid physics like what is found in KI or Xrd?
There are movement and attack options you can implement to keep the intensity going even on knockdown. Simple input commands allow the grounded player to utilize techniques such as quick-get up, tech rolling, and wake-up specials with large hitboxes/invincible properties (ie Sabrewulf’s Eclipse). Also, not just air-dashes but INSTANT air dashes (Injustice pls).
It is a bit redundant to state this as a competitive player, but please take the extra mile in getting both the math and science of fighting games accessible to all who buy your game.
-Frame Data
-Damage/stun values
-Hitbox display
-Replays
-Online training
-all-encompassing tutorials
All in-game. All available on launch day. Remember that there will be scrubs lurking on Steam discussions/Gamefaqs/brony forums. Yes, I am using a pejorative to describe some of your potential buyers, but it is important that EVERY type of person who plays your fighting game are on the same page when learning the game. If you want to dismantle the emotional and “singular” path to reaching tournament level skill, why not take the approach of making a tag team-based 2D fighter like SFxT? If 4 players are not enough, you can try the KOF 3v3 standard. If there is one thing fighting games need, it is 8-player lobbies that are not just two competitors and six spectators.
Game speed has nothing to do with framerate implementation.
I wasn’t asserting implying that game speed and frame data are not mutually exclusive. By “60 fps” I only meant how SF4 runs. I probably shouldn’t have used the word “frame” 3 times in one sentence…
So are you saying he SHOULDN’T make the game 60 frames per second?
Shit dawg give me locked 120 fps and you will win the hearts of PC gamers!
I guess instead of “60 fps” i should have used “gameplay”.
It’s great to see the discussion begin to take off here. I am going to do another blogpost to lay out the goals and scope of the project , but in the meantime, I’ll try to address a few of the topics brought up already.
Parries are a feature I want to try to do at some point. I have come up with a couple of different ideas on how to implement them that might be interesting.
That is probably a good way to look at it. The goal is to create a solid framework of core features and build on it over time. There are no plans for specific character designs at this point, but I do want to build in the functionality that will allow for character variation.
Character creation is going to be a tall order. Probably not so much of a mode within the game, but instead what I am hoping is that once the framework has been built, anyone with UE4 can then create or modify characters in some fashion.
I definitely want to explore network play at some point. Probably won’t be for a while.
My plan is to implement both and provide the option for one or the other. The idea is that I will show how one is done, and then how that is built upon to implement the other. Sorry, but over the weekend, I started with Button Guard. 
Button Guard seemed to be the most straightforward of the two, as it does not require some sort of attacking trigger event.
I hesitate to use the term “template” as it has a very specific meaning here at Epic. I am going with “framework.” If this all goes to plan, then there is a chance it could be turned into a template.
I will read and consider every post made to this thread. I may not respond to every point.
Right now, I am looking to get back to basics: a simple, good feeling control scheme and solid, reliable collision resolution. I am sharing the process because I really want to see the community pick this up and run with it. I can’t wait to see what features/systems people come up with.
I’m old school. My favorites are still some of the games from back in the day. What I really like about some of the classics is that if a player knew the basic moveset well enough, he had a chance of competing.
Execution is a tricky topic. Too strict and the game doesn’t feel reliable and becomes frustrating. Too lenient and things can devolve into a special move fest. You want to promote skill, but also be accessible. A very tough line to walk.
60fps is the target frame rate.
In terms of gameplay speed, I would prefer to see something a bit more paced. Less about reaction time and more about knowledge of the moveset. We’ll see how that pans out…
@anoon
If you want to implement parries i will recomend to see how Battle Fantasia did them (the 3s way is just horrid, imo).
Besides that good luck with your project.
On the topic of blocking. DO NOT do both. Games with back blocking have a prominent mixups/crossups feature. Having both will break game flow between matches since you have to have entirely different setups for guys with button blocking. Not to mention, button blocking is pretty much a free guard. At that point you will have to implement a guard meter. Hold back to block is the more popular of the two and there’s nothing wrong with how it works. Pick one and stick with it. Just remember that for every new feature you add to a fighter, you have to add another to balance it out.
You should really read the anoon’s opening post before you start posting suggestions. You seem to be under the impression that he is making a fighting game. Which he is not. He is building a framework from which someone, anyone, could build a fighting game. When you’re making a system like that, the obvious choice is to allow for many different options, so people can tweak this framework in whatever way they like. And thus: Both hold back to block and button block would be implemented.
I’m looking forward to how this stuff is going to pan out. Personally something I’d be interested in seeing in a 2D fighter with a 3D engine, is a less clumsy form of implementation of hitboxes compared to SF4.
While 2D fighters can work with 3D hit detection (like the Street Fighter EX series), I really feel like hit detection in the 2D plane makes it feel a lot more solid and oldschool. I’d like to see some way of being able to draw customized 2D hitboxes projected onto animations, rather than the (partially) automatically rendered hitboxes as in SF4, which give kind of odd situations.
How exactly to go about that in a 3D engine without the hitboxes etc. to completely break whenever you tweak the speed of an animation, I don’t know, but I’d like to see you try!
I think that there are other ways for the button blocking to work besides a guard bar (which there are no problems with them when done right), for example mk9 doesn’t allow you to break throws when blocking.
The reason most of use aren’t too fond of a block button is the fact that it dumbs down defense and makes blocking too strong. Instead of having 4 distinct blocking states (left high, right high, left low, right low), 6 if you add air blocking, a block button reduces this to two, removing the possibility for crossups. Even NRS knows this which is why MK has big chip damage.
Collision is going to be a critical task.
My experience with SF4 is pretty limited. I’d be interested in hearing what you think is “clumsy” about their collision. Is there reference out there that details, (and possibly diagrams,) how they are implemented?
What I don’t want to/won’t do, is simple attach collision spheres to joints. I believe many early 3D fighters may have went this route. What I am thinking is that there will be collision volumes, (boxes,) that are laid over the model for each move, independent of the character rig. Basically, taking the collision systems of 2D games and extruding into 3D. Since the players will effectively locked onto a plane, the game play will resolve in a 2D fashion.
Now, how those volumes are created remains to be seen. The fallback plan is to create them in conjunction with the animations if I absolutely have to, but this is not optimal. This would require that each tweak to the collision would require expensive art software that demands some level of expertise to use, not to mention adding the whole export process to the pipeline…
What I would prefer to do is come up with a method for creating collision volumes within Unreal 4. What that looks like, I don’t yet know. It would be the most flexible and permit rapid iteration for anyone with the editor.
Well, recently someone wrote a hitbox viewer tool: http://youtu.be/_PcfslZj8Xc
The thing that happens in SF4 is that, a lot of the hitboxes are automatically generated to follow certain parts of the rig. Perhaps it’s connected to the joints of the skeleton, but it seems to also look at how big the polygons are on the screen of the mesh attached to the skeleton.
In that video most hitboxes are more or less pre-programmed. how it works exactly, I’m not sure, but it often follows subtle movements of the model, which I don’t think is something you’d want.
It gets even stranger during hitstuns, where the hurtboxes start to cling very closely to the mesh. From there you get a really odd situations where you can suddenly hit the hands of someone’s body, or the head that is bobbing back and forth.
It’s also the reason why cr.LK cr.LK strings on Dictator act a little strange. Dictator stand very widelegged, and as soon as he is in hitstun the space in between his legs is no longer hittable because the hurtboxes follow his legs, so it can happen that you do cr.LK, and the attackbox of the second cr.LK actually whiffs in between the legs of Dictator. That looks very funny, and is not something you’d want.
Incidentally, on the subject of hitspheres. Marvel versus Capcom 3 actually uses hitspheres drawn onto the 3d Model (but function in a 2d plane). The PS vita versus of MvC3 actually comes with a hitbox viewer (and you should also be able to find videos of that on youtube)
It’s important to realize though that projecting it onto a 2D plane is important (at least, if you want to give it the 2D feel). If for example you would give a attackbox to a tatsumaki that spins around, and it would also be active while the foot is pointing forward or backward, the move would be able to hit wider (in the z-depth) characters earlier than less wide characters, which would end up giving strange fluctuations in startup and frame advantage of a move.
I hope that makes sense. I notice that I don’t have the technical vocabulary to talk about this stuff at all.
SF4 is tight. phoenix may disagree with character priority or balancing aspects or something but collision is consistent. Unless he’s talking about unblockables which has nothing to do with collision its a bug in the engine that makes it so the character doesn’t know what way to face.
One of the many reasons I’m all about the guard button left right crossups IS a old mechanic leftover from games with poopy collision purposely perpetuating it is redundant IMO high low throw is fine enough
early 3d fighters at least tekken and vf used boxes just like SF
I dont imagine they’d change ue4 much from 3 creating collision boxes is nothing you just pop in the collision box and boop its there. The hard part is gonna be scripting that shit.