When a Unity project is at its early stages we usually use the classic "Instantiate(...)" way to clone Unity Objects. That approach might later change to addressables, sometimes going back and forth during a project's lifetime.
This package contains wrapper scripts that let you decouple the sepcific instantiation implementation in your systems, allowing you to switch back and forth between the addressable system and the "old" way at any time.
Basic C# & Unity3D knowledge is required.
Since I am developing and maintaining this asset package in my spare time, feel free to support me via paypal, buy me a coffee or check out my games or other published assets.
See the API doc here
The current dependency is a fork with performance improvements (https://github.com/nikodemgrz/NaughtyAttributes) of the original open-source project NaughtyAttributes by dbrizov: https://github.com/dbrizov/NaughtyAttributes
Note, that the original NaughtyAttributes package is also compatible with this package in case you already have it installed!
Add the following git urls to include this package and my helpers package dependency:
"https://github.com/nikodemgrz/Unity3DHelperTools.git#upm"
"https://github.com/nikodemgrz/NikosAssets.Instantiation.git"
For my NaughtyAttributes performance improvements fork:
"https://github.com/nikodemgrz/NaughtyAttributes.git#upm"
The original NaughtyAttributes source:
"https://github.com/dbrizov/NaughtyAttributes.git#upm"
Using the serializable InstantiationData wrapper class in C# you can decide to either use an assetReference or a direct object reference in the inspector.
Since the call CreateInstanceAsync(...) needs to be awaited each time and has a little bit of overhead, it is actually recommended to call LoadAssetReferenceAsync() and use the data.CachedAssetReference afterwards and clone it via Instantiate() yourself.
Here is an example script:
using NikosAssets.Instantiation;
using UnityEngine;
using Random = UnityEngine.Random;
public class InstantiationTest : MonoBehaviour
{
public InstantiationObjectData materialData;
public InstantiationGameObjectData prefabData;
private Material _mat;
private bool _isDone;
private async void Start()
{
await materialData.LoadAssetReferenceAsync();
_mat = (Material)materialData.CachedAssetReference;
//slightly slower way to instantiate a gameobject (prefab or assetRef)
await prefabData.CreateInstanceAsync(transform);
//alternative way for the prefab or assetReference:
await prefabData.LoadAssetReferenceAsync();
Instantiate(prefabData.CachedAssetReference, transform);
_isDone = true;
}
private void OnDestroy()
{
if (!_isDone)
return;
prefabData.Dispose();
materialData.Dispose();
}
private void Update()
{
if (!_isDone)
return;
_mat.color = Color.Lerp(_mat.color, Random.ColorHSV(), Time.deltaTime * 10);
}
}
You can also use the MonoBehaviour variants that require a component reference you need to assign in the inspector.
In the following example either the AddressableGameObjectInstantiationMono or the DefaultGameObjectInstantiationMono component.
public class InstantiationTestWithMono : MonoBehaviour
{
public BaseInstantiationMono<GameObject> instantiationMono;
private async void Start()
{
await instantiationMono.CreateInstanceAsync(transform);
}
}
For custom Object types you need to create new scripts that inherit from either BaseDefaultInstantiationMono<TYourType> or BaseAddressableInstantiationMono<TYourType>.
The same goes for BaseInstantiationData<TYourType>.