![]() ![]() But from watching the video I wouldn't be populating most of them like that (outside of test scenes, which he makes great points about), I'd be doing some kind of dynamic lookup at initialisation time and/or when a relevant event is raised. Yes, he shows how to get that reference by dragging it from the Project view, and I've often scratched my head when people showed me this as a great new trick they'd learned. Showing up in the Project view is neat, but is only relevant for stuff that you want to put in a designer's hands, and is probably an unwanted overhead elsewhere. I strongly suspect that when an enemy spawns it just instantiates its own, memory-only FloatVariables for relevant fields. But he also points out that they can just exist in memory, which I imagine is the case 99% of the time. The examples in that talk are trivial, and because of that he can have his fields wrapped in SOs which are stored as Assets which can be clicked on in the Project view, which is neat. Unity didn't support it at all in the past, and it unfortunately still doesn't in the Inspector, but it's been supported by GetComponentOfType for a while now, which means that we can use it when looking for objects whos' events we want to listen for.Ĭlick to expand.I do wonder if some of that is because the examples are being taken out of context? That's not true any more, Unity has Prefab Variants to do exactly this, so that's an entire class of use cases for which I think this is now outdated.Īs another example, C# has the concept of "Interfaces" which exists specifically to solve the problem of references having to be explicitly typed. So my number one suggestion is to ensure you understand the problem that each of these things is solving for you, and see if other changes since the video was made might offer better solutions.Īs one example, he talks about minor variations between different enemies being a pain because prefabs can not share data. I just finished a very UI heavy project and it was not pretty! I would love to see an example of how a SO could be used to simplify exactly what you are talking about.Ĭlick to expand.Do note that this video is ~5 years old, and I'm pretty sure that it pre-dates some built-in solutions to some of the problems it solves. This is why having 3 built-in UI systems is a PITA, just pick one already! Of course, I had to use animated UI's and so couldn't use UI Toolkit. I feel like the UI Toolkit will ultimately do this best, so when/if that tutorial is ever writting hopefully it will use UI Toolkit. Does Unity have a single authoritative example for how to set up UI's correctly that will scale? That worked fine for one, simple UI but then the client needed many more 'modes' and it's a delicate mess of hooking up this to that, etc. The close buttons on both closed their own panel and 'enabled' the main UI again. For example, a button to show a screenshot gallery would open a gallery/grid panel of thumbnails (same button disabled the main UI), but if there were no thumbnails, I need a different tutorial/information screen to open. ![]() What I did was a nightmare of hooking up buttons to suit the mode. I wouldn't want it in game logic, unless we'd be dealing with a plethora of (configurable) variables.Ĭlick to expand.I just finished a very UI heavy project and it was not pretty! I would love to see an example of how a SO could be used to simplify exactly what you are talking about. ![]() I would hesitate using SOA for anything BUT decoupling the UI or potentially some other kind of "external source" like synchronization with a Web or DB API (ideal for caching and using local value store for testing). Until then, it was common for UI to break, based on modes or changes to business logic, which aggravated the client (are you even testing? ). Let's just say without SOA it would have caused TREMENDEOUS headaches, and in fact it did until we added SOA just about one year into the project. We had many different modes that affected UI (can't do this in that mode, limit this slider to other values based on some other setting) and different UI modes as well where the same functionality was accessible via drop-down menus, world-space UI (hotspots), VR specific UI and then VR + LeapMotion hand controlling GUI. When it comes to complexity: I have had SOA in just one large project (team of 4 working on it for 3+ years) and there it was mainly used to take a lot of grunt work and potential points of failure out of the UI. Just because in case you don't feel like going into wheel invention mode.Īt a minimum there's a ton of nice little solutions for just about everything around this architecture. Btw, there are a gazillion implementations of the ScriptableObject Architecture on github alone. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |