Erlang API reference
These docs are Lua-first, because that is how most games are built on Asobi. But Asobi is a plain Erlang/OTP library underneath, and you can use it directly from Erlang (or any BEAM language) without writing any Lua.
When to use Erlang over Lua: you want behaviour-level control (supervision trees, custom match state machines, direct gen_statem handling), or you are embedding Asobi in an existing Erlang application. Writing a game? Stay on the Lua API.
Start an Erlang project
The setup steps - the rebar.config dependency, the sys.config keys Nova, kura and shigoto need, and a minimal asobi_match module - are in the Erlang OTP section of the getting-started guide. That guide ships inside the library, so it is version-matched to the release you depend on. A working project is in examples/erlang-match.
Asobi is a game backend you write in Lua. Erlang is a supported way in, not the main road: the tutorials, samples and CLI all assume Lua, and the Lua runtime ships inside the same application, so you take it as a dependency either way. If you are writing a game rather than embedding the library, start at the quick start.
Reference
The full Erlang API reference is published on HexDocs: every public module carries -moduledoc/-doc attributes, rendered at hexdocs.pm/asobi. The source lives on the asobi repository.
The modules you will use
asobi_match- the game behaviour every mode implements (init/join/leave/handle_input/tick/get_state) - the Lua adapter implements it on your behalfasobi_match_server- the gen_statem that drives a match's lifecycle and broadcasts stateasobi_matchmaker- queues and pairing strategiesasobi_world_server- persistent, zoned worldsasobi_zone- spatial partitions within a worldasobi_spatial- in-memory spatial queries
Where next?
- Lua API reference - the
game.*surface most games use. - Core concepts - matches, worlds, zones, voting, phases.
- Self-host - run the runtime yourself.