ScriptableObjectCollection turns Unity assets into a typed lookup

The problem is assets found by naming convention

The stated problem is a familiar one in Unity projects. Most of the time, ScriptableObjects belong to some sort of collection: all your consumables, all your weapons, all your in-app purchases. Dealing with this is challenging because you have to rely on proper naming of those ScriptableObjects, and that becomes a problem quickly as the project grows.

The library's answer is to make the collection the unit of work. You create a collection asset, add items to it through the inspector, and the package maintains a registry of what is inside. Code then reaches items through generated static accessors rather than through a Resources.Load call with a hand typed string.

Two features follow from that and are worth separating. The first is code generation: the collection inspector has a Generate Code button that produces static access code for the items. The second is a property drawer: an item serialized through the inspector is drawn as a dropdown listing everything in the collection, so a designer picks from a list rather than dragging an asset from the project window.

The stated benefit for teams is that it makes ScriptableObjects more usable in bigger teams, and the mechanism for catching mistakes is the generated code itself. If an item goes missing, the documentation says you get an editor time compilation error, which it describes as super easy to catch and fix. That is a real advantage over a Resources.Load that quietly returns null at runtime.

Creating a collection is a four step workflow

The documented usage is short enough to follow without a tutorial:

1. Create new collections by the wizard `Assets/Create/Scriptable Object Collection/New Collection` 2. Now you should treat your new `ScriptableObjectCollection` as a regular `ScriptableObject`, add any item you want there 3. Now add new items to the collection by using the buttons on the Collection Inspector 4. After you are done, click on Generate Code on the collection to generate the Static access to those objects

The wizard is invoked from the project panel context menu, and the FAQ section describes what it creates: three items and a respective folder, namely YourCollectionName.cs, YourCollectableName.cs and the Collection Scriptable Object. So the collection is not a bare asset, it comes with a generated script and a collectable type.

Step four is the one that shapes the rest of the workflow. Code generation is not optional, it is how the items become reachable from code. That means the generated files belong in version control, that adding an item to a collection is a two step operation, add then regenerate, and that a designer working in the inspector and a programmer working in code are looking at the same collection through different doors.

The features list also mentions being able to expose the entire object to be tweakable in any inspector, and iterating over all the items of any collection by Collection.Values, which is the API path for code that does not want to enumerate the generated fields one by one.

The Resources folder registry carries a startup cost

The FAQ section contains the most useful warning in the documentation, and it is about where the registry lives.

The CollectionsRegistry is inside the Resources folder. That means every reference it holds, to a collection and to all the collectables, ends up inside the Unity Resources bundle. The documentation says that if you have a lot of references for expensive stuff, this can increase your startup time significantly. In other words, the convenience of always finding your items comes at the cost of always loading them.

The documented mitigation is a choice per collection. Items that should be available for the lifetime of the game belong in the Automatically Loaded items list. For expensive content, such as all the gameplay prefabs, you can uncheck the automatic initialization of the collection and register it during loading with CollectionsRegistry.Instance.RegisterCollection(Collection); and remove it when it is no longer needed.

A third option extends that idea. The Convert To References button in the collection inspector converts the items of a collection to references, which allows more flexibility to load and unload items individually, and those items are inserted into an Addressables group. That is the path for a project that treats its item database as addressable content rather than as a resident collection.

So the package offers a spectrum, from always loaded to manually registered to individually addressable, and the choice is per collection. Nothing in the documentation says which default is right for a given project, so the decision is yours.

Delete and duplicate operations are the fragile part

The first FAQ entry is short and unambiguous: it is really hard to make sure delete and duplicate work perfectly since the system depends on catching up with the GUIDs of the collectables, and the documentation says to always use Add New and deleting through the inspector itself.

That is a real operational constraint rather than a stylistic preference. The collection works by reference, and a Unity asset reference is a GUID plus a file id. If an asset is duplicated outside the inspector, or moved in a way that changes its identity, the collection's reference to it no longer resolves to what it did. The documentation is candid that the GUID catching is the fragile part.

The practical consequence is a rule for the team: assets in a collection are managed through the collection inspector, not through the project window's delete and duplicate commands. That is a process constraint, and process constraints are cheaper to adopt when they are stated up front rather than discovered when a build breaks.

Since the fix is to let the system catch up, the recovery path is to re-add through the inspector rather than to repair references by hand.

Dropdown or direct reference, per field

The property drawer offers two display modes and you choose per field rather than per project.

