Question All UI referenced to a global script VS every system controls It's UI

I've seen two interpretations of the MVP/MVC patterns in Unity.

One considers all UI as a unified View and all logic as a unified Model. They put all related UI scripts into a single folder called UI and then there is probably a global UIManager with references to all UI.

The other one considers every system a black box sealed system. So they do folders with the name of the system and they generate in there the model scripts and the view scripts. Every UI has its own manager so there is'nt a global UIManager referencing every UI.

I do consider the second option makes systems more portable and one I've seen in many packages and plugins from the AssetStore.

I think It also makes the project structure more expresive about what features the game has.

But I've seen the first approach in large projects.

Chop Chop and Fusion Battle Royale Demo for Unity Multiplay use that first approach.

What option would you recomend for a very big project ?
And how does that encourage code reusability ?

 

Key word is "demo" here.

 

Not going to express any opinion favoring one approach or the other.

Keep in mind that you can get away with a lot of things in games. Plenty of successful commercial games have what some might call awful code. Minor differences between programming patterns will unlikely be the main factor deciding whether the game succeeds or not. Just because you saw one or two projects doing something and not failing doesn't mean anything.

 

Single model, multiple views. Views only depend on the model, model never depends on the view. That‘s the most important architectural consideration. Everything else depends on the game.

For example if you know exactly what kind of game you are making and the UI is pretty much standardized since players expect them to work in a specific way and the UI complexity is rather low then you don‘t need to put that much thought into architectural separation. On the other hand if the game space and feature set is in flux and you need to experiment on UI style, layout and functionality and that over different game modes then a more sound architectural separation is helpful to make the UI adapt more easily to changes in requirements and design.

 

Now maybe I framed the question wrong.
The purpose of the question is to know if, when the project scales, what gives less headaches to a big group of developers.

I myself gone through both of the options. But never come to work wih a team of more than 3 developers regarding UI development.

So the question would be more like,
For a team of 5 to 10 unity developers wich approach makes more sense on the long term ?

 

Okay, in that case: Depends on the game AND the team.

If you have most devs casually working on the UI (and none of them like that) it‘ll be different than when there is only one very experienced and professional UI developer.

It also depends on the UI tech. IMGUI, UGUI, UI Toolkit, custom or 3rd Party GUI framework.

 

It really does. If you have one tech artist and all your engineers refuse to touch UI the answer is going to be quite different than if you have a team of engineers willing and able to learn and do tech art.

I am thankfully on the latter type of team. It's like heaven on earth.

Cruddy code in a revenue-generating game always beats out perfect code that is constantly being refactored to chase the latest MVC, MVVM, MVDingleberries and all the other MVs and SOLID and everything else that is the absolute bread-and-butter of earnest Medium articles about "Good clean code."

This is why it takes 45 seconds to open Visual Studio, even if I'm using it as just a text editor.