An open-source 3D platform fighter built around expressive movement, knockback, and compact hero-style kits.
SlopArena takes the platform-fighter fundamentals of movement, damage percent, recovery, edge pressure, and launching opponents off the stage, then gives each fighter a small set of distinctive specials and tools to play around.
The goal is a game that is readable and competitive without taking itself too seriously: strong character identities, generous 3D hitboxes, expressive movement, and plenty of room for stupid things to happen.
Current state: SlopArena is preparing a playable friends demo with four admitted cooked demo-roster packages: FightGuy, Manki, Wibou, and Bonk. Package admission does not prove kit completeness or player acceptance. Character execution is cooked-only; Nilus and the old LMB combo compatibility path were retired on 2026-10-02. See the playable friends demo reset for current product work.
SlopArena combines:
- camera-relative 8-direction movement, jump arcs, double jumps, fast-fall, ledges, and Dash;
- Smash-style damage percent, Knockback, Hitstun, Hitstop, Combo Influence, Clash, and Burst;
- readable hero kits with generous 3D hitboxes and meaningful recovery, zoning, and finisher choices;
- a server-authoritative GameServer for online matches and a local Shared simulation for prediction and training.
Each kit has a canonical 16-entry grid: grounded and aerial variants for normals 1, 2, 3, 4 and specials A, E, R, F. LMB and RMB are not persisted move identities; physical controls map to the canonical slots through the client input layer.
Solo always uses the heuristic CPU at the selected difficulty; Training starts with an idle dummy and exposes its AI mode in the pause-menu training settings.
Left Stick moves; Right Stick controls the camera and ability aim. Face buttons South/East/West/North use normals 1/2/3/4; hold LB with those buttons for specials A/E/R/F. The selected move stays fixed until its face button is released. RB jumps, LT crouches/slides/fast-falls, RT dashes, D-pad Left bursts, L3 faces the camera, R3 toggles target lock, and Start pauses. Remap buttons and the special modifier under Settings → Controls → Controller.
| Fighter | Style | Content status |
|---|---|---|
| FightGuy | Close-range martial-arts brawler with Ki Shot, Rising Dragon, Cyclone Kick, and Fist of Fury | Admitted cooked package |
| Manki | Explosive all-rounder / jetpack-bazooka skirmisher with bombs and aerosol area denial | Admitted cooked package |
| Wibou | Mid-range kitsune sword-spacing duelist focused on launches and air juggles | Admitted cooked package |
| Bonk | Greatsword fighter with sword-reach normals, targeted jump-slam recovery, and Blade Storm | Admitted cooked package; avatar visual/pose review pending |
Package admission identifies content accepted by the cooked roster manifest; it does not by itself establish kit completeness or player acceptance.
The game is built in Unity 6 with a pure C# simulation shared by the client and GameServer. The simulation advances at 60 Hz, keeps gameplay deterministic, and supports client prediction with server reconciliation and rollback.
git clone https://github.com/Binoui/SlopArena.git
cd SlopArenaInstall Unity 6000.0.78f1 and .NET SDK 8. Open client/Unity/ in Unity Hub and press Play for the local training flow.
Build the simulation and run its tests from the repository root:
dotnet build src/Shared/ --nologo
dotnet test tests/Shared.Tests/ --nologo
dotnet build src/Server/ --nologoRun the headless GameServer locally:
dotnet run --project src/Server/Unity client ── input ──► Shared ServerSimulation ◄── input/state ── GameServer
│ │
└── render authoritative state/events
Editable Character Package
package.json + character.json + CharacterAssetCatalog.asset
│
▼
Shared compiler + Unity asset cook
│
▼
Immutable content-cooked package
manifest + runtime definition + poses + client bindings
The server and client consume the same cooked deterministic representation. Runtime matches pin package IDs, versions, hashes, dependencies, and capability versions in an immutable Match Content Catalog. Raw authoring JSON is cook input, not a runtime contract.
Explore the interactive runtime architecture diagram for component relationships, trust boundaries, and the primary runtime path.
The longer-term direction is cautious Workshop/package support: creators compose approved deterministic primitives and package-owned assets; they do not ship arbitrary simulation code, native plugins, or direct Unity-path dependencies. See ADR-0022 through ADR-0030.
FightGuy demonstrates the package-native workflow:
- edit
client/Unity/Assets/CharacterPackages/fightguy/; - inspect and cook through the Unity CLI;
- validate source, asset bindings, deterministic pose data, generated client bindings, and hashes;
- load the immutable result in Ability Lab, Training, PvP, and GameServer paths.
unity command --project-path client/Unity \
sloparena.character.inspect --target fightguy --format json
unity command --project-path client/Unity \
sloparena.character.cook --target fightguy --format jsonAbility Lab is the primary gameplay editor for package drafts. It previews valid drafts through the same cooked definition and interpreter used by the game; an invalid draft is never silently substituted into a match.
To add a new character, start with Adding a Character. Do not copy the legacy C# registry path for new work.
Start with the documentation map, then read:
- Architecture overview
- Combat systems
- Ability architecture
- Ability Lab
- Animation system
- Netcode architecture
- Testing and verification
- Contributing
Issues, design feedback, code, art, documentation, and testing are welcome. Read CONTRIBUTING.md before opening a pull request. This project uses the MIT license and follows the Code of Conduct.
Thank you to the artists and developers behind the assets and tools used here. See Credits for their names and work.
SlopArena uses agent-assisted development and generated art as practical tools. Contributions remain reviewed project work: determinism, licensing, gameplay correctness, and maintainability matter more than how an asset or patch was produced.