InputSystem_Warriors is a Unity sample project you can read as a reference

A reference project, not a tutorial series

The Warriors project is described as a Unity example project created to demonstrate a variety of tools and functionality with Unity's Input System. The README says it is publicly available to be used as a learning resource for the Input System or for any other implemented feature and tool, as a foundation for building your own projects, or to extract code, assets and information.

That framing sets expectations correctly. This is a demonstration project that Unity Technologies built for its own webinars, and the maintainer asks that you contact Andy Touch if you use it in some form. It is a working Unity project with a real scene, real prefabs and real UI, which is exactly what makes it useful and exactly what makes it heavy to read.

The project lives in a single top-level folder, InputSystem_Warriors_Project, next to the README and a gitignore, so the repository is the project rather than a package beside one. The primary language recorded for the repository is ShaderLab, which reflects the graphics work in the sample rather than the input code.

Two things follow from the webinar origin. The branches are used as time-stamps for project states for webinars, with V1 tied to the Unite Now session in April 2020 and V2 to the November 2020 session, and master carrying the most recent state. And the README describes the project as being in continuous development and improvement, so the content of master moves without any version number to track it.

The input scenarios it actually covers

The list of demonstrated input scenarios is the useful part of the README, and it is a checklist of the things that are awkward to work out on your own.

There is an Input Action Control Scheme for basic player controls, with a directional axis for movement and a button press for attack, and a separate scenario for setting up keyboard and generic gamepad bindings to that scheme, tested with the PlayStation Dualshock 4, the Xbox One controller and the Nintendo Switch Pro controller. There is instancing of multiple player controllers for a local multiplayer setup, which is the piece that shows how per-player devices and per-player actions are wired together.

For touch, there is UI input with a virtual joystick and a virtual button. At runtime, the project switches between Player Control and Menu Control action maps, which is the mechanism behind pause menus and settings screens in an Input System game. There is UI for rebinding action controls to new buttons and joysticks, and UI that displays connected device data in both screen space and world space. Finally, there are callbacks for an input device disconnecting and reconnecting at runtime, which is the behaviour that saves a game from a controller being unplugged mid-session.

That last item is the one most worth reading the source for. Device loss and reconnection involve the whole action map being re-enabled or disabled, and a sample that shows the callback in place is a faster route than reconstructing it from the API reference.

Rendering and UI work bundled into the same sample

The project demonstrates a set of features that have nothing to do with input, and the README is upfront about it under a separate heading for other demonstrated scenarios.

On the rendering side, there is the Universal Render Pipeline's Camera Stacking for overlay UI, a Scriptable Render Pass for a scene blur UI overlay, and the Universal Render Pipeline's integrated post-processing for tonemapping. On the UI and asset side, there is a nested UI prefab for displaying input device information, a Shader Graph for filtering a mask map to produce team colours, TextMesh Pro for rendering screen space and world space UI text, and a Scriptable Object that stores device display colours and display names.

This mixture is worth understanding rather than ignoring. The project is a vehicle for a webinar, and the webinar covered both the input work and the rendering work in the same session, so the sample carries both. The team colour mask map filter and the per-device display colours are the pieces that tie the input side to the presentation side, since each connected controller gets a colour and a name shown in the interface, and the warriors are tinted by team.

The consequence for a reader is that the project is a larger thing to open than a pure input sample, and the packages it pulls in go beyond the Input System. The dependency list includes the Universal Render Pipeline at a specific version, so a project that only wants the input lessons still opens a project that expects a modern render pipeline setup.

Versions, packages and the hardware it was tested against

The tech info section pins the environment, and for a Unity project those numbers decide whether the sample opens cleanly.

The current Unity version is 6000.3.0f1. The packages are com.unity.inputsystem at 1.16.0 and com.unity.render-pipelines.universal at 17.3.0. The version numbers sit together, which is the point: the sample is known to work with that Input System release and that render pipeline release, and the project files in the repository carry those versions.

