One thing to watch out for is how Unity handles I/O. I don't know how true it is now, but I experimented with Unity a couple of years ago and the input handling had enough latency to make it unusable for a fighting game (it ended up being effectively something like 30hz or something awful). They may have addressed that in later builds, but there's no point in doing something that requires the precision of a fighting game with I/O latency like that. I know I've played a couple of music-rhythm games built in Unity and they always felt kind of jank.Damn, the put-downs in this thread today. :O
So I'm tinkering with Unity at the moment. It's a cool program and I think there's a neat fighting game engine in there waiting to be discovered.
There is already a FG engine in Unity, but it uses hitcircles attached to animation limbs for detection, which is dumb. Hitboxes should have nothing to do with the animation in a 2D game. That's because, functionally, a 2D game using sprites and a 2D game using animations should be identical. The game is really about boxes moving around on a screen, but you understand what the boxes are via the characters.
Anyway, I'm running through the basic 2D tutorial stuff at the moment and the rudiments of a 2D hitbox system are already in there via 2D box colliders.
I'm going to try and make something neat for Christmas-time using sprite rips as a proof of concept. Provided NaNoWriMo doesn't kill me.