Poolable Components

[antfarmar]

Poolable Components are currently added to objects at runtime during instantiation by the Pooler.

• This affects when references to the component are available.
  • Can't be on Awake!
  • Currently at OnEnable.

Choices:

1. Leave as is. It's not a real problem yet.
2. We could add the Component to the Prefabs of all Poolable objects:
   • In the Editor.
   • In the source code using [RequireComponent (typeof (Poolable))] attribute.
   • Reference: [RequireComponent (typeof (...))]

This would allow more flexibility in where initializations take place.

[ghost]

Option 3: Don't burden your components with logic regarding pooling. It would be cleaner if you could just call say RemoveFromGame or some similar simple and descriptive name, which deals with the plumbing in the background.

Before After (base class deal with details)

[antfarmar]

You're getting ahead of me with these event shenanigans! :smiley: Good idea and use of events! :+1:

Your rewrite of Poolable.cs helps make your solution and comment all clear to me now: it's event driven! :mega:

Link to Poolable.cs

A snippet:

public interface PoolableAware : IEventSystemHandler
{
    void PoolableAwoke(Poolable p);
}

void Awake()
{
        InstantiationGuard();
        ExecuteEvents.Execute<PoolableAware>(gameObject, null, (script, ignored) => script.PoolableAwoke(this));
}

[antfarmar]

Game objects now have a base behaviour class GameBehaviour. They all become "aware" of their poolable status through events, executed on Awake in Poolable.

public class GameBehaviour : MonoBehaviour, PoolableAware, Recyclable
{
    Poolable poolable;
    void PoolableAware.PoolableAwoke(Poolable p) { poolable = p; }
    public void RemoveFromGame()
    {
        if (poolable)
            poolable.Recycle();
        else
            RequestDestruction();
    }
.
.
.