When you add a reference to a Collectable you can choose how it is displayed by adding the CollectionItemEditorOptions attribute. There are two draw types. DropDown is the default option, displaying all the available options in a convenient drop-down, like an enum field. AsReference is a standard Scriptable Object field where you select the asset in a browser.

This is a small feature with a large effect on the inspector experience. The dropdown turns a free form asset slot into a constrained choice, which means a designer cannot assign the wrong asset because the wrong asset was not in the collection, and the inspector itself shows what is available. The direct reference keeps the native Unity field and is what you want when the item does not belong to a collection, or when you need to work with an asset that is not managed by the package.

The feature list also mentions exposing the entire object to be tweakable in any inspector, which is the counterpart: rather than picking a single collectable, you can surface the whole collection object in a script so the inspector edits it directly.

For serializing a specific item into save game data or backend data, the FAQ points to IndirectReference, which stores only two GUIDs, or writing a proper parser using the ISerializationCallback. The two GUID storage is the compact option, and the ISerializationCallback route is the one to take when you need control over the format.

A Unity package, installed through a package registry

ScriptableObjectCollection is a Unity package distributed through OpenUPM under the name com.brunomikoski.scriptableobjectcollection. The package.json in the repository records the package as a library in the editor extensions category, with a display name of Scriptable Object Collection and keywords of scriptable object, collection and code generation.

Two version facts are worth separating. The documentation states the system requirement as Unity 2018.4.0 or later versions, while package.json declares a unity field of 6000.0, which is the newer Unity version numbering. The package.json also records version 2.7.0, while the newest tagged release is v2.6.0 from 2026-05-16 and the one before that is 2.5.1 from 2026-04-06. So the package on the registry may be ahead of the tag history, and the two version fields in the manifest describe different things.

The repository layout is a standard Unity package: an Editor directory and a Scripts directory for the runtime code, a Tests directory, a Documentation~ folder for the documentation, and a Samples~ folder. The samples section in package.json lists a single entry, the Addressables Loaded Collection, whose description says it shows how to build a collection managed by the Addressables system, allowing you to update it on the fly.

The project is MIT licensed and the last push was on 2026-10-14, with the release history showing v2.6.0 carrying bitmask accelerated queries and API cleanup, and 2.5.1 bringing a new processor and quality of life changes.

When the collection machinery is more than you need

Three cases argue against the package.

The first is project size. If you have a dozen ScriptableObjects and one collection, a Resources.Load by name or a direct reference in an inspector will do the job with no generated code and no registry. The generated static accessors and the Resources folder registry are the cost you pay for scale, and paying it early means paying it twice, once for the tool and once when you restructure.

The second is lazy loading requirements. The default behaviour pulls the collection and all its references into the Resources bundle, which the documentation itself warns can increase startup time significantly with expensive content. A project that has already committed to Addressables for its content will find the always loaded default at odds with that architecture, and will want the manual registration or the Convert To References path, both of which add steps the package would otherwise have handled.

The third is teams that move assets outside the inspector. The GUID bookkeeping depends on the system catching up with asset operations, and the documentation is frank that delete and duplicate are the hard cases. A pipeline where assets are generated or moved by an external tool will fight that assumption.

The alternative worth knowing is the plain pattern: keep ScriptableObjects as individual assets, reference them directly where needed, and use a plain C# registry class or a ScriptableObject of references as the lookup table. That gives you the same grouping without code generation, without the property drawer, and without the Resources folder commitment, at the cost of writing the editor tooling yourself. ScriptableObjectCollection is worth it when the generated code and the dropdown drawer save more time than the constraints cost, which for a team at some size they do.

Editorial conclusion

ScriptableObjectCollection fits a Unity team that has grown past a handful of ScriptableObjects and needs a single place to find, validate and iterate over them, particularly a team where designers pick items in the inspector and programmers reference them from code. It is the wrong tool for a small project with a dozen assets, where the generated static class and the Resources folder registry are more machinery than the problem deserves, and it is the wrong tool when assets must be loaded lazily, since the default registry behaviour pulls everything into the Resources bundle. Before adopting it, check three things: that your Unity version is compatible, since the documentation states Unity 2018.4.0 or later while package.json declares the unity 6000.0 field, that you have read the startup cost note about the Resources folder and the registry, and that you will use the inspector's Add New and delete buttons rather than deleting assets behind the system's back, because the documentation warns that duplicated or deleted items break the GUID bookkeeping.

Frequently asked questions

Official sources

1. brunomikoski/ScriptableObjectCollection on GitHub
2. Issues
3. License: MIT
4. README
5. Releases