koobas.hobune.stream
How do I hook custom inspectors up to models?
I'm trying to implement an MVC architecture. I attach monobehaviour view scripts to unit prefabs (e.g. unit = monster or player). The view scripts create control objects and the control objects create model objects on Awake(). I do it like that so that the model is editable graphically in the editor (e.g. when you add a prefab the view, control and model all get created automagically).
My problem comes when I try to edit properties exposed by the views in the editor. Ideally these would be implemented (using custom inspectors) with getters and setters and the actual variables being modified would be down in the model or the control (following the DRY principle). Now the problem is that while we're in the editor Awake() may well not have been called, so the control and model may be missing. I can't override the constructor for the view object to create the control and model when the view is created, as the view scipt is a monobehaviour and overriding the constructor of those is verboten.
What I think I want to do is create the model and control objects when I create an instance of a View script (in the editor or when we instantiate a prefab at run time). However that doesn't feel like the Unity way. I'd be grateful to hear people's thoughts on this problem and/or alternate implementations.
One way to do this is to add the model, view and control scripts to each prefab. Then the problem becomes how do I hook these up so that each part of the $$anonymous$$VC architecture knows about the others, e.g. so the view knows about the control.
Someone posted these links.. http://docs.unity3d.com/412/Documentation/ScriptReference/index.Accessing_Other_Game_Objects.html and http://docs.unity3d.com/412/Documentation/ScriptReference/index.Accessing_Other_Components.html I'd like to drag one script onto anothers public field in the inspector. That doesn't seem to work though.
You might want to check out StrangeIoC, it's an Inversion of Control library for Unity that will help you organize your $$anonymous$$VCS more cleanly.
http://strangeioc.github.io/strangeioc/TheBigStrangeHowTo.html
Thanks Dan. StrangeIoC appears to start it's DI work with a Context initialized in Awake() so won't solve my problem with the inspector? (in the section of their doc labelled "A ContextView begins...") It's also a lot of framework for what I want to do. I don't really need dependency injection and it just obfuscates what's happening if you don't need it? Finally the demo won't load for me (running under wine).
I've worked out a way of doing it. $$anonymous$$ake the model subclass $$anonymous$$onoBehaviour, the control subclass the model and the view subclass the control. Add the views to the prefabs. It breaks the "prefer composition over inheritance" dogma and it will lead to tightly coupled $$anonymous$$VC if not careful.. but since private vars in c# aren't visible to subclasses it shouldn't be too hard to keep things separate. It also doesn't scale particularly well (lots of subclasses) and it doesn't allow multiple views of the same control/model (which is a big deal).
Hedge, notice my long comment below the question on this question, (for a beginner who didn't know about patterns like statics etc, but as an expert you'll get the point)
http://answers.unity3d.com/questions/906946/best-way-to-organize-3-specific-script-interaction.html
and the various links to the "Grid" "system". (I say "system" in quotes since it is so so simple.)
Note that unity (indeed all game engines) are just shitty toy scripting environments driven entirely and totally by the Monobehaviour concept.
Having done it for yrs on the largest projects, I would just say that you cannot do MVC in Unity. Indeed, you cannot do real programming in unity. :) It's really just that simple. It's just not object oriented, is not, can not be, and never will be. That's all there is to it.
For example, what you said here ... "I've worked out a way of doing it. Make the model subclass MonoBehaviour..." etc etc Sadly, every "real" programmer who comes to a game engine, to unity, tries that first, wastes a whole lot of good time on it, and it never works! Just forget it. :)
It's only a game engine. open a scene, drop in a few monsters, jets, guns, etc. using c# as clearly as possible add a few scripts to make the monsters jump up and down etc. decide on some sort of trivial policy (like the "Grid." thing) so that you can very clearly access all the "singletons" {bearing in mind that all games heavily use "singletons" and that, cough, unity has no singletons, and the concept utterly clashes with coroutines, or indeed anything frame based, so in a word you simply use persistent objects with "some trivial system to easily access them"} for things like scoring, social media connections, etc, and that's about it.
if you think of using, say, oh Pages or Word (I mean to write letters), unity is like that but it also adds pictures and sound. You wouldn't bother trying to work out a real programming pattern to type stuff in to a letter in Pages. (You just move around and type it in right?) Pretty much ditto with Unity.
Hence,
"However that doesn't feel like the Unity way. I'd be grateful to hear people's thoughts on this problem and/or alternate implementations."
"However that doesn't feel like the Unity way." -- that is incredibly insightful and utterly correct :)
"I'd be grateful to hear people's thoughts on this problem and/or alternate implementations." the very best programmers in the universe having spent 1000s of hours on the problem all come to the same conclusion: just give up and do it "the unity way". This "general paradigm" pops up in a number of different aspects of unity work. :O So, one guy's opinion !!
Lol .. this is a very accurate of what happened to me.
Yeah.. I can live with singletons. I'm old enough to have learnt about program$$anonymous$$g before the whole singletons are bad thing came into fashion. Their only bad point I think is that they can make unit testing problematic. Which doesn't apply so much here.
right just TBC you CAN NOT have singletons (practically) in unity, unity has no singletons. it just doesn't mesh with the fuckin' coroutine / monobehaviour concept, never has never will ! :)
So I've checked out your Grid class and think it's a good idea. I've done something similar so far but in a less well thought out way.
BTW your link is broken above.. went off and found the code using search.
I suspect that the real strength of this architecture is that it provides a nice separation between the coding and the artwork. It does work against all my instincts at times though.
What I think I want to do is create the model and control objects when I create an instance of a View script (in the editor or when we instantiate a prefab at run time). However that doesn't feel like the Unity way.
I don't see why not. However, I think you're trying to use one View for both runtime and edit-time purposes, and that's a mistake. Make your Model objects first-class citizens (e.g. by inheriting from ScriptableObject), and create a custom Editor class to serve as the edit-time view for it.
Yes. I think that is the right approach. Provides a compromise between editability and nice separation of concerns for games where you need the model well isolated from the view.