The hardware list is unusually complete, and it is the list to check against your own desk. The project was developed and tested with a keyboard, a PlayStation 4 Dualshock controller, an Xbox One controller, a Nintendo Switch Pro controller, an Android Samsung Galaxy S9 for the touchscreen virtual joystick and virtual button, and a mouse, which is used for simulating touchscreen input in the Unity Editor. The mouse entry is the one that trips people up, because the touch scenarios appear to work on a desktop even when no touch hardware is present.

The software note is that the example project was developed and tested on Windows 10.

Taken together, this is a project that expects a specific editor, two specific packages and a specific set of peripherals. If your input device is not on that list, the corresponding scenario may still work, but you will be the first person to try it, and the reference point for expected behaviour is the list rather than the code.

The known issues, including the one that greets you on first open

The technical disclaimers section names two problems, and the second one is the first thing a new user hits.

The GameManager script has a toggle for spawning a group of Warriors at runtime. The number of warriors spawned is based on a fixed integer variable that is set manually in the Inspector, and it is not based on the number of input devices connected and detected. That is a deliberate simplification for a demo, and it is also the thing to change first if you are extending the sample, because the whole point of the local multiplayer scenario is that a second player with a second controller gets a second character, and as shipped the count does not follow the connected devices.

The first open problem is the pause menu screen blur. When opening the project for the first time, the Pause Menu Screen Blur Effect might not be rendering. The fix is documented: locate the UniversalRenderPipeline_Renderer_MenuBlur asset and add the Kawase Blur Render Pass to the Renderer Features.

That is a rendering pipeline asset configuration that does not survive a merge, and the README says so plainly. It is the kind of detail that would otherwise cost an afternoon, and the fact that it is written down at all is a point in the project's favour.

The blur is implemented with a Scriptable Render Pass, which is why the sample sits in the Universal Render Pipeline at all. If your project is on the built-in render pipeline, that part of the demonstration does not apply.

Credit, feedback channels, and the missing licence file

The project is developed by Unity Technologies with involvement from R&D, Product Management, Product Marketing and Evangelism, and the README credits Andy Touch as the person to contact about usage. Questions about the Input System itself go to the Unity forums, and there is a specific forum for the new Input System.

For problems with the example project itself, the README offers two routes: open an issue on the repository, or send an email to Andy Touch. The issues route is the one to use for anything that looks like a bug in the sample, since it is public and trackable.

There is one gap that deserves attention. The repository's licence is recorded as unknown, and the top-level entries of the repository do not include a licence file. For a project that is explicitly offered as a foundation to build your own projects on and as a source of code and assets to extract, that is a real question for a company that has to clear licensing before it copies anything. A Unity example project is published to illustrate the engine, and the intent is usually permissive, but intent is not a licence file, and the answer is to ask.

The screenshots in the README, the sample name and the artwork are equally part of what you would be reusing, so the question covers the assets as well as the scripts.

Beyond that, the project is a maintained reference rather than a dependency. It is not a package, it carries no versioned releases, and the branches are webinar time-stamps. The right way to use it is as a codebase to read, copy the specific patterns you need, and then maintain your own version.

Editorial conclusion

InputSystem_Warriors fits a Unity developer who wants one concrete project to read while learning the Input System, especially for the parts that are hard to find in documentation, such as pairing control schemes with devices, splitting Player and Menu action maps at runtime and building a rebinding screen. It is the wrong starting point for a team that wants a production architecture, since it is a webinar sample with a known-issue list and a fixed warrior count rather than a scalable multiplayer setup, and it is the wrong source to copy assets from without asking, since the repository carries no licence file. Before adopting it, open the project in the stated Unity version, apply the documented blur fix on first open, and confirm the hardware you have matches the list of tested devices.

Frequently asked questions

Official sources

1. Issues
2. README
3. UnityTechnologies/InputSystem_Warriors on GitHub