Open-source project
Quaint-Studios/Reia avatar
Quaint-Studios/Reia

Reia is an open source action-adventure MMO built in Godot and Rust

RPG game action-adventure MMO built with Godot and Rust.

980 stars65 forksGDScriptAGPL-3.0

At a glance

What is it?
Reia is a fantasy action-adventure RPG from Quaint Studios, with a Godot client, a Rust server and a SQL layer, playable offline, with friends or as an MMO. The interesting engineering is in the delivery rather than the design, since the dedicated server image downloads itself, checks its own checksum, and the client project expects Git LFS assets and submodules before it will open.
Who is it for?
Reia suits a developer who wants to read a real Godot and Rust multiplayer project, and who is comfortable with a game project that pulls its assets through Git LFS and its server through a verified download. It is a poor fit if you want a finished game, since the releases are all labelled pre-alpha and the most recent tagged one is from April 2024, and it is a poor fit if you cannot host a server, since the MMO half needs the dedicated server running.
Can I use it commercially?
Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
Is it still maintained?
Yes. The repository last received commits 18 days ago.
What is it written in?
Mainly GDScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Three runtimes, and a game that works in three modes

The pitch in the readme is that Reia lets you explore endless worlds, that it is an action-adventure RPG which is also open source, and that you can play it offline, online with friends, or log in for an MMO experience. The vision line says you can create and explore worlds, manage your own economy and products, and restore Reia's world through the story, and that the point is to let you focus on whichever of the story, the combat, the playing or the economy you care about. The repository layout matches that ambition, with a `godot/` directory for the client, a `rust/` directory for the server side, a `sql/` directory for the data layer and a `docs/` directory, and the primary language recorded for the project is GDScript, which is the Godot scripting language. There is also a `_old_code/` directory, which is a fair signal of a project that has changed shape at least once.

The setup guide treats assets and submodules as part of the build

The getting started guide is a separate document and the readme points at it for anybody new, and what it covers is the practical part of working on the project. The steps it lists are cloning the repository, downloading the Git LFS assets, pulling the submodules, opening the project in Godot 4.x, and troubleshooting the common setup failures. That list is worth reading as a description of what a Godot project with large binary assets actually needs, because the repository carries a `.lfsconfig` and a `.gitmodules` alongside the source, and a clone without those two steps is not a working project. The guide also has a troubleshooting section, which is the part that saves time, since the failure modes of a missing LFS checkout and a missing submodule are not obvious. There is a separate `INSTALL.md` as well, and a `docs/ROADMAP.md` that the contributing section points at as the place to find work to pick up.

The server image downloads itself and verifies the checksum

The dedicated server Dockerfile is unusual, and the interesting part is the builder stage. The image is built from Ubuntu 24.04 with wget, unzip, jq, ca-certificates and coreutils, and it takes a version argument that defaults to `latest`, with a base URL pointing at the project's own release storage. The build then fetches a manifest, parses the file name and the expected hash for the Linux server binary out of it with jq, downloads the archive, checks the sha256 against the manifest, unpacks it and makes the extracted binary executable. So the image does not contain the server, it contains a verified downloader for the server, and the checksum check is part of the image build rather than something the operator does afterwards. The build instructions are in the header comment of the file, a tagged build for the default version and a versioned build that passes the version as a build argument, and a run command that publishes a UDP port.

Running one server locally is a compose file

The compose file in the repository is short and gives you the shape of a local server. There is one service, the image is published as `quaint-studios/reia`, and the command is the server binary under the builds directory. The port mapping is deliberately narrow, `127.0.0.1:4337:4337`, so the server is bound to the loopback interface of the host rather than exposed on the network, and the working directory is `/app` with the built server directory mounted over it. That is the arrangement that makes a local instance possible without touching the image, and the loopback binding is the detail that matters if you are tempted to change it. The repository also has a `SECURITY.md` and a code of conduct, and the security file sits next to a game that has player accounts and an economy, which is the right place for it.

The world model is a design document in disguise

