How to....MVC pattern

Hi guys I know that my English is poor , then I have to work with unity and I am in the area of programming :wink: , as I implement layers in Unity? :idea: would be possible to use the MVC pattern :?:


Regards
Taborga

 

Hi, welcome to the forum!

Can you give a bit more detail about what you need to do and how you imagine the MVC pattern working here?

 

I am interested on that topic too, it is possible to implement it? which will be the best way?

 

I am trying to design my framework and I would like to use an MVC approach if it is possible.

There is someone with enought knowleadge of unity3d to answer that? (I have read somewhere forums are leaving lots of questions unanswered, hope is not as bad).

Has been 2 weeks since I asked that in another topic and no good answers neither it could be a little frustrating if we can't have a proper support.

There is not anyone from unity team to help here?

 

As I replied to you before, design patterns are tools that help you solve certain common problems. First there is the problem, then there is a design pattern that helps you find the solution.

You appear to go about it the other way around: you have a pattern you want to use (MVC) and are now looking for the problem it will solve. I don't see the benefit of this approach.

On a more practical level: I have often used design patterns in Unity, for several very different problems in several different games. I have never encountered any need for implementing MVC. That's just my experience, though.

 

Yes you are right but I already made that and I would like to use a MVC pattern because is more convenient for my project than a component base. I have concerns about game object too and I would like to use the minimum of them. But my question still there, I will try to make it very clear.

1- It is possible to use MVC pattern with and event manager in unity3D without having too much problems to implement networking, new culling system... ?

2- It is possible to use a factory pattern (abstract class) which is not inhering from Mono (I will update it through my own main class)?

 

unity is based heavily around the components, there is no way to avoid.

Might be that you are interested in using MVC but as posted above: Patterns are to solve problems you encouter, forcefully using one is pretty much the worst thing you can do and goes totally against the idea of them.

MVC in unity at very best makes sense if you implement an own gui system, but I don't see any other field where its not just a lot of work for nothing and thus wasted time.

 

I can see that this thread is old, however we are investigating Unity to decide whether it would be suitable for our development team, and I do find this discussion startling.

Finally I am wondering whether SNoChE, Taborga or anybody else found a satisfying way to develop their game framework or game using MVC and Unity.

Although I doubt this requires an explanation, here is why I feel not only wanting to use MVC is legitimate, but also *whether* a toolkit is compatible with MVC or not may be a deal breaker in adopting a toolkit.

MVC is an architectural (meta)pattern. As such...
- It has been widely adopted in writing front ends, including games, not just because it solves one particular problem, but because it makes it generally easier to solve several problems.
- Being a metapattern, MVC can be instanciated in a variety of ways. I would be intrigued and even worried to find out that a toolkit cannot support MVC in a few reasonable ways (I actually believe combining MVC and Unity shouldn't really be a problem).

I know very few cases where using MVC is unavoidable and indeed many projects that do not absolutely require defining model, view and controller layers use it.
Here are two reasons why developers do not wish to tie their game/business logic to a particular UI/rendering library, or even their own UI code, even if the UI/rendering library is cross platform:

- MVC separation promotes clarity, helping us consider problems one at a time using (what has become) a widespread, intuitive approach.
- The UI/view tends to evolve faster than the game logic. Being able to modify the UI without worrying about breaking the game logic makes maintenance faster and easier.

I think the adoption of MVC in the software industry is wide enough that some developers will just find it convenient, being trained in using MVC components rather than coding another way, and surely they can be forgiven for not articulating their request around a specific problem, in the same way that some developers will look for packaging/scoping/namespacing constructs and feel vaguely upset if a language doesn't provide this facility.

So... finally did anybody successfully combine MVC with Unity? Using a custom framework or a documented MVC framework...?

Thanks

 

I'm using a MVC pattern mixed with 3 or 4 singletons.
Additional info, framework is actually 10000+ codelines long, with 40~50 classes (and growing).

I first used no pattern at all in my alpha version, but it started to be too much complicated to separate data, view, and controllers. I had a lot of class intricated functions that were doing a totally different job, which is not good for clarity.

So I jumped into MVC, with sub-mvc classes for different game parts (menus, main game, misc scenes, etc), and I admit it helps a lot.
I'm not a code heavyweight, though, so it's not as elegant as it could be. But it's much, much clearer and easy to maintain than with random components.

I also created other custom classes of course, that could not fit into MVC (like specific action treatment, state machines, etc).

IMHO, MVC is really important in a game, as you always need to pick out specific datas, translate it, and send it to the view.
There is so much data to handle in some game types, and so much controls to make over that data (even more with touch controls), games are becoming so much complicated, that I could never look back to random components.

But this is just my subjective opinion, of course ;-)

 

Thanks n0mad.

I can see where you're coming from, and I think your story is encouraging (e.g., encouraging me to look further into this attractive toolkit).

And... no... I don't think the component oriented approach has to be wrong. In fact I don't like to be locked into an MVC framework because it easily gets tedious, but I often find myself refactoring to MVC in my personal projects, and more often than not, I find MVC can make the difference between bleeding chaos and positive collaboration when working as a team.

 

