Hello Everyone … I would like to ask which Code architecture to follow in Unity ? i read about MVC MVVM and others , ? if anyone has links to follow or to read please post 
thanks a lot
3 Likes
The best idea is to forget about MVC, MVVM and whatever pattern you heard of and treat each in-game object as a separate self-contained system. Basically, imagine that you’re writing a small robot for a robot swarm. No “managers”, every object is separate entity.
That is, unless you’re making an accounting or database application in unity for some reason.
Also, try to get a hang of unity comnponent architecture.Instead of using traditional programming approach (where everything is a class), you need to get used to the idea that everything in the scene is a GameObject (and not a subclass of a GameObject), and almost all functionality is implemented as MonoBehaviors attached to that game object.
Minimize amount of intheritance and reduce number of classes.
For example, if you have a duck and a soldier in your game, then do not make “Duck” and “Soldier” class, instead use one “NPC” class for both, and express differences between duck and soldier via choice of mesh and animation controller.
Something like this.
16 Likes
I’ll second robot swarm. This is the natural way that Unity is defined to work. And it requires the least effort to get a unity to work this way.
Of course there are plenty of other alternatives. Plenty of different structures and ways to use Unity exist. Choose the one that is best suited for your project.
And if you have no reason to choose anything else, go with the swarm.
2 Likes
Try different ways and use the way that works best for you. It is completely reasonable to invest several weeks or even a few months just exploring different patterns and methodologies to find the one that is most productive for you.
My approach is completely the opposite of the replies above. I’ve tried the Unity component-based approach and the normal approach I am used to. Greatly prefer the latter especially after simplifying it even more by throwing out the modern practices of using Interfaces, Events and so forth and instead using a highly procedural programming oriented model. Everything is greatly simplified using managers to control collections of objects. I have only one GameManager GameObject that has a monobehaviour with the standard Unity Start and Update methods on it.
If you want to read more about this, look up component-based design and data-driven design.
Some good presentations are:
- Kinnen, Data-driven and component-based game entities
- Shumaker, Techniques and strategies for data-driven design in game development
I believe BoredMormon has done some good video tutorials on this, too.
4 Likes
Half of this is a code organisation issue, and the other half is a project organisation issue. On larger projects, these can and will conflict. There are no perfect answers, especially when Unity’s serialization and version control are involved. Component oriented MonoBehaviours are the usual go to, but these are intrinsically tied to scenes and prefabs which have no end to the horror stories when it came time to checkout. Then there are ScriptableObjects, which are often overlooked as just data storage devices when they can be as functional as MonoBehaviours if some work is put in.
@superpig The talk was great.
9 Likes
thank u all my app is mixture with “game” and “non game” app and i need it to be maintainable over the time … and i had a locally database written on json file
In my current codebase I have over 200 scripts and… 3 MonoBehaviors. Unity doesn’t force anything on you except that ultimately everything must be mapped to GameObjects.
Interesting subject, I was going to ask about this too.
I come from a procedural programming background so have my roots there, in particular Blitz Max where you simply use simple function calls to do various things rather than having to go through this whole object/model hierarchical structure all the time. It does however imply that everything is kind of exposed everywhere and there aren’t going to be any function name clashes or any ‘scope’ or ‘context’ issues, so it isn’t quite as organized, but it is easier at least for smaller stuff.
Lately I’ve opened up to trying to give objects their own independent scripts more. So I try to make them self-autonomous, at least as far as them having governance over stuff that is ‘local’ to them, and then I might have some other manager thing that takes care of bigger-picture stuff. I really don’t like the idea of having to call a ‘method’ just to set some value on an object though when I could set it directly, if I know what I’m doing so I try not to put too many middle-men between things, but I do understand how providing that interface keeps the external and internal parts communicating properly without letting external script break internal data consistency. I also don’t really like the model of ‘sending messages’ and getting into all this more advanced programming stuff, delegates and reflection and all that, maybe I don’t understand it but it isn’t as intuitive and ‘direct’ for me.
I still like to have arrays of objects where possible simply because it’s fast to iterate through and jump around, and its helpful that this can be stored/serialized. I’ll use arrays over lists or objects anyday. I also like the idea of multiple ‘layers’ of managers that kind of map to different layers of abstraction. I somewhat don’t like having to do everything in a compartmentalized per-object way, ie lots of small scripts all over the place, but I do like how that ties into prefabs and being able to just instantiate something and have it function right away rather than hacking into some kind of shared pool of data.
One thing I will say is that trying to do things more ‘procedurally’ has led me to some complexities that I don’t really prefer, even though I prefer this programming style. Lots of structured/nested if/else statements. It can be okay, but trying in particularly to keep track of user interactions and changes in ‘state’ in this way is not very intuitive to follow. It’s too easy to get lost determining exactly what ‘state’ things are in in a given piece of code based on various things that came before it, and then having to flow back up the nested hierarchy to figure it out.
I recently took a look at Playmaker because I hoped a) it could save time and b) it would make certain things easier. But what I found was that doing really basic things like simple math was so longwinded, it would’ve been far quicker and easier for me (being familiar with scripting). What I DID like however was the state machine. This concept that objects are in certain states - its idle, it’s moving, it’s celebrating, it’s attacking, whatever. And transitioning between those states (which is sort of another state really). This was what appealed about Playmaker but I didn’t like the efficiency. So then I turned back to scripting and decided to try to do things more ‘state-machiney’ in code. And I actually found this helpful.
I may not be implementing this in the most efficient way but basically now I am mapping functions to ‘states’ and then having a ‘switch’ statement (otherwise would be if/else) to go to the appropriate function based on the state. So then there’s a single state-tracking variable (and I mean, just an integer, not some fancy text enum thing although I can see how that might help keep things flexible/easier to follow). And since this gets called each frame/update the flow comes in and basically routes the logic to run the appropriate function. I’ve found this to be helpful because it’s clean and I don’t have all these different layers of nested if/else statements mixed in with a lot of other code, where it becomes quite hard to follow exactly which state the object is in or having to do lots of other logic just to decide which piece of code to enter. Then you’re kind of constantly having to test, well, if the key is down then do this and if the key is an A do that but if not do this, then do this if enough time passed and then do that if it’s too soon, and so on … it can get messy. So I guess I’m sort of separating out the ‘routing’ of major chunks of functionality from the functionality itself, relegating all the main processing to “state functions” or “transition functions” and keeping the main core of the program simple. It’s just a matter of thinking through what all the states are and whether you need extra states in-between to set things up or cleanup or do other transition work.
I always knew that I could program if/else nesting to deal with states before but those states weren’t clearly defined and there were all kinds of exceptions needed to deal with special cases and ambiguities. So now I just have it nicely broken out and am ‘thinking in states’ as I structure things. Program flow is obviously different but it seems to make more sense. One downside maybe is that only one state gets called per update, which is probably ok because objects are in one state at a time, but sometimes you might want it to flow on to multiple transitions and other states all within one frame so that gets to be either spread out over multiple frames or you have to find a workaround. But still, I’m enjoying this approach more and I don’t know why I didn’t do it this way before because it maps better to object behaviors and how they change.
[Edit] I just realized, this is practically like using a ‘jump table’, shock horror![/edit]
3 Likes
Neat! I can’t believe I haven’t seen that yet.
I’m subscribed to the youtube channel and even then I’m surprised I caught it. They’ve got a bad habit of dumping ten or fifteen Unite videos at a time, and since a good chunk of them are of the trend chasing variety, my eyes start to glaze over. I expect there are probably two or three other good talks that I didn’t catch from that conference. It will probably be the next Unite by the time I get caught up.
1 Like
Anyone see any merit to programming in a kind of state-machine style?
2 Likes
Generally everything I do is within state machines. GameState at top level. TitleStates may exist even. GameplayStates may exist. Objects definitely have states. It just makes each state isolated which minimizes the amount of code running during each frame as well as making the program easier to debug, enhance, etc.
And I handle states in a very straightforward way… a simple switch statement is all that is needed. States are just a natural way to break complex things down into simple things. Divide and Conquer.
All of these developers apparently do: http://www.hutonggames.com/showcase.html
I agree with GarBenjamin. Most behaviors that transition between discrete values are a good candidates for state machine architectures. AI states and menu states are obvious examples, but most activity in a game is like this, too.
3 Likes
Even if my application contain both UI (native plugins ) as well as game ? i thought of possibility to use MVVM (http://forum.unity3d.com/threads/mvvm-databinding-and-lobby-toolkit.232526/) for GUI as i need them to have native ux in different platform ? and the Game part of the app is using normal unity’s component based architecture ? Plz help
thank u for reply Even if my application contain both UI (native plugins ) as well as game ? i thought of possibility to use MVVM (http://forum.unity3d.com/threads/mvvm-databinding-and-lobby-toolkit.232526/) for GUI as i need them to have native ux in different platform ? and the Game part of the app is using normal unity’s component based architecture ? Plz help
I already develop it using xamarin an d did not cover my needs so switched to unity … what possible codes or functionality we can use if i switch to Unity ?? can i use the Core portable project which generally contains logic and not ui ?
Sorry, the thread may have gotten a little off track from the intent of your original question. Go ahead and use MVVM for each menu, and maybe a state machine concept to switch between menus. If you’re looking for a framework to speed up your MVVM development, that one looks fine.
What works for me is the event subscriber/listener pattern, and singletons for all my global reference objects.
Yes, some might say you shouldn’t use singletons, but I find them easy and efficient to work with, and being an indie with limited time and money, I need to get code written quickly.
Also check out this website, it goes into some good details about patterns for games…
www.gameprogrammingpatterns.com
Why would you want to minimize inheritance?
I don’t see any benefit in wrapping up a Duck and a Solider class into one NPC class, if both Duck and a Soldier have different methods.
For instance, a Soldier will have a Shoot() method, while a Duck won’t.
1 Like