3D Fighting Game Development: From Character Design to Combat System Implementation

1. Project Goals and Overall Architecture

A 3D fighting game requires an interaction system that combines complete combat logic, differentiated character design, multiple AI difficulty tiers, and responsive controls. The project described here is built around an anime-style, all-female fighter theme, with the core goal of real-time battles between two distinct characters—Yin Shilin and Jiang Yina—on a rainy rooftop stage, supporting both single-player AI challenges and local two-player versus modes.

The overall technical architecture is divided into three layers:

• Presentation layer: character skeletal animation, particle effects, scene rendering, and UI interaction
• Logic layer: state machine management, collision detection, damage calculation, and combo detection
• Data layer: character attribute configuration, move frame-data tables, and AI behavior tree parameters

This layered design decouples combat logic from rendering, making it easier to debug each part independently and to add new characters.

2. Character System Design

2.1 Differentiated Character Design

The two characters differ not only in their visual models but, more importantly, in numerically defined fighting styles:

Attribute	Yin Shilin (Power Type)	Jiang Yina (Speed Type)
Base HP	1200	950
Move speed	3.2 m/s	4.5 m/s
Per-hit damage multiplier	1.2	0.85
Attack startup frames	12	7
Stun recovery time	0.6s	0.35s

The power-type character emphasizes high single-hit damage and pressure, while the speed-type character builds combo advantage through fast startup and agile movement. This differentiation means players must adopt completely different strategies depending on their character choice.

2.2 Skeletal Animation State Machine

Every character action is managed by a finite state machine (FSM) with these core states:

• Idle
• WalkForward / WalkBackward
• Jump / JumpAttack
• Crouch
• LightAttack / HeavyAttack
• SpecialMove
• HitStun / BlockStun
• Knockdown / GetUp

State transitions are driven jointly by player input, frame counters, and collision events. For example, if a light attack lands within the combo window—while the opponent is in hit-stun but not knocked down—the FSM can force a transition into the next attack state to chain a combo.

3. Combat Mechanics and Controls

3.1 Core Command Set

The game follows classic fighting game input conventions, mapped to keyboard or gamepad:

1. Block: Hold the block button (gamepad L2, for example) to enter guard stance. Blocked attacks deal 70% less damage but drain the guard gauge—continuous blocking leads to a guard break.
2. Throw: Press Light Punch + Light Kick near an opponent. Throws deal unavoidable damage to blocking opponents, and the attacker is invincible during the throw animation.
3. Jump: Pressing the jump button enters a jump state with roughly 0.8 m of height and 0.5 s of air time; attack commands can be executed mid-air.
4. Dash: Double-tap forward or back to slide quickly for 0.3 s, with brief invincibility frames (about 6 frames) for evading attacks or closing distance.
5. Launch (juggle): A heavy attack that connects against an airborne target triggers a float state; the target cannot act until landing.

3.2 Motion-Input Special Moves

Special moves use the classic “directional motion + attack button” input scheme. Examples:

• Fireball-type: ↓ ↘ → (quarter-circle forward) + Light Punch (ranged projectile)
• Rising uppercut-type: → ↓ ↘ + Heavy Kick (invincible rising attack)
• Spinning kick-type: ← ↙ ↓ ↘ → + Light Kick (multi-hit close-range strike)

Input recognition is implemented with a sliding input buffer: the system records the button sequence from the last 15 frames and matches it against the move table to trigger the corresponding skill. This satisfies the muscle memory of experienced fighting game players while lowering the learning curve for newcomers.

3.3 Meter-Based Super Moves and Cinematic Cameras

Super moves require a full super meter (built by landing hits, taking hits, and blocking). Activation triggers the following sequence:

1. Global pause: combat logic freezes while the attacker plays a charge close-up (the camera rapidly zooms in on the character’s face)
2. Skill judgment: after the close-up, the super move animation executes; it covers a frontal cone area and typically carries 3–4 hit judgments
3. Finisher presentation: if the final hit connects and the opponent’s HP reaches zero, a slow-motion KO cinematic plays, with the camera orbiting to showcase the character’s victory pose

The cinematic camera is implemented with a virtual camera (CineCamera) that supports time scaling (Time.timeScale = 0.3) and depth-of-field effects for extra visual impact.

4. Tiered AI Design

Single-player mode offers Easy, Normal, and Hard AI, built on a hybrid framework combining behavior trees with a finite state machine.

