![]() ![]() Having to change every reference by hand when replacing a SO is okay for me, as I don't (yet) have any that are used by more than 2-3 scripts, also I like having those dependencies explicitly represented/"injectable" by the serialized fields on the client scripts.įor my exampe case, I've just come up with a "solution" that I might use: I'm also not sure if I'm overlooking something here, but the problem with not knowing if a SO is in use should in my case be solvable using "Find references in scene", pointing me to scripts with serialized fields of that type (of course this gets tedious with references in other scenes). I have yet to delve into Addressables, so I don't entirely understand the points about them (how can a ScriptableObject instance be part of a prefab?). You can connect the player and UI through events / delegates You can connect the player and UI through a scriptable object which holds a reference to Player data. You can create a separate Player scene that loads additive and have UI & Player references serialized. You can inject your player data into the UI using the UI as Singleton. You can have the player instantiate the UI and inject itself. But it is up to you as developer to choose one of those approaches as you see fit and what works for your project. ![]() They're all valid and they all have their pro's and con's. But it all depends on what does your project need and what makes it manageable.įor connecting a Player HUD with the actual Player Data there are so many different approaches. I made peace with a mix of Singletons & Dependency Injections. Singleton pattern is not necessarily bad but you have to manage it well. It went from one problem to another.įor a simple project without addressables I'd say it's an ok structure but as soon as it grows larger it becomes tedious. But then found myself I still had to replace all references to those references SO's. So then started using References to SO's. When I wanted to replace a SO, I had to replace them everywhere they were serialized. At some point I didn't know whether I could delete a SO, if it were in use or not. Besides it being annoying with Addressables, I had too many events with too many variables it cluttered my project immensely. I could fix it by moving everything to addressables but that made scene loading & editting a bother. Which caused things to break because of different instances. Due to using addressables some instances of ScriptableObjects were in the scene some on an addressable prefab. ![]() But after the project grew larger and when addressables came into play, I instantly regretted using this structure. I tried ScriptableObjects based on Ryan Hipple's talk. I've been experimenting quite a lot with structures. Looking forward to hearing how other people solve / dodge this. Is there a nice solution for this that doesn't need some sort of Find() method that relies on the scene objects being set up correctly (with a tag / their name / their position in the hierarchy)? Even worse the original problem still remains with enemy prefabs which can't have references to scene objects. Referencing scene objects from enemies that are also scene objects obviously works, but I would have to set up the reference by hand for each one manually (or is there some better way?). Then I thought about not using a global manager for the health bars at all (because duh), but a separate MonoBehaviour added to each enemy instead. That got me wondering about good ways to set up that reference, and I opted for GameObject.FindWithTag() from within OnEnable() which isn't great as it relies on the canvas object having the correct tag. Next I wanted to replace the Singleton with a ScriptableObject, but could no longer directly reference the scene canvas. Creating the health bar requires a reference to the canvas in the scene to use as parent (One overlay canvas, not multiple World Space canvasses). So an Enemy MonoBehaviour would retrieve the Singleton instance, register itself as a health bar "owner" and the Singleton would create the actual health bar, hook up events and so on. To manage health bars, I started with a Singleton MonoBehavior (with a public static Instance field set to this in Awake()) responsible for instantiating health bars from a prefab for each game object that needs one and updating it based on events from the game object. I think it's best if I explain what has gotten me to this point this time around: However, I haven't yet found a satisfying solution for when I need to reference a scene object / a way to properly design things so I don't run into that problem (at least as often as I do). After reading more about the Singleton design pattern and why it's mostly discouraged, I've turned to using ScriptableObjects which are "injected" into client MonoBehaviours via drag'n'drop in the editor for manager classes. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |