# Gameplay Ingredients: reusable runtime and editor scripts for Unity

> Gameplay Ingredients is a MIT licensed Unity package that collects runtime and editor scripts for common gameplay actions and logic, distributed through the OpenUPM scoped registry and pinned to a Unity version by tag, with the built-in render pipeline dropped as of the Unity 6 line.

**peeweek/net.peeweek.gameplay-ingredients** — Gameplay Ingredients for your Unity Games - A collection of runtime and editor scripts that ease simple tasks while making games and prototypes.

- Repository: https://github.com/peeweek/net.peeweek.gameplay-ingredients
- Stars: 641 · Forks: 66
- Language: C#
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/peeweek-net-peeweek-gameplay-ingredients

## A Unity package for the scripts every prototype rewrites

Gameplay Ingredients is a collection of scripts that ease simple tasks while making games and prototypes. The package description puts it more precisely: a collection of scripts for the editor and runtime to set up gameplay actions and logic in your games. That framing matters for what you get. This is not a framework that asks you to restructure your project, and it is not an asset store bundle of art. It is a set of behaviours you attach, and the package keywords make the shape visible, listing Gameplay, Ingredients, Unity, Behaviour, State Machine, Editor and Streaming. The documentation is published on readthedocs under the gameplay-ingredients section, and the repository keeps a CHANGELOG.md alongside the package metadata. The licence is MIT, which for a package of this kind removes the usual question about whether you can ship it inside a commercial game.

## Runtime, Editor, UI and the tilde folders Unity leaves out

The repository layout shows how the package splits. There is a Runtime/ directory for the behaviour code that ships in the build, an Editor/ directory for code that only runs inside the Unity editor, a UI/ folder, a Resources/ folder, an Icons/ folder and a StarterAssets/ folder with files for starting a project. Two folders carry a tilde suffix, Documentation~ and GFX~, which is the convention a Unity package uses to keep a folder out of the imported project, so the documentation and the graphic extras do not end up in your build. Everything is delivered through a single package.json at the root, which declares the package name net.peeweek.gameplay-ingredients, the display name Gameplay Ingredients, the category Gameplay, the Unity version it targets, links to the documentation, the licences file and the changelog, and names PeeWeeK.NET as the author.

## Installing in Unity 6000 through a scoped OpenUPM registry

For Unity 6000.0 and newer the install runs inside the editor. You open Project Settings and go to the Package Manager, add a new scoped registry that references the OpenUPM registry at https://package.openupm.com, and give that scoped registry the scopes com.dbrizov and net.peeweek. The com.dbrizov scope is needed because one of the package dependencies lives under that namespace. Then you open the Package Manager window, choose Packages: My Registries in the toolbar, select Gameplay Ingredients in the list and click Install. The documentation for the package sits alongside this flow on readthedocs, which is where the per-component guidance lives. Installing from a local clone works the same way with one extra step: clone the repository, set up the same scoped registry, then use the plus button in the Package Manager window, choose Add Package from disk and point at the package.json at the root of the package.

## For 2019.3 and older: openupm-cli or a git URL in manifest.json

Older editors have their own route. The recommended one is openupm-cli, with a single command:
```bash
openupm add net.peeweek.gameplay-ingredients
```
The alternative is a git reference, which needs command line Git installed on your machine. With Unity 2019.3 closed, you edit Packages/manifest.json in a text editor and append a dependency line pointing at the repository and a specific tag:
```json
    "net.peeweek.gameplay-ingredients": "https://github.com/peeweek/net.peeweek.gameplay-ingredients.git#2019.3.7",
```
You can check that the package was imported by looking in the project window under the Packages hierarchy, where a Gameplay Ingredients entry should appear. Both older paths are worth understanding even if you are on a current editor, because they are the ones that show you the version pinning mechanism the package relies on.

## The tag you choose decides which Unity version you get

Version compatibility is expressed as a table of tags, and choosing the wrong one is the most common way to get a package that does not compile. The current line is for Unity 6000 and later and uses the latest version from the registry. Older editors map to specific tags: Unity 2018.3 and 2018.4 take the tag 2018.3.0, Unity 2019.1 and 2019.2 take 2019.1.2, Unity 2019.3 and 2020.1 take 2019.3.7, Unity 2020.3 takes 2020.2.11, and Unity 2021.3 takes 2021.3.2. The README also states that older releases remain compatible with 2018.3, 2019.1, 2019.2, 2019.3, 2020.3, 2021.3 and 2022.3. The release history in the repository follows the same pattern, with 6000.3.0 updating to Unity 6.3 and 6000.0.0 marked as the 6000.0 release.

## The built-in render pipeline is no longer an option

