Fighters Paradise: Modern Game Engine Reimplementation in Rust

Problem

MUGEN is a legendary 2D fighting game engine from 1999 that spawned one of the largest community content libraries in gaming history. Thousands of characters, stages, and modifications exist, but the engine itself is closed-source, Windows-only, and showing its age. Running legacy content on modern systems is increasingly problematic.

I wanted to build a modern, cross-platform engine that could preserve this massive community archive while leveraging contemporary systems programming practices. The challenge was significant: MUGEN’s file formats are partially documented at best, the engine’s behavior is the de facto specification, and fighting games demand frame-perfect determinism. Any reimplementation needs to match MUGEN’s exact 60Hz timing or existing content behaves incorrectly.

Beyond preservation, this project let me dive deep into game engine architecture, GPU rendering pipelines, and the systems programming that Rust excels at. Building a fighting game engine touches nearly every domain of systems programming: binary parsing, real-time rendering, physics simulation, input handling, and state machine design.

Approach

I structured Fighters Paradise as a Cargo workspace with 14 specialized crates, each with clear boundaries and responsibilities. This modular approach lets me develop incrementally, completing sprite rendering before tackling physics, then input handling, and eventually combat systems, while maintaining a clean architecture that mirrors how professional game engines separate concerns.

Key Design Elements

• Fixed 60Hz timestep: Fighting games require deterministic simulation. I implemented a fixed timestep loop that guarantees exactly 60 ticks per second, matching MUGEN’s original behavior so existing content plays correctly.

• GPU palette lookup shader: MUGEN sprites use 256-color indexed palettes, enabling palette swaps without modifying textures. I wrote a WGSL shader that performs palette lookup on the GPU, avoiding expensive texture re-uploads when swapping character colors.

• Defensive parsing: Community-created MUGEN content often contains malformed or edge-case data. Rather than crashing on unexpected input, my parsers substitute safe defaults and continue, prioritizing robustness over strictness.

• Binary format reverse engineering: SFF v2 files use multiple compression schemes (RLE5, RLE8, LZ5). I implemented decompressors from scratch based on format documentation and empirical testing against real content.

The input system uses a 60-frame ring buffer that captures the complete recent history needed for command recognition. Fighting game inputs like “quarter-circle forward + punch” require detecting specific sequences within timing windows. The buffer approach lets me pattern-match against recent input history efficiently.

Outcomes

• Playable prototype: Characters render, animate, walk, jump, and crouch with keyboard input. The core rendering and input pipeline is complete.

• Comprehensive format support: Four MUGEN file formats fully parsed: binary sprite containers (SFF v2), animation definitions (AIR), command sequences (CMD), and configuration files (DEF).

• Robust test coverage: 131 tests across the workspace validate parsing correctness, rendering behavior, and input handling.

Key Contributions

• Designed modular 14-crate workspace architecture that separates game engine concerns (rendering, physics, input, combat) into independently testable components

• Implemented wgpu rendering pipeline with custom WGSL shaders for indexed palette lookup, supporting blend modes and collision box visualization

• Built comprehensive binary parsers for undocumented SFF v2 format including RLE5, RLE8, and LZ5 decompression

• Created input buffering system with 60-frame ring buffer and pattern-matching command recognition for fighting game inputs

• Engineered graceful error handling throughout parsers to handle malformed community content without crashing

• Documented architecture decisions including format specifications derived from reverse engineering efforts

What I Learned

Reverse engineering MUGEN’s binary formats was harder than I expected, and not in the ways I anticipated. The community documentation is extensive, but it documents what people observed rather than what the original authors intended — which means edge cases are underdocumented by definition. The real specification is the behavior of the original engine, and the only way to test against it is to run content through both implementations and compare outputs. I spent more time on empirical testing against real community files than on reading any spec.

The GPU palette shader was the most satisfying design decision to get right. MUGEN’s indexed color model — where sprites are 256-color palettes that swap at runtime — looked like a constraint at first. It turned out to be elegant: the GPU lookup table approach lets character color variants happen at zero cost. I’d have designed it differently if I hadn’t been forced to understand the legacy format first.

What I’d do differently: start with the state machine design before touching rendering. I built the sprite pipeline first because it was concrete and testable, but the state machine is what actually makes a fighting game a fighting game. Getting rendering working early felt like progress; it was actually deferred complexity. The architecture handles it, but the sequencing meant I had a beautiful renderer with no combat logic for longer than I’d like to admit.