Hi, I’m pretty much beginer in Unity and so far I made my games just as a monilith monobehavior trash and one with LeoECS to try it out.
I read a bit about MVC/MVVM/ECS and I don’t really know which of them to stick to.
I’m currently learning Entitas but I’m not really sure if I’m going in right direction as ECS is not really mentioned in many vacancies. Though they don’t mention any other patterns.
Can you tell how do you architect your projects, which paradigm/pattern/framework you use? What architecture should I learn first?
As you’ve seen so far, Unity works on a scheme of attaching multiple components to objects. The best architecture will have clear and clean separation of concerns between each MonoBehaviour class, so that they can be mixed and combined in many different ways on various objects.
MVC really doesn’t work in Unity; the behaviors need to keep the data and manipulate the data that they are responsible for, and making parallel data models, controllers and viewing code is cumbersome. Each MonoBehaviour tends to be responsible for all three, to a degree.
Make “managers” for top-level systems in your game. The main game structure itself, the levels or worlds or regions, the player character’s many data features, the ways the user interacts with a character, the overlay systems on the screen, the UI elements on the screen, the networking layer if needed, the AIs which guide non-player characters, the save-game data management, and so on. Each are separate systems and should focus independently on their own concerns as much as possible.
If you are trying to model tens of thousands of fungible items, look into the newer data oriented capabilities Unity has, but otherwise, it’s best to stay on the traditional coding side for your first couple projects. The Data Oriented stack is still experimental and not as many tutorials will guide you there.
Me neither.
And if I was doing a 1-day game challenge my answer is going to be different than if I’m starting my team of 20 guys up on a three-year-long AAA multi-console port game for a publisher.
Try some stuff, gain experience in it. Try some other stuff, see which works best for you. Everybody thinks differently.
Remember, learning is the modification of behavior through experience, not so much reading about other peoples experiences.
3 Likes
Imo ECS is objectivly better for games than OO.
In my job project we use Entitas and after 6 months with it, I can say that it has its pros, but for my pet project I’m using LeoECS. The result code is simpler and much more compact compared to Entitas.
I wouldn’t abondon ECS even if it’s hard to find job with it. It’s better to have more tools in your arsenal.
MVC-like patterns aren’t really applicable to Unity, at least for game-logic related stuff. But principles which they promote may be useful and I think it’s still good to know them.
In our job project and in my project as well we are using MVC for UI code (UI is a thing where MVC-like patterns do work).
Interesting that we use Entitas as Model, so OO with MVC and ECS can work together.
I would learn ECS first. You won’t build your whole game around any MVC pattern anyway, because pure MVC isn’t good for games, but you can do that with ECS, it was created for games and will be broaded your horizons as developer.
Regarding other architectural stuff, I would look into learning Zenject and “DI” as concept, what’s “EntryPoint”. You can get comfortable with it in a week probably, but again, it will be another tool in your pockets, which also used quite often by many teams, and you will think differently as a developer after spending enough time with it.
By the way, LeoEcs has built-in injection, and you can inject anything into systems, so you can start with it, and then move to more complex injection framework later.
Agreed, but if you take this route in the Unity context you have cut yourself off from 99.9% of the tutorial and example material out there. You will be on your own mostly, as almost all of it is traditional OO with MonoBehaviours. That’s just reality in 2021, and probably at least for a few more years.
Keep in mind if you’re targeting mobile in any form, processing “too many GameObjects” is rarely your bottleneck. Mobile limitations are almost always to do with pixel fill, and ECS gives you no help there. Zero.
I’m not honestly sure pure MVC is good for anything but the classroom, but hopefully that won’t start a massive flamewar.
I still stick with “try lots of different stuff, pay attention to how easy or hard it is to use to solve your data transformation problems.”
If you aren’t using DOTS, but some vanila Unity friendly ECS library, then all tutorials are completely there for you. All you need is to convert fields into components, which is quite easy. When you watch tutorials you still refactor and shape the code to fit your architecture, so there isn’t big difference, if you aren’t completely new to Unity.
That’s true, but performance isn’t main ECS advantage. ECS is all about architecture: simplicty, scalability and easy data access. So even if you don’t gain extra performance, you get all these great ECS benefits.