Do not use MVC in Unity.

hello i thought i should start recording some videos and tutorials and discussions about unity 3d development because i've been doing this a long time and have a lot of experience and have been on lots of different unity projects and it's been pulled into lots of different unity projects to diagnose them and offer advice on their design and architecture and i've come to realize that lots and lots of people out there are all now new and getting into unity and this is a great time where i can pass on some of the uh pay it forward so to say so that the new people coming in can learn and i i notice that there's a there's a number of topics that i see new people are getting into and struggling with and wondering about that uh you know i sorted out like 10 years ago for myself and so um to get into this what this video is going to be about is it's going to be about uh mvc in unity this is a subject that often comes up with newer people in unity for a number of reasons they're looking for a way to do proper architecture in unity or make their unity project more manageable and they hear about mvc and they see some things about mvc and then they start wondering how do you do mvc in unity should mvc done in unity and the simple answer of it i would say is absolutely do not do mvc in unity it is a complete it's it's a completely confused notion to say let's do mvc in unity and i i will explain why um i made some blog posts well first if you if you want to know who i am here is my github page ryg06 i have a link to my linkedin right here you can go look over my resume and stuff i've worked on in the past and uh you know decide for yourself if you want to trust someone with my background in having a knowledge on this worth listening to but yeah that might github here linkedin to linkedin and then on my blog i had done some posts on this years ago uh starting with forget about mvc and unity ecs not mvc and then most recently controller is a bad probably a bad name and i would still think these are pretty good articles to read through and i linked to the other ones also in this article ecs not forget about mvc unity and this this explains uh some of the reasonings of why i say you should not do mvc in unity and they have it spread over three blog posts but really you know i could even do even more blog posts concerning this but it's kind of exhausting and i actually felt like this was a pretty done discussion like five years ago when i made this initial blog post because i had wandered my way i guess into the section of the country and unity developers that had not been conceiving of anything in mvc land i think it's because i started working with more people who had background in actual like game engine development rather than web and mobile developers people who come from a mobile app background or a web development background tend to want to do mvc and unity because like android and ios are still mv architectures and some web app frameworks are also still like mv or mvc architectures and so people who come from webs and 2d ui they come to unity as the 3d their first 3d engine and they want to carry that perspective on whereas people who come more from other game development backgrounds and 3d game development backgrounds and 3d game engines i think tend to not do that because it's a 3d game engines actually run on a different kind of fundamental architecture and i'll get into the explanation of why this is and the other thing uh about this that i noticed now is i decided to type mvc and unity in google again and lo and behold there is a lot of new content of people talking about doing mvc in unity and like the first result is this top towel article um saying unity with mvc how to level up your game development and this this article to me is just uh you know i don't want to criticize it too much because like i can obviously tell the author is a very smart person but i feel like he's doing the thing that so many people have done when they come from mobile app background and they're starting to move into 3d gaming like i've seen it in so many projects and so many that they come into 3d land and they're like well mvc worked in all my 2d ios applications let's just now figure out how to stick mvc on unity and it's it's a logical extrapolation but there's a really fundamental error in it and the error in it is that it's very different problem domains and to get into so model view controller if you're watching this hopefully you know like model view and controller mvc and the model is the object which interfaces with a database or some kind of back end apa doing crud operations and performing other business logic on that data and then a view represents an actual like 2d view in your 2d user interface like a button or a panel or something it describes only the visual representation of it and then the controller binds the model to the view so that the controller figures out what to forward to the view and what to operate on the view and all that and it's it's largely done for decoupling and a separation of concerns and i i want to first highlight that i don't think mvc itself is bad mvc is actually a pretty decent conception of architecture evidenced by the fact it's lived on for like uh you know started in 79 the 70 yeah it's like over 30 years or no 40 years that's i'm getting a lot older these days but yeah it's lived on for a long time and like apple and android are still have derivatives of mvc so it's it's a very good architectural design it is very good the thing about it though is that this was conceived of for the architecture of 2d graphical user interfaces it actually spawned out of um xerox park in the early days in like their early gooey stuff and his first implementation on small talk 79 that's interesting uh but yeah commonly used for developing user interfaces and this is really where it came from is that it was an architectural pattern for 2d user interfaces that's literally what it was conceived of for i found this nice layout of some ios panels and when they came up with mvc what they were doing was they were looking at this um well not literally this because of course they didn't have android back then they're looking at some really old very crude ui on like the first xerox computers but they're looking at you know ui panels and they're saying like what are the fundamental behaviors present in this and they identified well we have a view which is a window or not a window a view is a panel some sort of collection of 2d interface elements and only their presentation and so they labeled the the visual representation of a ui they labeled that a view and then they were like well we need to operate on a database what what what is and we need to do logic so what are we going to have we're going to have a model and there is literally another object that that serves this literal purpose in the concept of 2d user interface and then they're like well we need something to drive the interfaces you know talk to the models and drive the interfaces and what do we call what we call it a controller and this is the thing to understand about mvc is that these concepts of model view and controller were conceived of by decomposing the behavior of 2d user interfaces they were derived from the things that needed to literally exist in the context of a 2d user interface that there was actually a literal view and it was literally a panel that just described the view of the panel and that actually existed in the context of objects it was a required behavior in that environment and so that's where view came from and then they needed the behavior of interfacing with a back end and doing logic on the data returned and so that's where the concept of the model came from and then something to read and control the two and that's where they needed the behavior of the controller you know we have three categories of behavior here which are very well tuned to this specific use case of 2d user interfaces but now let's go over to a different problem domain here we are in unity the first thing i'd hope you notice is that this is not well the unity editor is a 2d user interface but your game world is not a 2d user interface your game world is something very different than a 2d user interface and here you have a cameras to move around you have shapes you have lights it is much more complex than a 2d user interface not this at the moment but you know if you made a whole full game with players running around and things that could explode and items to pick up and a whole game it's like it's there's much more here than just elements of a 2d user interface and this is where the abstractions in here come from where here you have a light and so you literally have the concept the abstraction of a light here you have a camera so you literally have the concept the abstraction of a camera here you have meshes which this is actually these are decomposed into a few different behaviors for differing reasons but you have a mesh filter and a mesh render and a capsule collider and you have a collider concept because you literally have a collider you have a mesh renderer because you literally have something rendering a mesh and this is the thing to understand is these abstractions and the problem domain of a particular system the abstractions come from describing the literal decomposed elements of necessary fundamental behaviors and this is what mvc is but for the context of 2d user interfaces it's the literal behaviors necessary to construct 2d user interface mvc are not universal abstractions they're abstractions describing behavior of a very particular use case and so this is the weird thing about people now saying let's do mvc in unity is that they're taking a much simpler problem domain a much simpler environment of behaviors which which with just a few simple like three very simple abstractions of types of behavior and then they're coming to a much more complex problem domain which is fundamentally different than a 2d user interface and they're saying let's take all these more complex abstractions describing the literal fundamental behaviors of a 3d interactive environment let's take all those more complex abstractions and try to fit them into the abstractions conceived of from a completely unrelated problem domain that is far far simpler and it literally just makes no sense and i think the only reason people are doing this is because they just don't know this is what you're supposed to do as a system architect and they don't know this is what mvc came from that they're spent probably most of their time in a mobile app background or a web app background using all mvc and everything was mvc and so then they leave that and they're like mvc is this great architectural pattern let's do everything in mvc and they don't you know maybe they knew maybe they forgot maybe they never knew but mvc wasn't a universal set of abstractions for every problem in existence they were abstractions which literally described the actual existing behaviors which underlay specifically 2d user interface and so they continue on and try to try to contort the thing and it's um a really bad idea and you know i that this article is really it's a well-written article but it's just not a good article and he the author does note that unity is an entity component pattern this is the fundamental architecture that unity runs on and a lot of game engines run on is an entity component architecture unreal runs on it uh half-life engine ran on it did it start a quick i don't remember where exactly it started but most this is one of the very predominant patterns in uh 3d game development a good doe also runs on this type of pattern and it should be noted that the entity component pattern is different than the entity component system in unity related in some conception but these are kind of different things and he goes on to say where entity component falls short and that he says in large objects we are still too free and we can find ourselves in a feature ocean having a hard time finding the right entities and components or figuring out how they should interact there are an infinite ways to assemble entities and components for a given task this is actually the whole point of an entity component architecture but to continue on he then says i see that there's three categories and these map to mvc um some handle the raw data allowing it to be created read updated deleted search others implement the interface for other elements to interact with detecting events related to their scope and triggering finally some elements are responsible for receiving these making business logic decisions deciding how the data should be manipulated uh are those really the three categories of behavior in a game engine sorry i wasn't showing the page this is this is the page uh yes are these really the three categories of behavior and he says that these come to distill down to model view and controller um let's go back over and really there's three categories here actually let's go look at uh the the unity documentation let's look at this let's look at all these two free components describing way too many concepts uh android input can't scroll version yeah so let's get audio clip audio configuration audio distortion filter audio source avatar avatar builder behavior bitstream box collider cache canvas canvas group collider contact point debug frame like yeah this is this is i guess you could say uh uh how did he describe it um a feature ocean it's two free look at all these all these different behaviors that have been identified for the problem domain of 3d interactive environments this is a lot of complexity how do we manage this complexity well we fit it all into three concepts three concepts derived from 2d user interfaces uh no it just makes no sense it makes no sense whatsoever if you go through here and you started to rename all these things to colo collider controller collision model color model component controller contact point model crash you know if you start to go through and categorize these things into these three categories this isn't going to make it more manageable it's not it's going to make it worse because for one there's way more categories of fundamental behavior to derive from in a 3d interactive environment and then two the categories of behavior that you're now trying to fit into a new set of abstractions to make it more manageable are a set of abstractions that were conceived of as literal descriptions of a completely different problem domain so this is why i say no let's not do mvc in unity let's not take the abstractions from a completely different problem domain and then try to fit a completely different problem domain that is innately more complex and natalie requires more categories of behavior and fit them into this other simpler set of abstractions from a completely unrelated problem domain it kind of just blows my mind that like this type of article makes it to the top of google and there's so much written about this and i really can only think of it it's because there's just so many new people coming in from mobile mobile app and web backgrounds that don't know the things i just explained don't know where mvc came from don't know why it was conceived of as a good architecture in its problem domain and don't know why uh and don't really understand what entity component architecture is i think it's primarily just because the people are so familiar and so spent so much time with mvc and spent so little time with entity component architectures and it's funny to me that if you type mvc and unreal engine the first result that comes up is a reddit thread asking about model view separation and unreal engine and the first response with the most upvotes is i've never seen anyone use mvc or mvv bvm or anything like that in a game if i'm to be honest with you even if the separation of graphics and logic is possible i really don't think it's worth the hassle to work against the grain of the engine exactly it's it's funny mvc and unity returns this like article from a very you know somewhat known uh website that's just like whoa and then the first result in unreal engine returns just simply no what the hell are you thinking and i think that probably has a lot to do with the people coming from mobile and web background they aren't initially going to unreal they're initially going to unity and so uh the the higher concentration of people that come from game engine development and game engine architecture backgrounds have uh taught these things a little better as the users trickled into the unreal community but unity just got over flooded with people who had really no idea about this stuff and so with all that said though i would like to how long is this video i don't have a timer let's just go as fast as possible i would like to though highlight how you approach entity component architecture because i think this is what people struggle with getting is they don't get the entity component architecture and how you can design systems in it that are manageable and they haven't seen enough of it so they don't really realize what it looks like when you're doing it appropriately but we come back to just the basic principle of object-oriented design and that what you do and the same way this was done with mvc and 2d user interface is you put your problem domain in front of you you know whatever the visual problem domain is and this is one nuance of this is object orientation i don't think is itself universally applicable and if you start to get into problem domains which don't have like literal representations of objects that's when starting to approach things more in a functional programming style makes sense but if you're in a problem domain where there are literally objects in an environment that's when object orientation makes a lot of sense and that's where you start from this approach of object-oriented design and it starts with looking at what are the literal objects actually existing in your environment and for a user interface it was a 2d view and in here you know ios also has the abstraction of a window because there's a window obviously and i think android also had that abstraction but they they look at what are these actual things and they derive back from backwards from there so we have a view we have a window and then we needed something for database something gloom controller and that's where the taxonomy and the abstractions come from starting with what is literally there is the objects and so we then go to unity and this is the same thing being done here you start with what is literally there and you name it literally that and then you work backwards from there and if you need some stuff that's a little more you know sometimes you do end up with objects that don't have literal counterpart or like literal representations in the environment that you can see and you do end up with these objects that run on more abstract concepts so one of the examples of this is the canvas system in unity which is the canvas system is a 2d user interface but it's a 2d user interface implemented through entity component architecture so it's actually different even though it is still a 2d user interface interestingly i'd like to highlight this that unity does have a new user interface library in development and it isn't actually been pre released for production for use in the editor and that new 2d user interface called ui elements does in it have actual views it has literal views and the you know the same meaning as mvc and so you actually could be doing mvc and unity with this new ui system but it would be a 2d ui in your 3d environment and the conception and abstractions of mvc would be constrained to that 2d ui but back to this canvas system which is canvas is 2d ui done and entity component pattern so one thing about this is yeah this is decomposed into by behaviors and this is one of the the nuances about this to understand is some people i think tend to believe that mv's might see what i'm saying is kind of a semantics argument of like oh yeah but you still have controllers and views you're just naming them differently and this actually is not true this isn't true there is a very it informs a different kind of architecture when you start approaching things as entities and components that mvc does not inherently inform and what i mean by this is if we go to [Music] android and their user interface uh here's the android documentation where they have a views and views kind of go in a hierarchy of like you know you have button a button view on a panel view on another view and this actually gets laid out in an xml format now that you lay out in a the editor views also can traditionally be just a class that describes placement and coordinates of the layout of elements but more and more you have these editors that lay them out in xml but when we come into unity what in here is most literally a view you know over here in android lan it's the hierarchy of views ui elements stacked on each other related to each other and stored over in an xml and if we come back to unity what is that over here the the literal closest thing it's your scene in your scene graph and then the arranging of the components on them which describes the description of it and this is uh one of the weird things if you're trying to do the mvc in unity and why it's not really just a semantics argument is that for one there literally is no equivalent of a view in the context of a 3d interactive environment that needs to be created as a component like you're trying to turn a component into a view but what the view literally is closest to being is your scene and your scene graph and you don't need to rename that to something else you can just call it scene or call it your scene graph and this is what i mean by uh you know these are not universal concepts you shouldn't be taking the abstractions from this problem domain and sticking them to other problem domains you should learn your specific problem domain and describe just or derive your abstractions from that specific problem domain so the view or the scene graph in your scene is what describes the arrangement placement and description of all of your visual things you can actually see and then we come over here to uh the components and this is where how unity implements the entity component pattern is you have game objects which are your entities and then you stack components on them and the way components are supposed to work is they're supposed to describe composable behavior that's that's the purpose of them describing composable behavior and this is where it gets kind of weird when you come into the concept of controllers and views in relation to this because you could say that this is a view but it's also implementing logic because this has a number of operations in it that just describe its behavior how navigation gets to it how these things fade and display and it it inherently it doesn't have a split of conce or separation of concerns separating what can be neatly conceived of as a view and a controller if you were to do that in here what the view would be is the view would be the serialized data of the button component and the logic or the controller would be the c sharp code of the component but it's you see you're taking something just a completely tangential perspective and trying to contort it to fit here the way you're supposed to view this is here's your entity and here are your components which compose to describe its behavior and so what you first do is you look out into the scene and you say what is actually existing here well we have a button we have a literal button so what are we going to do we're going to make an abstraction called button and the same way that when they're looking at 2d user interfaces and they're like what do we literally have here a view we're going to make the abstraction of view here you have the literal abstraction of button and so you end up with a component of button here you have a literal image and so you end up with the abstraction of image here you have literally an object with text so you end up with the abstraction of text and you start from there you start with what your literal objects are and go backwards and you do get to points where not all of your objects will have literal representations in the world and this is when you start need to come up with more abstract concepts to relate them one of these more abstract concepts is the canvas renderer or a renderer obviously this doesn't have a literal existence in the world but it's still serving a behavior in the ecosystem of all of your other objects and components and then canvas canvas scalar canvas group and this is this is one of the the nuance thing about is if you kind of really go through and think of what each of these things are doing some of these could be said to be more like controller concepts or they could be more like view concepts or some deal more with presentations some deal more with logic and because like canvas scalar is really just dealing with the scaling of canvases so maybe that's a presentation component uh the buttons dealing with just like the logic of a button so maybe that's a controller and you know you can go through and kind of do this but really all these components are a mix of both they're all a mix of both because it's not trying to be because it's starting with what i just described it's starting with looking at what's literally there and working backwards from what's literally there to describe the abstractions and people come in here and i've heard so many people say like we need to separate the logic from the presentation do we in some contexts i would agree with this but you know follow me through here on as i explain this is that really what you're looking for in a more fundamental sense is the separation of behaviors if you have a behavior that needs to deal with presentation you end up with that as a separate concept if you have a behavior which deals with some kind of logic not explicitly bound to that presentation you end up with that as a separate object but you don't separate concerns based on abstract concepts like presentation and logic you separate your concerns based on the elements of behavior that literally exist in your environment and so here is how you know i think the canvas system is actually a pretty good example of how you do an entity component design it's interesting also to see it because it's a 2d ui framework so you can relate it to how architecture ends up in mvc versus this but the way you end up with these things separated here is not with presentation components and logic components but with components which represent what actually exists and through that is where you can start to from that is where you can start to split things off into different categories of behavior as as you need them as you only as you really need them because this is another thing about uh entity component architecture and envies and kind of a difference from mvc is you you don't you have to actually kind of work through the problem domain and the architecture of it to really get a sense of what the different behaviors are that you need sometimes you can sit there beforehand and just say like these are all the different behaviors i need and you can come up with them right off the get-go sometimes you need to though implement something the behavior of something and you realize that actually this component can be decomposed into multiple behaviors and you decompose it in different ways as are necessary for what you're specifically working on and so in this context you know you have a button and you have these uh colors normal color highlighted color which describes how how these get affected and one thing that i wish actually the canvas system did is that this functionality of color was further decomposed into another behavior you could just call this like a color color schema or color palette is what i've called it in the past as a as a palette and you just store you'd have one object which is a scriptable object which stores nothing but a color palette and then you would be able to load this into here and then you could have multiple buttons sharing the same color palette unity already has this kind of implemented with presets where you can save a preset but it's it's kind of a a little bit of a different system i think because the presets don't automatically update all the things they're connected to but that's one fundamentally different take on how you approach this is you don't just make one blanket statement on what your separation of concerns would be for literally everything you know like again just just proves down like the unity documentation and imagine all these things having corresponding controllers and corresponding views it literally would make no sense to do this because a blanket statement of what your separation of concerns should be doesn't make sense you have to figure that out as you go and as you need to separate things out into different composable behaviors like audio for example they uh have audio clip playable audio mixer audio mixer group audio mixer playable audio mixer snapshot audio playable binding audio playable output uh that's yeah can you think of how to fit those uh abstractions into the concepts of controller and view well no it would make no sense because these are abstractions derived from an audio clip playing in a 3d environment alongside other audio clips and controller and view are abstractions derived from a 2d user interface doesn't make any sense and so this is what how i generally approach doing these things is you start with what literally exists in your environment and then you break it out into more break it out into components as is necessary to further decompose the behavior to enable the behavior to become composable on other objects and you don't actually want to decompose it into multiple components unless that actually introduces a new behavior that can be composed in different ways one way to think about this is that your your game object here and then your components on it you can almost think of it as like a visual scripting system but instead of chaining together nodes you're dropping logic blocks and a stack to describe the behavior and if in a visual scripting system you had two visual nodes and those two nodes could only connect to each other and those two nodes always had to be connected to each other and there is no other configuration by which those two nodes could disconnect and configure to other things like if you had two nodes and they explicitly could only be connected to each other and had to be connected to each other those are not two separate behaviors from the perspective of a visual scripting system those are one behavior and they should be one node because it would just be pretty silly to have two nodes that you always had to drag both of them out and connect them every time you wanted to use them and there would nev and they would never be used in any other way but that and that's kind of the same mentality that i think you should take when designing components where if you have a component it's actually okay to do it as one mono behavior that encapsulates a whole bunch of things but you only keep it as that until you start to discover the behavior that should actually be broken out so that it can be composable to produce different kinds of behavior and one example of how i did this is i have these uh item objects in in my game which items are things you can drag out in the world and place around and i started this first with just an item script or an item component and this described all the data of the item and how you could drag the item around and what you could place the item on and what you could do with the item and it was and i was going along with just item for a while until i realized that okay the dragging behavior of the item doesn't always need to be there sometimes i want it to not drag and then you can also drop the item on other things so i have an item drop component and then also at times you needed a gizmo and so i have a item gizmo component and as i went on i discovered these new categories of behavior and because there are new categories of behavior that didn't necessarily need to always be included in the behavior of the first component i was working on i broke them out into new components and so now you can compose the behavior of an item by composing different components and this is this is the point of doing it in this manner is so that you end up with many different composable components and to the point of this original article that says it's uh i don't know where that article that it you turn into a feature ocean and it gets hard to manage uh this is this is an appropriate statement it does and it this is what the whole point though of like good architecture is is that you need to take a lot of care to describe your abstractions and identify the categories of behavior and name those categories of behavior appropriately and keep the the naming consistent the the um the categories of behavior that components perform consistent and this is already done in unity to some degree there you know you have the abstraction of a renderer and they reuse this multiple places because and you can reasonably assume that wherever there's a render it's rendering something in some manner and the same thing with the abstraction of a collider they have box glider cylinder collider all these different colliders and you can be reasonably assured that if they're something is named collider it's it plays the behavior of colliding with something and so that's how you do end up having to deal with a more complex set of abstractions and something more difficult but that's because it literally is more complex and it literally does need more abstractions than what were needed for 2d user interfaces and one point i'd like to know is that when you go along and do this you do this item component or item entity i have i did manage to turn into some generic composable behaviors and that's good for this but there are times when you you end up not actually decomposing the behaviors into different uh components that much and one of the time places that this tends to not occur in practice for me is with the component that i put at the root of a menu and this component is actually pretty similar in its behavior to a literal mvc controller because this holds a bunch of references to a whole bunch of things that are presentation oriented and then it implements logic and it does and it receives and interops with databases and so this is probably like the most controllery type thing that exists in my games is the the ui component that i'd put at the root of a ui next to a canvas and this is the what i mean of it's like i'm not explicitly saying mvc is bad i'm saying that its abstractions are the product of decomposing a specific problem domain and if in your new problem domain you know going through the same process of how you decompose objects into you know decent object oriented design if you end up with a similar concept then that's great in this case i did this is kind of like a controller but an interesting thing to highlight here too is in this back on the item is this is composed of multiple components to construct its compound behavior and in a way all these components combined are like the controller and if i was following more strict mvc here i imagine i would probably end up with an item controller which had all these different components put into it and that is where thinking in an mvc context can actually be very counter-intuitive to the entity component architecture because it's better to have decomposed components to recompose into new kinds of behavior so that you end up with a library of components that you can combine in every which way to make new behaviors without having to code new things like this is this is better and you don't you actually don't want to do this unless you truly truly don't need to come decompose it further you don't want one component which has a bunch of references and does a bunch of logic it if at some point i discover that actually there is a certain behavior in this component that other ui needs to share i will pull it out of this component turn it into a new component and then start multiple ui will start to share that component but that is what you always want to aim for decomposed components that can be recomposed in new ways and you do end up with a lot of components but that's where becoming an architect and managing this stuff comes into play and i have a blog post here that if you want to get some idea of this it's called controller is probably a bad name on this blog here but i i brainstormed and wrote up just some some types of behavior that i end up using in projects sequence catalog factory route container render api ui menu database datum ite item piece part pool group wrapper like these are all fairly decent abstractions of behavior that you end up with if you derive it off of your actual 3d environment and this is by no means like an authoritative list there's even more that you could come up with but just to start to get an idea of the types of things that you can further decompose into you can read through this list and i usually recommend that as teams develop code bases and libraries they they keep a rolling uh log like this internally where someone will propose a category of behavior and they'll name it and then they'll describe what that behavior is so that anyone making a new component that has a similar behavior can name it the same thing and this is how i think you end up with a good architecture in an entity component uh engine that is based on that architecture is just putting a good amount of thought and a good description into what your categories of behavior are another thing i'd like to note is that in the context of unity and game engines one of the concepts of mvc that does transfer over pretty decently is the model because you do end up with objects in unity that just do crud operations to a database or do just implement logic in some way and the thing about this though is i usually prefer not to call these things model because in the taxonomy of a 3d game engine the abstraction of model is already taken by 3d model and the name model wasn't even i think the best of names either you know it comes from decades ago and what i find is that when i start to create a model object in unity what it is doing is it is implementing an api or it's interrupting with a database or it's being a kind of service object or it's just holding data to pass around and what i prefer to do is literally name it what it specifically is so if it's an api that's just doing crud operations name it api if it's interrupting with a database name it database my game database my game api if it's uh providing some kind of service um you know that's a little more of a generic name but whatever any component which is to be universally accessed either in a scene that never unloads or has been marked do not destroy database api and wrapper could all be better names if they provide if they better describe your component but sometimes you may end up with service components yeah so in a way service is kind of like a more generic descriptor of um something that could be a model same thing with manager same thing with system uh these could all be kind of interchangeable things because they're a little more abstract so if you use these terms you'd probably want to put some more specific description to them or go off my specific description i described these as a system as the entry point into a more complex system um and a manager whole needs to hold many references to other things these are my concepts though that i'm inventing and each each code base will probably end up with a little bit different conceptions of these behaviors but as long as the behavior is uh you know decently consistent across the the components which use those namings and you're not going completely counter to the types of abstractions that are already in the unity api then i find code bases that go in that route are do end up well they end up good and relatively easy to manage and they scale well and new people are easy to onboard into it because if everything's named well and the categories of behavior are described well then it becomes uh decently self-documenting and so that yeah that's the way i think you should really approach architecture and unity is work backwards from what's literally there in your environment and come up with abstractions of behavior that are as literally descriptive as possible and don't necessarily decompose things into different components of behavior unless you really need to i would add one note though that even if you do have one component even if you do have one component that has a lot of logic and code in it and it doesn't make sense yet or maybe ever to decompose this component into multiple components you shouldn't necessarily just write a massive component with thousands and thousands of lines of code instead what you should do is internally decompose some of that logic into just plain c-sharp objects not unity components but just c-sharp objects which can be instant or created instantiated inside of the class itself and held as private references inside the class so some of that logic can get pulled out of the main class and put into sub classes to help make the main class smaller and categorize parts of it internally better and that's also something to consider as well for sharing behavior or logic between components is that it may be possible that shared logic doesn't always need to be an additional component that shared logic could just be a c-sharp object that multiple components internally instantiate and keep a private hidden reference to there's times when you do that because the the real reason for making a new component is exposing something to be controllable in the inspector that if your new component introduces behavior that has fields on it that need to be set or references that need to be set up or something like that that's that's usually when you want to make a new component and actually do that otherwise you probably don't want to uh like pollute your component library with concepts and abstractions that aren't really necessary to be understood again thinking of components as kind of like a visual scripting stack is relevant you wouldn't want to put in a method or operation into a language which your user will never need to use or offers no real additional functionality or configurability on top of what it would just do by default so some things to think about and hopefully this can help people in understanding how to better approach entity component architectures and why mvc is a bad concept in the context of 3d interactive games or specifically unity

Channel: Ryan Goodrich

Views: 816

Keywords: Unity, Unity3d

Id: er2KzMdUies

Length: 62min 21sec (3741 seconds)

Published: Fri Sep 03 2021

Reddit Comments

[u/tiktiktock]

"When the only tool you have is a hammer, everything looks like a nail." It's baffling to me that so many people are trying to shove an alien architectural pattern into an engine already built around a perfectly serviceable one.

[u/Nesto23]

I was working on a project with the successful use of an MVC-like pattern for UI in Unity. But it was used only for UI components, it wasn't the backbone of the entire game artitecture like you are describing.