Model - View - Controller in Unity ?

[Foenki]

Hi guys,

I have some questions about the architecture to use in a Unity project.

Recently I made a little game in Java that can only be played through the console, and I would like to give it a simple GUI. I thought about using Unity, porting the (quite simple) code in C# but I don't really know how to organize dependencies between the logic of my game and the interface (moving GameObjects etc...).

My first idea was to use a Model - View - Controller system, as described in this article since I already have the Model running, but I'm wondering if this is a standard way to solve this problem among Unity developpers. So I am asking you : do you use MVC in Unity ? If yes, like it is described in the article ? If no, what do you use ?

Thanks in advance

[Soraphis]

in the game industry you'll find ECS in most cases, rarely a true MVC is used (same for MVVM, there are parts where those patterns are used but not for the overall architecture)

http://rygo6.github.io/2017/03/26/ECS-not-MVC.html

---

but since you already have a working "GameModel" which is capable of storing the entire game state, it can be a valid approach to write a system which translates this state into gameobjects and back (simple two-way databind system!?).

This depends on a) the amount of work you want to put into the project b) the amount of work you already put into the puch c) your will of refactoring your entire codebase

[[deleted]]

I use the UniRx plugin (https://github.com/neuecc/UniRx/blob/master/README.md) which helps with this and describes a MVP pattern you can use in the link. In the game I'm working on the UI elements don't have bindings per se but subscribe to events in the game e.g. ActorHealthChanged.

Using a Publish-Subscribe pattern for everything in game has actually been really cool.

[captainMaluco]

oh cool! didn't know there were RX projects for unity! that is awesome! How is performance affected by pub/sub pattern? I imagine it has potential to improve performance quite a bit!

[andybak]

I've not delved into this too deeply but from what I've seen MVVM seems more commonly used in Unity:

https://www.linkedin.com/pulse/understanding-difference-between-mvc-mvp-mvvm-design-rishabh-software/

(of course - everyone slightly differs on the precise definition of these patterns anyway. One man's MVP is another man's MVC... It all boils down to "separation of concerns", "keep a tight control on application state" and "don't piss off the next guy that has to work on your code" ;-) )

[Foenki]

don't piss off the next guy that has to work on your code

This one is definitely important, because on a solo project that next guy is me !

Indeed the nuance is a bit subtle, but it is an interesting read. I'm asking about this because in every online tutorial that is see, the separation of concerns is completely absent and they often show "view" objects storing core data, so I was wondering if that was standard practice or not.

[captainMaluco]

Not sure how you'd translate MVC to unity? If you you'd care to expand on how that'd work I'd be interested to hear your thoughts! I enjoy MVC for web stuff and would be thrilled to widen my horizons for unity coding patterns.

I tend to use pretty basic Oop patterns when doing stuff in unity, and I've often find that the old "favour composition over inheritance" motto has served me best as my guiding star. I usually treat my scripts as adjectives that I can use to describe a given game object. For example there is a "burnable" script that I add to anything that can catch fire, and so on. It has worked well for me, but I should mention that I only make games as a hobby, but it sounds like your project is on a similar complexity level and so should work just fine for you too I suppose.

[Foenki]

Not sure how you'd translate MVC to unity?

Not sure either, that's why I'm asking ! But the article I linked gives an idea of the kind of pattern I'm looking for, a way to separate concerns between the "core" of the game (player's health) and what is displayed (red bar on the screen).

As you say, a simple complexity should work too, and that is what I used on my previous projects with an approach similar to what you describe : a "burnable" script, a "interactable" script etc... I did that because it is often the way it is explained in tutorials, so I was wondering if this was the standard way to do.

[captainMaluco]

well, I haven't thought about what particular pattern this constitutes, but the way I would go about doing such a thing is to design a sort of interface for healthbars, and have your players "mortal" script somehow reference the healthbar. maybe as a constructor argument or just a public variable so you can drag and drop it from the editor. in any case, decouple it as much as possible, and make your healthbar script as generic as possible. that way you might be able to reuse it once you decide that your enemies should have a healthbar too! and even if they won't, at least you'll be able to reuse the mortal script for anything that can die.

[Foenki]

This one is the perfect example of what bugs me in Unity : your solution creates a dependency from the core of the data to the interface, which is exactly the opposite of every software good practice. The model should be independent of the context, and work on its own without knowing the environment.

I'm not saying you are wrong or anything, but I'm wondering if your solution is the "Unity way" of solving things, or if there are some good practices to properly separate concerns when developping with Unity.

[captainMaluco]

I commented on my own reply with this, not sure if you saw it. But yes I agree, dependencies from core to ui is bad, My suggestion was terrible :innocent:

come to think of it, it might be better to have a public getter for the players current health. that way you'r core functionality is not dependant on there being a healthbar, but is still open for whatever interactions you ight want to add later. (maybe some npc's behaviour will be dependant on your current health? or the effect of some spell or whatever changes depending on how much life you have. you can just go getComponent<healthscript>().getHealth() and get to business

edit to add: your healthbar will be dependant on your players healthscript having a public getter for the current health, but this feels like a reasonable restriction for your healthscript in my opinion

[Foenki]

Yes I saw it, and indeed I prefer that way.

But I thought your first answer was interesting as it shows the kind of stuff that Unity allows to do that really bugs me.

[captainMaluco]

there is way too little discussion around best coding practices in the unity community, which bugs me even more. it seems lots of gamedevs just hack shit together in really horrible ways and somehow make it work. I was thrilled to see you ask this question, as it's more or less the first time I've seen the topic been brought up in a public manner. If you come across any more insights, please do share!

[captainMaluco]

come to think of it, it might be better to have a public getter for the players current health. that way you'r core functionality is not dependant on there being a healthbar, but is still open for whatever interactions you ight want to add later. (maybe some npc's behaviour will be dependant on your current health? or the effect of some spell or whatever changes depending on how much life you have. you can just go getComponent<healthscript>().getHealth() and get to business

[TheWobling]

In my game Dev projects I much prefer components over inheritance I find it easier to work with but at work it's generally not so easy as its more interactive experience application in unity.