4.1 AI Decision Tiers

• Easy: 300 ms response delay, low attack frequency (2.5 attacks per second on average), prefers ranged pokes, never uses throws or special moves, and reacts to blocking slowly
• Normal: 150 ms response delay, attack frequency raised to 4 per second, switches skill combinations based on distance, anti-airs when the player jumps, and prioritizes the super move when the meter is full
• Hard: only a 50 ms response delay, precisely evades predictable attacks, runs preset combo strategies (up to 6 hits), reads and counters throws through prediction, and punishes quickly after blocking (frame-advantage pressure)

4.2 AI Behavior Tree Example

Root
├── Condition: distance > 2.5m
│   └── Action: advance + ranged poke
├── Condition: distance ≤ 2.5m AND player is attacking
│   ├── Random execution:
│   │   ├── Block (weight 30%)
│   │   ├── Evasive dash (weight 20%)
│   │   └── Counter attack (weight 50%)
└── Condition: meter full AND random number > 0.7
    └── Action: fire the super move

On Hard mode, the AI also leverages the concept of “frame advantage”: when its attack is blocked, it predicts the opponent’s punish window and either attacks first or re-applies pressure, simulating the neutral-game mindset of an expert human player.

5. Two-Player Mode and Match Flow

5.1 Local Two-Player Versus

Two-player mode is implemented by extending the input mapping. Player 1 uses WASD + J/K/L on the keyboard, while Player 2 uses the arrow keys + numeric keypad 1/2/3. The game loop reads both independent input devices every frame, and the two input buffers do not interfere with each other.

5.2 Best-of-Three Match Format

The match flow works as follows:

1. Character select: each side picks their character from the two available (mirror matches are allowed)
2. Round start: a 3-second countdown leads into a “Ready? Go!” prompt
3. During the round: each round is limited to 99 seconds; on timeout, the winner is decided by remaining HP percentage
4. Round end: the results screen compares both sides’ damage output and combo counts; the round winner gains 1 point, and the first to 2 points wins the match
5. Pause and restart: either player’s pause button freezes both players’ inputs and the timer simultaneously, preventing one-sided pause abuse

6. Game Flow and State Management

6.1 Scenes and State Transitions

The game’s core states are MainMenu, CharacterSelect, Battle, Pause, and MatchResult. The main menu displays character art and the stage background (the rainy rooftop). Entering character select lets both players lock in their choices with a confirm button, after which the battle scene loads.

6.2 Rainy Rooftop Stage Rendering

The stage environment includes a dynamic rain particle system, a reflective floor (captured via a real-time reflection probe), and a mix of warm streetlamp light with cool-toned ambient light. Invisible walls define the combat area’s collision boundaries and restrict character movement, and the ground friction coefficient is set to 0.8 to keep characters from sliding too far.

7. Technical Challenges and Optimization

7.1 Fixed-Timestep Simulation

To keep the two-player experience consistent, combat logic runs on a fixed timestep (16.67 ms per logic frame). All judgment and input processing happens within logic frames, while render frames only interpolate for display. This design eliminates speed differences across devices with different refresh rates.

7.2 Hitbox Optimization

Combat detection uses three capsules: a body collider (for movement limits), an attack hitbox (whose size changes per move), and a hurtbox (the region that takes damage). The attack hitbox is activated only on key frames, reducing physics computation overhead.

7.3 Memory and Loading Strategy

Character animations use a bone-based compressed format (animation keyframes store rotation data only), and scene textures use ASTC compression. The battle scene loads asynchronously, keeping the maximum wait during scene transitions under 1.2 seconds.

8. Conclusion and Extension Ideas

The core value of this project is its complete coverage of the implementation path for a 3D fighting game, from basic controls to advanced mechanics. Developers who want to go deeper can extend it in these directions:

1. Online play: add latency compensation on top of the fixed-timestep simulation to enable remote matches
2. More characters: expand the roster quickly with a data-driven approach (JSON-defined character attributes and move tables)
3. Spectating and replays: record keyframe data streams of battles to support full replays and slow-motion analysis
4. Tournament mode: add esports-oriented features such as elimination brackets and character switching between matches

Fighting games are the genre that most stress-tests the rigor of systems design within action games. The concepts covered here—state machines, frame data, and AI decision-making—apply equally to action RPGs, side-scrolling shooters, and other action-oriented games. With a modular architecture and data-driven design, developers can efficiently build a game with a professional-grade combat experience.