Quaver: a community rhythm game with an editor and multiplayer

A vertical scrolling rhythm game, on Steam for three desktop platforms

Quaver is described in the repository description as a community-driven, open source competitive vertical scrolling rhythm game. The README adds the details that matter for a reader deciding whether to install it: two game modes, online leaderboards, an in-game editor and a multiplayer mode.

The vertical scrolling format is the defining trait, and the competitive framing is the second: leaderboards are part of the product rather than an add-on, which is what makes an in-game editor and a multiplayer mode worth having. The game is published on Steam for Windows, Mac and Linux, and the README makes the accessibility argument itself, pointing out that the platform spread makes it one of the more approachable community rhythm games.

It is a game rather than a library or a service, which changes what a reader should expect from the repository. The interesting parts for a developer are the editor, the multiplayer layer and the way the client is put together, not a reusable API. The homepage linked from the repository metadata is the Steam page for the game.

Building from source means the .NET 8 SDK and Steam running

The build instructions are short, and they contain one requirement that surprises people. Beyond the .NET 8 SDK and the source tree, the instructions say to have Steam open and running. The instructions do not say why the Steam client is needed, but it is listed as a step of the setup rather than as an optional extra.

The clone step pulls the submodules as well, and it does so in a way that skips the server client submodule during the update:

git -c submodule."Quaver.Server.Client".update=none clone https://github.com/Quaver/Quaver --recurse-submodules

After that the client is started straight from the SDK:

dotnet run --project Quaver

There is no separate packaging step in the documented path, no asset pipeline command and no configuration file to edit before the game starts. The two steps above, an SDK and a running Steam client, are the whole setup. For anyone who wants to contribute, the same instructions apply, since the contribution guide points at this build path rather than at a separate developer environment.

One solution holds the client, the shared layer and the API client

The repository is a single Visual Studio solution, Quaver.sln, with the game itself in the Quaver directory and two shared libraries beside it. Quaver.Shared holds code shared across the components, and Quaver.API is the API client. A directory named Wobble sits alongside them, and a file named AGENTS.md sits at the root next to CODESTYLE.md.

Two entries are Git submodules rather than plain directories, which the .gitmodules file records. Quaver.Server.Client is the server side client library, and Quaver.Resources holds the game assets. The clone instruction above deliberately does not update the server client submodule, so a first build works without it, and a contributor who needs the server side pulls it in afterwards.

The root also carries the usual project infrastructure: .github/ with the workflow that builds the code, a .travis.yml, a .editorconfig, a .vscode/ directory, and crowdin.yml, which points at a translation platform. That last file is the reason the README lists translations for the game, and it tells you that localisation is handled through an external service rather than through files in the repository.

Contribution rules assume one feature per pull request

The contribution guide is specific enough to be useful, which is unusual for a game repository. The recommended entry point is the Discord server, where the developers, the community and the testers are said to be.

The rules for pull requests are stated plainly: one branch or pull request per feature, no unrelated commits on a feature branch, and pull requests kept short and concise. If a branch is named my-new-feature, it should contain that feature and nothing else. Contributions are made by opening a pull request.

There is one extra step for anything intended for the Steam release. If you want to develop a feature with the goal of having it in the Steam build, the guidance is to open an issue first, so that the scope can be discussed before the work starts. That is a useful signal about how the project is run: the Steam build is a curated target, and the repository asks people to agree on scope before writing code rather than reviewing it after.

Style is a separate concern, handled by the CODESTYLE.md file, which contributors are asked to follow so the codebase stays consistent, with an invitation to raise concerns about the approach in the same place.

MPL 2.0 covers the client, the assets do not

The licence of the game client is the Mozilla Public License 2.0, and the terms are spelled out rather than left in a file. If you modify the software, you must disclose the source code of the modified version of the files you changed and include the original copyright notice. That is the file level copyleft the MPL applies, and it is the part most people need to understand before forking the project.

Two carve-outs follow, and they are the reason the licence section is longer than usual. The game client is split into submodules that carry their own individual licensing, so the licence of the server client and of any other submodule has to be checked separately. And all game assets are released and covered by a separate licence, which matters if you plan to use the software to create derivatives for commercial purposes. The assets live in the Quaver.Resources repository, where the further licensing information is kept.

So the picture for a commercial use case is a split one: the code you can read, modify and disclose under MPL 2.0, and the artwork, which follows its own terms. Nothing here is legal advice, and the licence files in each submodule and in the resources repository are the place to check what actually applies to a given asset.

Patch releases landed through September and the tree is still moving

The release history shows a patch level line inside the 1.8 series, with v1.8.0.6 on 2026-08-04, v1.8.0.7 on 2026-08-23 and v1.8.0.8 on 2026-09-11. The default branch is develop, and the branch the licence links point at, while the build badge in the README refers to a workflow named dotnet.yml, so continuous integration is part of the setup rather than an afterthought.

The last push was on 2026-10-17 and the repository is not archived. That is the number to weigh when you plan to depend on the project, since it sits closer to the tag dates than the tags do: the 1.8.0.8 release from September is not the last thing that happened in the tree.

For a reader deciding whether to invest time in the code, the practical points are these. The client is on a modern .NET target, the project publishes on all three desktop platforms, and the pieces a contributor would want to touch, from the shared layer to the server client, are visible in one place. What you will not find here is documentation of the internals, and the CODESTYLE.md file and the Discord server are where the shape of the code is explained.

Editorial conclusion

Quaver suits a developer who wants to change a competitive rhythm game rather than just play one, because the game client, the shared layer, the API client and the server client are all reachable from one solution, and the contribution process asks for one feature per pull request and an issue before anything reaches Steam. It is the wrong target if you need commercial reuse of the artwork, since the assets are covered by their own separate licence in the Quaver.Resources repository, and it is the wrong target if you want a stable public API, because the documentation here covers building, contributing and licensing rather than the API surface. Before you start, install the .NET 8 SDK, have Steam open and running as the build instructions require, and read the CODESTYLE.md file and the licence terms in each submodule.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. Quaver/Quaver on GitHub
4. README
5. Releases