Jump to content
  • Advertisement
Sign in to follow this  
moeen k

Unity is mvc design pattern good

This topic is 675 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

how mvc design structure works in game development and specially in unity game development.

 

I know what mvc is and how it works but in coding structure for game development specially in unity I don't know how it really works.

 

as you may know is it a good structure for developing video games? if its a yes, why and how it should be used?

 

thank you for helping

Share this post


Link to post
Share on other sites
Advertisement

The MVC pattern

  • Model. The Model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the View), and responds to instructions to change state (usually from the Controller).
  • View. The View manages the display of information.
  • Controller. The Controller interprets the mouse and keyboard inputs from the user, informing the Model and/or the View to change as appropriate.

The Controller notifies the View. Both the View and the Controller depend on the Model. However, the Model depends on neither the View nor the Controller. This is one of the key benefits of the separation. This separation allows the model to be built and tested independent of the visual presentation.

03xpn.gif

And of course the Controller cannot be the only one who changes the Model. For that reason there are indeed some variations:

 

The passive model is employed when one Controller manipulates the Model exclusively. The controller modifies the Model and then informs the View that the Model has changed and should be refreshed. The Model in this scenario is completely independent of the View and the Controller, which means that there is no means for the Model to report changes in its state.

 

The active model is used when the Model changes state without the controller's involvement. This can happen when other sources are changing the data and the changes must be reflected in the Views. Because only the Model detects changes to its internal state when they occur, the Model must notify the views to refresh the display.

 

Note that this is only a UI design pattern and most Model-View-Controller connection combinations will work, but do not necessarly correspond to the MVC pattern (i.e. it is tricky to implement and stick to a pure MVC pattern as one can easily break the conventions...)

 

 

Is it any good for games?

 

The MVC pattern imposes a lot of connections which can become a design flawn in large codebases. One could alternatively use event/message buses.

Edited by matt77hias

Share this post


Link to post
Share on other sites

pehaps MVC comes to mind when thinking about games because of the similarities.

 

the Model is similar to the thing the game is simulating - such as shooting aliens (space invaders) - or running around in a medieval fantasy world (skyrim).

 

the Controller is simply the input devices (mouse, keyboard, touchscreen, etc)

 

and the VIew is of course, the output devices. Screen, audio, VR goggles, etc.

 

you might rename "model view controller" to "system, output, input" - which generally describes more or less all software.

 

 

in 40 years of game coding, "patterns" i've noticed include:

 

a main game loop with input, update, and output (render, audio,etc) capabilities.    Implementations vary widely - but pretty much all games contain these things somewhere. they are the basic components of simulation software. and almost all games are a form of simulation software.  in fact you might define a game as an entertainment simulation (apologies to you interactive story fans out there).

 

initialization, use, and un-initialization of assets and game data.   from how many squares there are in tic-tac-toe, to papyrus scripts for skyrim.   it may be hard coded or data driven - but its in there somewhere.

 

modules with init, run, and un-init methods. such as program, game, and mission modules.

 

lists of things (including lists of size 1) , and methods that operate on  the list or individual elements of a list.

 

there are other "patterns" in games, but it seems most all games have the ones mentioned above. 

Edited by Norman Barrows

Share this post


Link to post
Share on other sites

Those are some patterns, but certainly not the only ones.  I've seen hundreds of named patterns, including every one from the old GoF Patterns book. I've also seen countless other things that are still patterns, just not named and studied patterns.  On my bookshelf I've got a collection of good books describing patterns, smells, designs, and practices; all are variations of the same things with different names. If you look through any large code base you'll see the same fundamental patterns repeated everywhere.

 

 

 

Don't look at a pattern or design and say "I want to do that".  It is backward. That's having a solution and crafting a problem to fit the answer.

 

When you have a problem you are trying to solve, ask "What are the similar existing solutions?"  This will generally lead you to several well-studied patterns, each with well-known behaviors and pros and cons. Then you can quickly evaluate which existing pattern is a good fit, and adapt it as necessary for the problem at hand.

 

For example, if you have a problem where you have one set of data, you want to keep the manipulation of the data insulated and decoupled, and you want the display or other presentation of the data to also be decoupled, then MVC is one possible solution. MVVM and MVP patterns immediately spring to mind, but so do some other patterns for messaging, or for event handling and hierarchies passed between chains.  Many solutions may fit, each with their own small variations and quirks.

Share this post


Link to post
Share on other sites

I should also point out that following patterns religiously is in itself an anti-pattern.

 

The whole point of design patterns is to give you ideas on how to reason about how a system can work. How it can separate data and how information flow works. Often people take it way too literally and try to write classes with everything named "controller" or "view" or something.

 

The question should more be: in what scenarios is this pattern useful, or a variation of this pattern. Is there something I'm having trouble with that it could make easier or more intuitive.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!