YARG: a plastic guitar game where the controller plumbing is the hard part

A rhythm game where the peripheral support is the specification

YARG, a.k.a. Yet Another Rhythm Game, is described as a free, open-source plastic guitar game that is still in development, supporting guitar with five frets, drums with plastic drums or an e-kit, vocals, pro-guitar, and more.

That list of instruments is the product. A rhythm game that only accepts a game controller is a game with a scoring system, while one that accepts a plastic guitar, an electronic drum kit, a microphone and a professional six-string controller is a game that has to talk to real hardware. The repository topics place it firmly in that lineage, with clone-hero, guitar-hero and rockband as the three tags.

The README is also unusually explicit about the state of the thing. YARG is still in active development, so there may be bugs and missing features. That sentence is in the first paragraph, and it matters, because the following paragraph is a piracy disclaimer that is even more emphatic: YARG stands firmly against all forms of piracy, does not use any ripped or pirated assets or music and never will, and users agree not to promote or endorse piracy through the platform. The disclaimer also clarifies that YARG stands for Yet Another Rhythm Game and not for pirates, which is a joke that only makes sense if people have been getting it wrong.

The project is C# under LGPL-3.0, the homepage is yarg.in, and the last push was on 2026-10-15. The releases are v0.15.0 from 2026-06-24, v0.14.0 from 2026-01-28 and v0.13.2 from 2025-12-25, so the version is pre-1.0 and the numbering says so.

The content model follows from the disclaimer. Songs are not bundled, they are imported, and the repository mentions a separate YARG Setlist distributed alongside the game in the launcher, and a crowdin.yml file at the root, which is the configuration for a translation service, so the game's interface is translated through Crowdin.

The game is not installed directly, the launcher is

The downloading section is short and makes one recommendation clearly: download YARG through the YARC Launcher, and the portable option is not recommended because some features may not work.

YARC is a separate application in its own repository, with its own releases page, and the download flow it supports is a sequence of nine steps. Go to the YARC Launcher releases page, click the download for your operating system, expect a possible warning that the application is not safe, which the README says is a false positive and links to an antivirus warnings section in the launcher repository. Then open the launcher, click YARG on the left, press the green Update Stable button, choose an install folder which should be empty, wait for the install, and press Play Stable. If you want songs, install YARG Setlist, also on the left of the launcher.

Two design points sit in that list. The first is that the game, its songs and any future content are separate installs managed by one launcher, which is a content delivery design rather than a game design. The second is the antivirus warning. An unsigned or self-built Windows binary frequently trips heuristics, and the project treats that as a known false positive with a documentation page for it, which tells you that the launcher is distributed outside the usual signed channels.

The two-step structure also shapes the source layout. The repository root is a Unity project, with Assets/, Packages/, ProjectSettings/, Images/ and a crowdin.yml, plus a YARG.Core directory. The YARC launcher is not part of this repository, so the launcher and the game are separate codebases, and the README points at the launcher releases rather than shipping binaries here.

Linux needs udev rules, and the file name has to come first

The Linux section is the most technically detailed part of the README, and it is a good illustration of what a plastic guitar game actually requires from a Linux machine.

The dependency is that HID devices, such as PS3 and Wii instruments, will not work without some setup. The packages are hidapi and libudev, with the package names varying by repository: on apt-based distributions such as Ubuntu or Debian, sudo apt install libhidapi-hidraw0 libudev1, on pacman-based ones such as Arch, pacman -S hidapi systemd-libs, and on Fedora, dnf install hidapi systemd-libs.

Then a udev rules file, which is where the real requirement is:

KERNEL=="hidraw*", TAG+="uaccess"

The file has to be called 69-hid.rules and placed inside /etc/udev/rules.d/ or /usr/lib/udev/rules.d/. The name may differ if desired, but it must come before 73-seat-late.rules, and the README explains why: without the file, YARG will not be able to access HID devices without special permissions such as being run with sudo, which is not recommended. The last step is to reboot the system to apply the new rule.

The ordering constraint is the interesting detail. udev applies rules in lexical order, and the seat management rules that come later would otherwise reassign device access, so the file number is a functional requirement rather than a naming convention. Getting it wrong produces a game that cannot see the guitar, and the fix is a rename and a reboot.

There is a second rules file for the XBOX 360 Wireless Adapter:

SUBSYSTEM=="usb", ATTR{idVendor}=="045e", ATTR{idProduct}=="0291", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="045e", ATTR{idProduct}=="02a9", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="045e", ATTR{idProduct}=="0719", MODE="0666"

The file is 99-yarg-libusb.rules, the vendor id 045e is Microsoft's, and the three product ids are three revisions of that adapter. The mode 0666 is wide open, and it is worth being clear that this is the project's own instruction and that a 0666 mode on a USB device is a permissive choice that a security-conscious user may want to narrow.

Contributing means a dev branch, a fork with all branches, and a Unity merge tool

The contributing section carries a warning that is unusually blunt, and it is the first thing in that part of the README.