Hi!
I write a tutorial how to implements MVC for unity. Read it here http://unity-tutorials.blogspot.com/

 

thanks for this i've been thinking along the same lines..
the main thing i want to acheive is being able to access ui elements in unity as composed programmatic objects at a higher level than our ui library (ngui).

i.e. not have to do lots of Object.Find(..), getComponent etc in all the display code

 

I'm doing it and not just as MVC but as MVCL which I find will be a hand later on if the game succeeds and I need to translate to many other languages. I simply created 4 folders in Assets named MODEL, VIEW, CONTROLLER and LANGUAGE. After that, I separate everything that seems appropriate to each of the folders and duplicate those that need duplicates such as Character, Classes, Environment and so on. MVCL is a terrific solution and I disagree with the point raised

this is an old fashioned view of developing systems (not being impolite to the one who wrote it) cause it privileges structure over design. Nowadays, it has been shown by many big successful companies that if you privilege design over structure you'll get much better results.

see ya

 

You're living in fantasy land if you believe that. For greenfield development, this certainly works. But that's not the case with Unity. You are scripting into an existing engine that already has an established architecture (Components). You can build a lot of MVC pattern things to work within Unity but that doesn't mean you should try to work around Unity's existing architecture and force everything into it. That's just bad practice. If you do any enterprise level development out in the professional world you'll learn that in a hurry.

Look at existing tools for example. Let's say you're building a brand spankin' new MVC website. Unless you're building a simple quilting website for your grandma, you're going to leverage several patterns. If you force everything to be "MVC" then you're going to have a tightly coupled mess of garbage when you get done, when instead you should be leveraging lots of different ideals. You're going to be working a data layer and web services and likely to be using additional patterns such as Factory and Locator which really have absolutely nothing to do with MVC.

And imagine you have an existing old school Web Forms project. Just because you as a developer think it should be MVC you start architecting and building around WebForms and forcing everything to support "MVC". You may succeed... however you've created a lot of extra technical debt in the process. You've also spent a lot of time just building out supporting architecture. The guys who sign the paychecks in the corporate world care about money, not patterns... and while projects like this are "cool", they make you less productive and as a result... less employed. And for good reason... why "fix" something that isn't technically "broken".

Which brings me back to the original point. Patterns are not necessarily to solve problems themselves, but they are the framework through which you devise the solution and they are used out of necessity. If you need to go to the store, you'll take your car. But if the road you live on doesn't support cars and only allows busses, well then you'll take the bus. You're more than welcome to get out your brick and mortar and start paving your own road to drive your car on, but what would be the point?

And so come the questions... I see comments from the original poster and you talking about how great MVC is as a solution... But:

1. Why? What benefits does it provide you?

2. What are the drawbacks of the approach?

3. Do the benefits outweigh the costs? And if so... how?

As a professional developer that contributes to enterprise applications (primarily MVC based web applications) on a daily basis... I fail to see how forcing Unity into a MVC pattern is at all beneficial.

 

I had a feeling. A lot of people, like myself, are on this MVC kick where they're convinced it's the best thing ever and it needs to be used on everything all the time.
However, It's just one of many design patterns, and highly incongruent to the Unity (Unitarian?) way of doing things.
Having the data representing the state of a GameObject anywhere other than on the GameObject in the scene just makes things complicated, not easier.

 

May I ask if anyone evaluated if the mvc pattern gives an advantage on cpu/gpu load on mobile devices? I could imagine, that too many monobehaviour scripts may slow down the experience on old devices if too many update() functions are called, but I never tested it.

 

I'm with Dustin Horne on this.
MVC has its uses and I've 15 years experience using this approach and others with many varying applications, I've only ever employed MVC for Websites and desktop applications for which MVC was absolutely the best approach for the design and UX of those particular applications.

Don't go into a project thinking you must use a particular design pattern or framework.

I've worked with many developers who fall into this trap, myself included; resulting in a sub-standard product and a real sense of "If only". All because of the constraints imposed by desperately fudging the application to use a framework or pattern.

Focusing too much on using the latest tech or favourite framework than the end user.
You must remain open-minded, there are always different and/or better ways of doing things.

 

Maybe this can help!
http://forum.unity3d.com/threads/ar...how-to-level-up-your-game-development.344631/

 

Have you tried Strange IoC? (http://strangeioc.github.io/strangeioc/)
Is an Inversion of Control/Binding Framework that could help you to build your games/apps based on an MVC pattern.

 

Yes! Searching for MVC and Unity I stumbled on this framework!
Usually I prefer more simpler alternatives, it got confuse when I saw the diagram and descriptions of the concepts.
The framework I've made are simpler scripts with straightforward rules. No need to injections and binders.

You just need to:

1) Extend BaseApplication
2) Do 3 scripts extending Model,View,Controller each
3) Create variables on Models i.e. (float var)
4) Call Notify("some.event.path") or Notify("some.event.path",[data0,data1,...]) inside the View
5) Override OnNotification(string path,Object target,params object[] data) in the Controller
6) switch(path), decide your workflow and modify app.model.var

* This would be a good Hello World

There! Basic MVC in 6 steps using my framework