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.

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.

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)

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. :slight_smile: 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. :slight_smile:

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 :slight_smile:

“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. :open_mouth: So, one guy’s opinion !!