Skip to main content
euca-moba is a complete MOBA kit — hero attributes (STR/AGI/INT), towers and barracks, creep waves, Roshan, neutral camps, fog-of-war and wards, day-night — shipped as an example game under games/euca-moba, layered on the genre-neutral gameplay, units, and inventory primitives. Two mental models to hold:
  1. It is a game, not an API. Open it in euca-studio (cargo run -p euca-studio, pick the MOBA project) and press Play, or serve it headless with cargo run -p euca-studio -- --headless moba (agent HTTP API on :3917, no window). The engine names no game; the studio resolves the moba project’s app id to its Game.
  2. There are no /moba/* or /hero/* endpoints. An arena is assembled from the generic spawn, item, rule, and gameplay routes plus the MOBA ECS systems that run inside game.step. The repo’s scripts/moba.sh builds the whole arena this way over the API — read it as the worked end-to-end example.
This page shows the core loop — spawn a unit from components, give it an item, drive scoring with rules — with output captured from a real headless server.

Stand up an arena

1. Spawn a hero unit from components. A hero is a generic entity composed in one /spawn call (see Units & roles); the same call the CLI’s entity create sends. There is no template or registry — the flags are the unit.
scripts/moba.sh does exactly this for both teams’ heroes, plus structures and towers as --physics Static units with --combat --combat-style stationary --role tower. 2. Give the hero an item. Items are global definitions traded onto entities (see Inventory & economy). Define one, then give it — /item/give auto-creates the unit’s inventory:
3. Towers, creeps, and scoring are rules + entities. Towers and barracks are just entities with combat stats, a team, and an EntityRole::tower/structure; creep waves are driven by timer rules; kill bounties and scoring come from death rules. scripts/moba.sh sets all of this up over the API:
Or load a whole match from one scenario document (see Build a scene).

Behavior and gotchas

The things you only find out by running it:
  • There is no /moba/spawn, /moba/match, /hero/define, or /hero/select. Those MOBA-specific routes were removed; they 404. The MOBA layer is pure ECS systems plus the generic spawn / item / rule / gameplay routes. A hero is one /spawn with combat + role flags; a creep is /spawn plus a combat role, or a timer rule.
  • The full hero kit (mana, abilities, stat growth) is in-game, not over HTTP. euca-moba’s Rust spawn_hero inserts an AbilitySet, Mana, and base/growth stats. The generic /spawn does not — see Units & roles and Abilities & status effects.
  • The MOBA systems run inside game.step. tower_aggro_system, neutral_camp_system, vision/wards, and day-night are part of the MOBA game’s per-tick schedule, so they advance on every /step of the headless host without any MOBA-specific endpoint.
  • Serve it with the project id. cargo run -p euca-studio -- --headless moba loads the moba project under projects/. With no id, the first discovered project is served instead.

Endpoints

The MOBA layer borrows the generic surface — there are no dedicated /moba or /hero routes:

Status

  • Shipped — hero attributes (STR/AGI/INT, derived stats), towers and barracks, creep waves, Roshan, neutral camps, item actives, fog-of-war and wards, day-night, tower aggro, and gold/XP. Runs as the euca-moba example game in euca-studio (windowed) or headless.
  • Requires — rendering a match needs a GPU host (the windowed studio); the match logic itself is fully headless.

The full API

The spawn, item, gameplay, and ability endpoints used to assemble a MOBA, with schemas.