let me say it, I do not like Unity Framework. Let me more precise about it, I actually like the way it pushes the developer to add behaviors using composition and not inheritance, but I actually dislike all the rest, or at least most of it.
Thanks god, Unity supports c# and so I can create my own framework to manage everything I think it is just bad code design in Unity Framework.
Although this is the first time I work with this tool, so I would like to understand the good practices in order to judge it definitely.
Of course I am not talking about prototype/one man developing here, I am talking about big project management with multiple developers involved and code that must be maintained over the time.
My question is simple, how do you usually split the logic and the graphic? I am talking about MVC, MVP, MVVM here or anyway everything that allows a clear separation of concerns.
To be more specific, my doubt is, does it make sense to use GameObject or even GameObject hierarchies to just hold Pure logic or pure data classes?
I know that this is probably a highly controversial subject, but imo MVC and friends do not relate very well to games, as graphics and logic are intertwined in a lot of cases. Of course there are cases where this is not the case (e.g. board games etc.), but in most cases you don’t design a game to replace graphics frequently while keeping the same logic. (unless you are working for zynga et al. ;))
That said it is certainly possible to do that within Unity although the idea behind is a probably a different one. Most importantly you don’t have to attach anything to a GameObject if you don’t want to. Of course you won’t see anything then, but you can use plain .NET or rather Mono code as much as you want. So in theory you could do your whole game “in-code” and just move a few GameObjects as your graphical representation. So in this case you could think of the scene as your “View”. Although on a more complex game you will probably notice that it actually makes sense to have GameObjects with actual Behaviours that can react to the surroundings/collisions etc. directly. Again you are free to write or use a centralized AI-framework for that (as many of us do).
Depending on your team’s workflow it can make total sense to add data classes to GameObjects, as that would allow your Game/Level Designers to modify this data on the fly while tweaking the game. But that totally depends on your specific needs. If you don’t want/need that you could also get all your data from a database/textfiles/googledocs etc…
Unity is based on Entity Component System (ECS) architecture. This carries a fundamentally different perspective on how to manage code and complexity as compared to any MV* or Presentation Domain Data type architecture.
You can find some valuable mentality in MV* to take with you to ECS and game programming, but fundamentally you should just forget about all MV* related subjects.
Interactive websites, where MVC is highly popular, and 3D interactive game programming, where ECS is popular, are highly different problem domains. You should not expect the architectural perspective of one problem domain to thoroughly transfer to another problem domain.
It’s also of note that UE4 runs on a similar ECS type architecture, as well as Lumberyard and Mozilla’s new A* framework. ECS is emerging as the prevailing perspective on architecture for describing 3D behavior logic.
I see a lot of people making the mistake of trying to take MVC into Unity and other ECS like systems. I believe this is due to there being way way more web developers and backend web developers as compared to game developers. Thus there is far far more literature written about ideal perspective on web development, thus if you start reading about software development, mostly everything is talking about MVC-like subjects because its about web development. Many people then mistakenly believe all the MVC related stuff represents a universal perspective on all application architecture, but it really doesn’t, it is web specific. Games are a different problem domain than web.
There are a few books which I think are really good for those getting into game development.
Game Engine Architecture by Jason Gregory.
This is a great book which thoroughly covers ECS architecture in both theory and example. In fact I think the Unity devs based a lot of their architecture decisions directly off this book. The knowledge about ECS conveyed in this book is also directly applicable to UE4, Lumberyard, A* and all other ECS based systems.
Game Programming Patterns by Robert Nystrom.
This distills the Gang of Four type design patterns down into more game specific context. Reading through it is valuable to get a better mentality on game programming.
When you get to implement unit tests to your game logic there is nothing better than to decouple your logic classes from your presentation classes. In that way you can instantiate objects inside unit tests that will run in NUnit without having to rely on Unity dependencies. For example, It’s hard to instantiate a Monobehaviour in unit tests, I don’t even know if it’s possible, it’s better to use a Humble Object approach like the creator of Unity Test Tools recommends than to code all the logic inside a GameObject. I’m having some hard time trying to decouple everything so I can use automatic tests, but once it’s done, I’ll have a great way to test my code in regression.