The scenario: I’ve got pools of pre-instantiated prefabs to ease the burden of calling GameObject.Instantiate() on demand. In the inspector, I can drop in prefabs as List elements, then during Awake(), at least one of each gets instantiated and added to its own pool. When I want to access one, I have to call PM.instance.Spawn(“nameOfPrefab”…);
Though I doubt it means a whole heck of a lot in practice, it sure would be cool to avoid calling the prefab by its string name. Is there a way to do this that doesn’t involve setting up associations manually? I really dig the convenience of having the PoolManager be fully modular - manual associations would require editing a file every time I add a new prefab to the system, which I’m trying to avoid.
That’s the issue - I don’t want PoolManager (or any script) to require changes for each unique prefab, such as adding Enums by hand. Ultimately, it’d be neat to say something akin to PM.instance.Spawn(PM.Enums.NameOfPrefab…); without having to add each prefab name to PM.Enums
How might I go about achieving behavior similar to this? Should I just stick with string names? Thanks!
1 Like
Just to be clear, is your real goal here ease of coding (intellisense with the enum) and not necessarily trying to reduce the performance impact of using strings?
Honestly, I think it’s bad practice - and I really hope someone has a better solution for you - but you could always create an editor script that creates a C# class automatically for you (and have it auto-regenerate on asset import). Basically you’d write a class that creates a new .cs file (or overwrites the existing one) and populates it with the names of your prefabs as members of an enum (by checking a certain folder in the asset database).
The primary goal was to eliminate the need for string arguments for performance reasons. To have intellisense auto-completion, I’d have to do something like you suggested, which is unfamiliar territory. It sounds potentially messy, but it’s a pretty creative way to provide that feature! It would also give me compile-time errors when something changed, which would be nifty.
I guess there’s no harm in coding enums that correspond to each prefab when working with a new project, really. Convenience has to end somewhere, after all. I don’t see a great way around it without giving scripts that call PM.instance.Spawn() variable references to the prefabs they want to spawn. The whole concept of calling it by its name feels irresponsible but it’s dead handy. How expensive are string comparisons, anyway? Is it worth giving up that convenience?
Further advice will be appreciated, 
Honestly, negligible enough to where I wouldn’t worry about it. Unless you’re spawning a ton of things frequently - in which case it may be worth coming up with a cache system where you can say something like…
int _bulletPrefab = -1;
void Awake(){
_bulletPrefab = PM.Instance.GetIndexOf("Bullet"); // Option A: Just write a cache function
}
void SpawnBullet(){
if (_bulletPrefab == -1){
_bulletPrefab = PM.Instance.Spawn("Bullet"); // Option B: Have two overrides for spawn, one of which accepts a string and returns the index of the prefab
} else {
PM.Instance.Spawn(_bulletPrefab);
}
// Option B - Inline
_bulletPrefab = PM.Instance.Spawn(_bulletPrefab == -1 ? "Bullet" : _bulletPrefab); // This would require the index version to return the index as well, which is kinda ugly - but lets you do this in a single line instead of requiring an if/else - I'd go with the if/else though
}
Hey, thanks for your commitment to helping me out! Quite above and beyond. Establishing index relationships instead of enums might take a similar amount of work, just distributed in different places. Either could be centralized for easy changes, too. I’ll keep this idea in mind…
Perhaps I should abandon the idea of having the sheer convenience of string names without additional coding. Unless I were to attempt your automatically generated enums file idea, that is. I’m trying to make a plug-n-play pooling solution for my Great Big Honkin’ Universal Asset Package, but string arguments may indeed be the best way to avoid coding alternative approaches on a per-project, per-prefab basis.
In any case, I’ve learned of some neat alternatives. Many thanks!