Singletons and large Prefabs, is this efficient?

[molten breach]

After applying this code for instanciating my singetons, i had the idea to put the related canvas inside the prefab, this way i can add references in there instead of GameObject.Find-ing them on spawn. Is this fine? Are there any issues that I should know about (size, lead time, errors, etc.)?

[molten breach]

My Players aren't singletons but are also huge prefabs including the player itself, various canvases and various managers (inventory, HUD, etc.)
This way I can just Instantiate this prefab to make more players and all the references are already setup within itself.

[storm cloud]

All this code does is adds a static typing to your prefabs

Usually what people do instead is using some prefab manager with a lookup table inside of it

namespace Game
{
  public class Player: Monobehaviour { }
}```
```cs
namespace Prefab 
{
  public class Player : MonoBehaviour 
  { 
    private static Game.Player _instance; 
    public static Game.Player Instance => _instance; 
    ...
  }
}```
```cs
Game.Player player = Instantiate(Prefab.Player.Instance)

My idea if I were to do it this way

[molten breach]

umm okay? i dont think this is relevant to what im asking
the code is fine, im asking if its fine to add a bunch of stuff to the prefabs so i can assign all the references in there (for example, the player to the inventory UI)

[clever girder]

replacing Find calls with serialized references is usually an improvement in nearly every way

[storm cloud]

Well, I don't understand why you'd link the code if it's not relative to the question, lol. But if the question is about prefabs in general, you'll not likely to run into problems unless you do have prefabs that load in heavy assets into mem, but otherwise you can make them as big as you want. Personally I like to chop prefabs into smaller parts and then combine them into one greater prefab.

[limber falcon]

As alawys, it depends. there is no like golden rule how compelx your prefabs can or should be. If you add 1000 empty gameobjects, you be fine. If you add one 20million triangle model, it probably break your performance or crash your device (depending on the platform) 😄 So its up to what is included in your player. If its just simple models and UIs for a player, I do not see an issue with that. Its also a question about reusing prefabs or not. so is every player the same, or do you have multiplayer and distinguish between local and remote players? That might add up to the complexity of your prefab and you might think about chunking it up and only load the relevant parts inside your palyer prefab/script. But thats just a lot of shots in the dark. you know your setup best.

[molten breach]

Its relevant because that's where its instanciated, I'm worried for example that if Instance has an issue the whole giant prefab would be created again and waste a bunch of space.

[molten breach]

I haven't worked with remote players yet, they're just local rn.
The prefab for players includes the whole inventory system, managers + UI.

[dry crest]

I'm not sure what you mean by this

"has an issue"?

[clever girder]

if you have problems that regularly mean you have to recreate prefab assets that's a sign you need version control not something you should design around 😛

[brazen dawn]

Always be wary of lazy loading your instance over an explicit lifecycle because it may end up loading at an inopportune time. If a prefab is large, that instantiate will be a significant performance hit, which is something that is ideally hidden behind a loading screen. Controlling the load flow also allows things to move to happen async with a lot less work.

[molten breach]

Not having problems right now, just wanna know if its bad practice

[molten breach]

Thanks, this is the kind of thing i want to know

[limpid stirrup]

this pattern forces a bunch of instances to exist in your game at all times, this makes it difficult to test your stuff, isolate parts and roadblocks when you want to reload/branch into a clean state. It makes it more difficult to create a blank slate of application state that you can get by not using DDOL/auto-instancing and a clean scene load. it also doesn't encourage portable/reusable systems that can slot into any architecture later. you can probably make a successful project with this approach, but it is ultimately a pattern that doesn't scale and if you build too much stuff around it you'll probably get stuck at some level of complexity. working your way out of that can be difficult if you've made the wrong assumptions about whats truly a singleton early on. Therefore, i'd keep eveything thats a convenience-singleton decoupled, as much as possible, from stuff thats not yet fully in its final spec.

a reliable pattern is to have a bootstrap scene that has this stuff instantiated, no DDOL and the rest of the 'game' loaded additively. Instantiate everything that needs to be procedural from a single bootstrap script. Then as complexity grows move away from self-instantiation and self-init because that only causes init/exec-order issues and move init into that bootstrap flow.

[fierce kayak]

this can lowkey suck for rapid prototyping though

when you wanna jump into a scene immediately

theres solutions to it but overall not a magic bullet

[dry crest]

I use RuntimeInitializeOnLoad to instantiate a single "game controller" prefab, which then instantiates everything else that it wants