You're asking some pretty broad questions, so I'm not quite sure how best to guide you. I'm the programmer on Aztez, which is a beat-em-up made with Unity. Some footage: http://www.youtube.com/watch?v=efwB-pv3QV4
(that's Ben, the artist, talking over the video).
Some random pieces of info. Feel free to ask any direct questions about how I've set any of this up:
- Everything is 3D, rendering to a normal perspective camera
- Characters are a single RigidBody with a capsule collider. We don't use CharacterController
- Enemies don't collide with each other, or hit each other. We use layers and the "Layer Collision Matrix" in physics setup to do this. Layer-wise, we have:
* Player, Player No Collide, Player Attack, Player Sensor
* Enemy, Enemy No Collide, Enemy Attack, Enemy Sensor
- Player is for the player, which collides with Enemy and Enemy Attack. "Player No Collide" is a layer that doesn't
collide with Enemy. Some moves set this (ie a dash or a dive roll you want to move through an Enemy).
- Most everything in the game is a "Move", including some non-attacking animations (getting up, etc). A move is a character animation clip synced with a prefab. The prefab contains all of the hitboxes, links, etc. The hitboxes are sometimes animated within Unity. We animated quite a lot of things in the animation editor (like toggling booleans for when hitboxes are active).
- Unified architecture helps. It's actually not a small amount of code, which makes it pretty densely packed, but it means I only have to write debug/etc tools once
- Gizmos are your friend for visualizing all of this.
- We use animation events to trigger code-related changes during move animations. These are super great: http://docs.unity3d.com/Documentation/Components/animeditor-AnimationEvents.html
- The game has a very generic list of "states" for characters. Really, it's just an array of strings. Moves can ignore collisions based on states, or require a state to fire in the first place, etc.
- There's a list of moves that are always available to the player. There are "link" objects as part of a move that will add to the list of possible moves for a short duration. All combos are handled this way.
- The same input may trigger multiple moves at any given time. Moves have a priority, which determines which move actually fires.
- Required states are used heavily to manage different moves from the same input. An opening (always available) move might require the "Airborne" state, and have a higher priority, which means the same button is a simple ground swipe or an air swipe, depending.
Let me know how else I can help!