Unity Debug Sheet turns a pile of debug commands into a menu

The problem is that debug commands multiply

The project states the problem in the overview, and it is a familiar one. In general, many debug commands are created during game development, and the number of them increases as development progresses. As a result it becomes difficult to find the desired command, which in turn leads to a decrease in development efficiency. That is a workflow complaint rather than a technical one, and it is the reason a hierarchical menu is worth a package rather than a hundred lines of IMGUI. The library allows you to create a debug menu with a hierarchical structure, and the claim is that its interface can be controlled easily and intuitively by anyone, especially on mobile platforms, which is the detail that separates this from the usual developer-only debug overlay. A vertical layout is supported as well as the default, so the same menu can be operated with a thumb on a phone, and the project ships an animated example in the documentation folder showing the concept in motion.

Cells are the building blocks and the API is four calls

The cells are the generic items a debug page is made of, and the ones described in the readme cover the common cases. A label is static text, a button invokes a callback, a switch holds a boolean and reports changes, and a slider holds a float between a minimum and a maximum and reports changes. Each takes its display text and a callback, and the code reads like a description of the menu you would otherwise be wiring up by hand.

// Label
AddLabel("Example Label");

//　Button
AddButton("Example Button", clicked: () => { Debug.Log("Clicked"); });

// Switch
AddSwitch(false, "Example Switch", valueChanged: x => Debug.Log($"Changed: {x}"));

// Slider
AddSlider(0.5f, 0.0f, 1.0f, "Example Slider", valueChanged: x => Debug.Log($"Value Changed: {x}"));

The callbacks are what make the system useful, because a debug command is usually a small piece of state you want to flip while playing, and a switch bound to a gameplay parameter is a different kind of tool from a button that fires an event. The readme also lists a way to update cell contents after the fact, which matters when a value changes elsewhere in the game and the menu should reflect it.

Installation is a git URL in the package manager

The library installs as a Unity package, and the documented route is the package manager. You open the package manager from the window menu, click the plus button, choose to add a package from a git URL, and paste the address of the assets subdirectory of the repository.

https://github.com/Haruma-K/UnityDebugSheet.git?path=/Assets/UnityDebugSheet

The equivalent for a project that keeps its package manifest under version control is a line in the dependencies block of the manifest file in the packages folder.

{
  "dependencies": {
    "com.harumak.unitydebugsheet": "https://github.com/Haruma-K/UnityDebugSheet.git?path=/Assets/UnityDebugSheet"
  }
}

The requirements section is short, which is unusual for a Unity asset, and it says the tool is compatible with Unity 6.0, known as 6000.0, or later. The tree backs up the compatibility story with several project files for different configurations, including one for the editor, one for the base library, one for the Graphy extension and one for the in-game debug console extension, so the package is built as a set of assemblies rather than a single blob.

Pinning a version means editing the lock file yourself

If you want a specific version rather than the latest, the instructions are to add the version number to the end of the git URL, and the readme is explicit that you update the version by changing that number.

https://github.com/Haruma-K/UnityDebugSheet.git?path=/Assets/UnityDebugSheet#1.0.0

The consequence of not pinning is described next, and it is a real one. If you do not specify a version, you can update it by opening the package lock file in the packages folder and rewriting the hash of the library, which is the entry the package manager uses to decide whether the dependency has moved.

{
  "dependencies": {
      "com.harumak.unitydebugsheet": {
      "version": "https://github.com/Haruma-K/UnityDebugSheet.git?path=/Assets/UnityDebugSheet",
      "depth": 0,
      "source": "git",
      "dependencies": {},
      "hash": "..."
    }
  }
}

For a team that wants reproducible builds, that is a mechanism to be aware of, since the default behaviour of the package manager is to track the branch rather than a tag, and the lock file is where you intervene.

Placing the prefab and creating the first page

The quick start is four steps and the first one is a scene operation. You drag the prefab named DebugSheetCanvas into the hierarchy window to place it in the scene, and if an EventSystem does not exist in the project you create one, which is the usual Unity requirement for any interface. The second step is to create a page, and the way to do that is to inherit from the base class named DefaultDebugPageBase, which is where the cell adding calls from the earlier example go. The third step is to add a link to that page, which is what makes it reachable from the menu hierarchy, and the fourth is to open and close the debug menu, which the readme describes in terms of a keyboard shortcut and a way to show or hide the sheet. The pages are the hierarchy, the cells are the contents, and a link from one page to another is how a deep menu is navigated, so a project with twenty debug commands ends up with a tree rather than a list.

Demos double as the documentation for the cell system

The demo scenes are not a toy, they are a reference. You can try the demo by cloning the repository itself and playing the demo scenes, and there are four of them. The character viewer demo lets you switch between character models and motions from the debug menu, and it includes samples that integrate with other libraries, Graphy and an in-game debug console, to monitor performance. The default cells demo lets you check the behaviour of every cell the library includes, which is the fastest way to understand what the built-in set does without reading the source. The custom cells demo shows how to create your own cells. And the entry scene transitions between those three, showing how the debug sheet placed in each scene behaves as a singleton, which is a detail that matters when a game has scene transitions and the menu should not be destroyed and rebuilt. The documentation folder also holds the animated concept images, the installation screenshots and the demo captures, all committed to the repository, so the readme and the assets agree.

Mobile details and extension packages are the interesting part

The advanced usage section is where a project that targets mobile shows its experience. There is a way to work within the safe area, so the sheet does not sit under a notch or a home indicator, a way to change the minimum and maximum size of the menu, a way to change the show and hide animations, a way to hide the backdrop, and a way to keep the menu open when the backdrop is clicked rather than dismissing it, which is the behaviour you want on a phone where a stray tap would close the sheet. You can also pop several screens at once, and there is guidance on using async methods instead of coroutines for cell actions. The basic usage section covers excluding the sheet from release builds, which is a build configuration step rather than a runtime check, and there is a section on extending the built-in cell prefabs. Three extension packages are listed, one displaying the system information of Unity, one an in-game debug console, and one for Graphy, and the repository carries a third party notices file, which is what you need when a package pulls in other people's code.

Editorial conclusion

Unity Debug Sheet earns its place for a Unity team whose debug commands have multiplied until nobody can find the one they need, because the hierarchy and the labelled cells turn a flat list of hotkeys into something a designer or a tester can operate without reading the source. It is the wrong choice for a project that is not in Unity, and the wrong choice if you want the console output rather than an in-game menu. Verify three things before you adopt it: that your Unity version is one the project supports, since the current requirement is Unity 6 or later, whether the debug sheet is excluded from your release builds, since a menu of live tuning controls has no business shipping to players, and whether the cell types cover what you actually need, because the built-in set is a fixed list of generic items and anything else is a custom cell you have to write. The licence is MIT, the last push was on 2026-08-19, and the newest release is 2.0.0 from the same day.

Frequently asked questions

Official sources

1. Haruma-K/UnityDebugSheet on GitHub
2. Issues
3. License: MIT
4. README
5. Releases