There is one compatibility break that can end an evaluation immediately. Starting with Unity 6 compatibility, the package is only compatible with the standard scriptable render pipelines, URP and HDRP, and the built-in render pipeline is no longer supported. A project still on built-in rendering therefore has to migrate its render pipeline before it can take the package. That is not a small change to schedule around, and it happens before any of the scripts are useful. The requirement is stated plainly in the requirements section rather than buried, which is at least honest of the project. The other requirements are milder: Unity 6000.0 for the latest version, and command line Git on your system only if you take the git reference install route or work with older versions.

## Three dependencies come with the package

The package metadata declares its own dependencies, and there are three, all version pinned. Two are Unity packages, com.unity.cinemachine at 3.1.0 and com.unity.timeline at 1.6.4, and the third is com.dbrizov.naughtyattributes-x at 2.2.1, which is the reason the scoped registry needs the com.dbrizov scope. For a Unity team those resolutions are usually unremarkable, since Cinemachine and Timeline are common in the same projects. The pinned versions are the thing to check, because an upgrade in the host project that wants a newer Cinemachine will meet a package that asks for an exact one. The package also ships starter assets and icons, which are conveniences rather than requirements, and the folder names suggest how the pieces are meant to be used, with runtime code, editor tooling and interface elements kept apart.

## Where Gameplay Ingredients is the wrong tool

There are two honest alternatives, and the difference is about where the work lives. The first is to keep writing the scripts yourself inside your own project. That means no registry to configure, no version tag to choose, no dependency on Cinemachine and Timeline, and full control over the code, at the cost of re-implementing the same behaviours for every new prototype. The second is to lean on the systems Unity already ships and build on those, using the animation and state machinery that comes with the editor rather than a package of assembled behaviours. Gameplay Ingredients earns its place when the same handful of gameplay actions recur across projects and the team would rather maintain one shared package than copy scripts. It does not earn its place when the project needs a single bespoke mechanic, when the render pipeline is built-in, or when a package whose last push was on 2026-04-08 is not a dependency your team wants to carry.

## Conclusion

Gameplay Ingredients fits Unity teams that want ready-made gameplay components and editor tooling for prototypes instead of writing the same scripts per project, and who are on Unity 6000 with URP or HDRP and comfortable with a scoped registry. It does not fit a studio still on the built-in render pipeline, a project on an old Unity version that is not covered by the published tags, or a team that wants a package with a steady commit stream, since the last push to the repository was on 2026-04-08. Before adopting it, pick the tag that matches your editor version, confirm that com.unity.cinemachine, com.unity.timeline and com.dbrizov.naughtyattributes-x can be resolved in your project, and read the documentation on readthedocs before you depend on it.

## FAQ

### How do I install Gameplay Ingredients in Unity 6000?

In Project Settings, open the Package Manager and add a scoped registry pointing at the OpenUPM registry https://package.openupm.com with the scopes com.dbrizov and net.peeweek. Then in the Package Manager window, choose Packages: My Registries, select Gameplay Ingredients and click Install.

### Can Gameplay Ingredients be installed from a local clone?

Yes. Clone the repository, add the same OpenUPM scoped registry, then use the plus button in the Package Manager window, choose Add Package from disk and select the package.json file at the root of the package.

### Which Unity versions does Gameplay Ingredients support?

The latest version needs Unity 6000.0, and older releases remain compatible with 2018.3, 2019.1, 2019.2, 2019.3, 2020.3, 2021.3 and 2022.3 through specific tags, for example 2019.3.7 for Unity 2019.3 and 2020.1.

### Does Gameplay Ingredients work with the built-in render pipeline?

No. Starting with Unity 6 compatibility it only works with the standard scriptable render pipelines, URP and HDRP, and the built-in render pipeline is no longer supported.

### What packages does Gameplay Ingredients depend on?

The package metadata lists three dependencies: com.unity.cinemachine at 3.1.0, com.unity.timeline at 1.6.4 and com.dbrizov.naughtyattributes-x at 2.2.1, which is why the com.dbrizov scope is required in the scoped registry.

## Sources

- [Issues](https://github.com/peeweek/net.peeweek.gameplay-ingredients/issues)
- [License: MIT](https://github.com/peeweek/net.peeweek.gameplay-ingredients/blob/master/LICENSE)
- [peeweek/net.peeweek.gameplay-ingredients on GitHub](https://github.com/peeweek/net.peeweek.gameplay-ingredients)
- [README](https://github.com/peeweek/net.peeweek.gameplay-ingredients/blob/master/README.md)
- [Releases](https://github.com/peeweek/net.peeweek.gameplay-ingredients/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/peeweek-net-peeweek-gameplay-ingredients