Something not clear to me about using MVC design with Unity

Hey all,

There's something that's not clear to me when trying to write a game using a MVC design with Unity.

Supposed I'm writing a simple Pong game. What's not clear to me is this:
Lets suppose an input event was received in the View, for example, the "up" key was pressed.Now, this event is then passed to the Controller which then tells the Model that puddle one should be moved up.
My question is, how does the Model then moves up the puddle? When using Unity regularly, I'd just add a vector in the up direction to the puddle's RigidBody object. But, in the scenario I described, the Model that I implemented now has to carry on the action of moving the puddle upwards. This means that I have to create my own Physics engine that contains the "moveUp" command, doesn't it?
How can I take advantage of Unity's Physics engine while writing the code using MVC design?

Thanks in advanced for the help

 

I'm having trouble understanding your question. For an example like pong, you wouldn't need to write a physics system. You could simply map the key inputs to the movement direction you want the paddle to go in.

Example, use Translate to translate the paddle up as long as you hold down the "W" key.

 

Thanks for the quick reply.

I actually only gave Pong only as a simple example. The same principle could be applied to a 3D FPS game in which Physics are much more difficult to implement by myself.

 

Consider the built in physics engine an extension to your model. The rigid-body properties such as transform should be operated on directly by the controller.

 

Ok, I'm starting to see what you mean.
But I don't want to get the View and the Model mixed up. Do you suggest I create 2 game objects and use one just with RigidBody and without a Renderer, and the other with just a Renderer and without a RigidBody and then mimic the movement of the first object on the second one?

 

I don't think the Unity framework was designed with MVC in mind so, if you really want to apply MVC, you will probably need to put up with these weird inconsistencies. Someone may have a more clever way of implementing true MVC but in the meantime maybe this perspective will help:

If you remove the main camera from your Unity scene, the game engine will not stop applying physics - the simulation will continue. In that sense, the View component of MVC is the rendering done by the unity camera code. You can extend this View by adding custom UI elements but outside of that I would just ignore the View aspect of MVC and focus on extending the Model and implementing the Controllers.

 

Ok, I'll think about it some more but in general, I think that your idea is the direction I'll take.
Thanks for the help.

 

I've found zero benefit in trying to implement design patterns in gamedev with Unity. I suspect this would be the same irrelevant of engine choice. MVC is a business software development pattern and makes sense there.

There are bits of patterns that would be of use, but if your game has less than 20,000-30,000 lines of code, I don't think its big enough to justify the use of an mvc pattern. Im sure others with disagree, but I dont care, Im all about streamlined/fast code with no overhead.

I do use singletons a bunch though.

 

One design pattern that did catch my eye recently is an entity system framework implementation released as open source by one of the community members. You can read the thread here: http://forum.unity3d.com/threads/ro...yle-entity-component-system-for-unity.335182/ or skip the tldr; and go straight to the source and documentation https://bitbucket.org/dkoontz/robotarms

I think this kind of design will make more sense for games than MVC once you wrap your head around it.

 

I occasionally use MVC principles, without resorting to the full blown pattern. Normally the rigidbody is on the parent GameObject (ie the model), the renderer and graphics stuff are on a child GameObject (view). Their is normally a separate component for input (controller).

It's only vaguely MVC. But it's works well enough. Just keep the model, view and controller all in separate scripts and you can get benefits from the pattern.

I agree with the general comments about the pattern not being overly applicable for games. The full blown MVC is for when you are dealing with a server or database external to your application. Valid for an MMO, but not so much for a smaller game.

 

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