If you wish to contribute, use the dev branch. Your pull request will not be merged if it is on master. The setup instructions then say that if you do not follow them, it is possible that you will not be able to run the game at all.

Step one of the setup is to fork the project, and to uncheck the option that includes only the master branch, because the dev branch will not be included in your fork otherwise and you will not be able to set things up correctly. The README includes a screenshot of that setting for the sake of anyone who has not seen it before.

Then the toolchain, and the first entry is a surprise for a game project. Make sure you have the latest version of Blender installed, and the reason given is that it is for loading models even if you do not plan on editing them. So a build of a Unity rhythm game with instrument models needs Blender on the path, which is an unusual dependency for a C# repository and reflects that the instrument meshes are part of the project rather than imported art.

The repository layout supports that reading. There is an Assets/ directory with the Unity assets, and a YARG.Core directory that is separate from it, which is a common way to keep the game-specific code and the shared library apart. There is a .gitmodules file, so the project pulls in submodules, and a .git-blame-ignore-revs file, which is a standard for ignoring formatting-only commits in git blame.

The table of contents also names a Unity YAML Merge Tool, and the root has Assembly-CSharp.csproj.DotSettings and YARG.sln.DotSettings for the Rider and Visual Studio settings, and EnableNullability.props, which turns on nullable reference types for the project as a whole. The Unity YAML merge tool exists because Unity serialises its scenes as text YAML, and a merge conflict in a scene file is nearly impossible to resolve by hand.

The external licences and assets sections are where the content story is

The table of contents carries three sections about legal and asset provenance, and they follow the contributing section, which is where you would expect them in a project with this much third-party content.

There is a License section for the game itself, which the repository identifies as LGPL-3.0, an External Licenses section for the components the game uses, and an External Assets and Libraries section. Three separate headings is a signal that the project takes provenance seriously, which follows from the piracy disclaimer at the top of the README.

The reason that matters practically is the content model. YARG does not ship ripped assets or music, and the songs are imported rather than bundled, with YARG Setlist distributed as a separate install through the launcher. So the pipeline is: the game and the setlist are separate packages, the setlist carries the licensed music, and the game provides the engine to play it. A creator who makes their own charts imports them.

The LGPL-3.0 choice for the game is also worth noting in that context. LGPL is the licence that allows a project to be used in a way that requires its own source to be available for modifications while still permitting the game to be distributed as a binary, which is what a launcher-based install needs. The repository root has a LICENSE file and a .gitconfig, and the presence of the External Licences section in the README means the third-party components keep their own terms rather than being folded into the project's.

For a user, the practical question is what the setlist actually contains and under what terms, and the README does not describe the licensing of the songs in the setlist, so that has to be checked in the launcher and the setlist documentation rather than here.

Where YARG is the wrong tool

The limits are the ordinary limits of an unfinished game project, and they are stated plainly enough that a reader can decide for themselves.

The first is that it is not finished. The README says YARG is still in active development, so there may be bugs and missing features, and the version numbers agree, with v0.15.0 as the newest release and a pre-1.0 version. A pre-1.0 game that is still in development will change under you, and that is fine for a project people follow but not what you want from something you depend on.

The second is the content. Because the project ships no music of its own, a new user has to install the setlist separately and that is a download of somebody else's licensed content, or bring their own. So the first hour of the game depends on a step the game itself does not provide, and a user without a setlist has an empty game.

The third is the Linux story, which is the sharpest limitation in the repository. Playing with a real instrument on Linux means installing two system packages, writing a udev rules file with a specific name, rebooting, and getting the ordering right relative to 73-seat-late.rules. The XBOX 360 adapter needs a second file with world-writable device permissions. The README is good about this, but it does mean that a Linux user without permission to write to /etc/udev/rules.d/ is out of options except running the game with sudo, which the README explicitly does not recommend.

The fourth is the launcher dependency. The portable option is not recommended because some features may not work, so a Linux user without the launcher, or a user who would rather not run a third-party application manager, is dealing with the less supported path. There is also the antivirus false positive to think about, and a self-built binary that trips a heuristic is a recurring source of friction for a game that wants casual players.

The fifth is the platform scope of the controllers themselves. The instrument support named in the README is a list, not a promise, and the Linux section mentions PS3 and Wii instruments and the XBOX 360 wireless adapter specifically. Anything outside that list, particularly newer or less common hardware, is what a contributor would have to add, and the setup instructions make clear that adding a new instrument means working with the same Unity and Blender toolchain as the rest of the game.

Editorial conclusion

YARG is worth following if you play with a real instrument and want something that runs on your own hardware with songs you own, because the instrument support is broad and the content is importable rather than bundled, and because the project is transparent about how much of it is still in progress. It is the wrong tool if you want a finished commercial rhythm game with a large song library, since the game itself is described as still in development with possible bugs and missing features, and the wrong tool on a Linux machine you cannot administer, since HID and USB access depends on udev rules you have to write. Before installing, read the Linux section if that is your platform, and if you intend to contribute, work on the dev branch rather than master.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. Project website
3. README
4. Releases
5. YARC-Official/YARG on GitHub