The lore section is unusually detailed and it is really the systems design. Four Ethereals, the deities of the world, are in conflict, and one of them, their sister, is Reia. Each Ethereal creates a realm, the equivalent of a giant planet that keeps growing as it consumes ether from its surroundings and from other realms, and the player-facing consequences are player-owned floating islands, raids of varying sizes including server-wide ones, bosses, PvP zones and custom mini games. How a realm grows is decided by how it is ruled, with four stances. A neutral realm holds its size but can still absorb pure ether from the void, the emptiness between realms. A passive realm draws energy from the void and from neighbouring realms, which is much faster but is considered hostile and can spark wars. An aggressive realm invades, taking ether from the realm, from its occupants and from the Ethereal itself, which can kill a deity. A defensive realm absorbs the invaders' occupants as food and grows stronger for it. The design is a set of rules about who takes energy from whom, and the lore is how the rules are taught.

The netcode lives in its own Rust repository

The multiplayer layer is not in this repository, and the readme says so directly, pointing at a separate project called Sustenet, which it describes as the netcode designed specifically for this project and made in Rust. The split is a sensible one for a game with a Godot client, since the network layer is the part most likely to be rewritten and the part least likely to be touched by a designer, and keeping it in its own repository means a contributor to the game art or the combat does not have to build the networking stack to run the game. The readme also lists a Discord server and a jobs page, with a jobs document in the repository, so the project is presented as something with a team and a process rather than a solo experiment, and the Open Collective badge in the header suggests the funding model is the same.

Pre-alpha releases, an AGPL licence and a precise contribution contract

The release list is three versions, v1.0.0.3, v1.0.0.4 and v1.0.0.5, all labelled pre-alpha and all published on the same day in April 2024, while the last push to the repository was on 2026-10-04, so the code has moved on considerably since the last tag and the version numbers do not describe it. The licence is AGPL-3.0, which for a hosted game server is the licence that matters most, since the server is offered over a network. The contributing section is the most precise part of the readme, and it asks for a specific workflow: create an issue for the task, fork, and name the branch with your username and a root focus, where the examples are a main menu, keybindings, multiplayer and art, and the guidance is that the focus should be something you could build on later and should not be overly specific. The commit conventions are given as a table of wrong and right forms, with a full stop at the end of an imperative sentence, and the length of the commit does not matter as long as a long one is summarised in the description.

Editorial conclusion

Reia suits a developer who wants to read a real Godot and Rust multiplayer project, and who is comfortable with a game project that pulls its assets through Git LFS and its server through a verified download. It is a poor fit if you want a finished game, since the releases are all labelled pre-alpha and the most recent tagged one is from April 2024, and it is a poor fit if you cannot host a server, since the MMO half needs the dedicated server running. Before you clone it, check three things: that you have Git LFS and the submodules ready, because the getting started guide treats them as part of the setup rather than an afterthought, that the licence suits you, since the project is AGPL-3.0 and the game server is a service, and what the current state actually is, since the repository was pushed to on 2026-10-04 while the release tags are considerably older.

Frequently asked questions

What is Reia?

An open source action-adventure RPG and MMO from Quaint Studios, built with a Godot client, a Rust server and a SQL layer. It is described as playable offline, with friends, or logged in for an MMO experience, with player-owned floating islands, raids, bosses, PvP zones and a player economy.

How do I set up the Reia project?

Follow the getting started guide, which covers cloning the repository, downloading the Git LFS assets, pulling the submodules, opening the project in Godot 4.x and troubleshooting the common setup failures. The repository carries a .lfsconfig and a .gitmodules, so a clone without those steps is not a working project.

How does the Reia dedicated server Docker image work?

The build stage downloads a manifest from the project's release storage, parses the Linux server file name and expected sha256 out of it with jq, downloads the archive, verifies the checksum, unpacks it and makes the binary executable. The image is built with `docker build -t reia-server:latest .` and can be pinned to a version with the VERSION build argument.

Can I run a Reia server locally?

Yes, with the compose file in the repository, which runs the published image, starts the server binary and maps port 4337 on the loopback interface only, with the built server directory mounted into the container. The narrow binding means the instance is not reachable from the network without changing it.

What licence is Reia under, and what state is the project in?

AGPL-3.0, which matters for a hosted game server. The tagged releases are all labelled pre-alpha and all date from April 2024, while the last push to the repository was on 2026-10-04, so the tree is well ahead of the last version tag. The project also maintains its netcode in a separate Rust repository called Sustenet.

Official sources

  1. License: AGPL-3.0
  2. Project website
  3. Quaint-Studios/Reia on GitHub
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/quaint-studios-reia.svg)](https://hysenlabs.com/projects/quaint-studios-reia)

Was this useful?