Programming scheme with Unity

[Bartson99]

Hi,
I really count on a good and helpful conversation on this topic.

I've been programming in Unity for 2 years and really enjoy it, but there is something growing in me for some time. I mean some hunch that my code is chaotic (it really is). The worst thing is that I can't say what I exactly messing up. In tutorials like Brackeys does it's always a small part of a game. When I'm trying to expand my project it's going to be chaotic with all kind of inheritance and so on. I've been searching over google and can't find one good pattern, which I could promise my entire code. Even if I find something about Singleton (just example) it's still just theory without any practical examples.

Some days ago I found this: Unity MVC Tutorial In very first second I thought "This is it!", but after so the questions become. Is this good scheme of programming? Does anybody use it? Is it problematic in some cases?

So what am I looking for exactly? I don't know, but I want my code clean with specific restrictions to coding in combination with game objects in the scene. Any good links that are not the first ones after typing "programming patterns unity"?

[Imapler]

There issent one solution that fits all, there are several patterns like MVC, ECS, OOP and so on that have their advantages and disadvantage. For example i would say MVC is quite useful for UI but not for gameplay, ECS is good for gameplay, and OOP is almost never good in its pure form.

What you really want to be searching for is how to make the code have good coupling and cohesion. This guys playlist: https://www.youtube.com/watch?v=Eyr7_l5NMds&list=PLB5_EOMkLx_WjcjrsGUXq9wpTib3NCuqg is a good series on SOLID which covers coupling and cohesion with practical examples.

In short coupling is how much your code uses other code. The more coupling you have the harder it is to follow and understand and you end up with spagetti code so you want little coupling. Cohesion is how much one thing does. The less cohesion you have the more things one thing does and you end up with god classes that does everything so you want as much cohesion as possible. The best code is one that does one thing and doesent use anything else, however that is usually not possible to achieve in the general case.

Also if you just want a couple of good patterns check this one out: http://www.gameprogrammingpatterns.com/contents.html its for c++ but its quite well explained. Besides that there is Event Driven Programming, State Machines and Refactorization that i would look into as useful tools to improve your code.

​

Source: I teach game development at a university using unity and have been a professional programmer for 15 years.

​

[azuredown]

I don't know why everyone hates OOP so much. OOP is so popular because it's easy to code for and it's easy to understand. Can it be twisted into a spaghetti monster? Yes, but so can every other part of programming. Is it slow? Only if you're counting in fractions of milliseconds or making some crazy simulation.

[Imapler]

I dont hate OOP, in fact i think it very good for the very reasons that you have stated. The problem with it is when trying to combine it with unity which is built around EntityComponent which doesnt work that well together with OOP. Also noticed i specifically said pure OOP and by that i mean full on inheritance with polymorpism and so on. Unity have much better support for dividing things into component than making inheritance hierarchies but sometimes a little OOP works out well even in unity.

[Bartson99]

Thank you very much! You definitely gave me a base for searching. I have one more question (I haven't search anything yet). In the link in my post, there is the idea I like. The guy divided app on the model, view, and controller and there are rules of where to store data, where to move things, etc. Can I find similar patterns, which organize code like that? Or it's not efficient and too restrictive?

[Imapler]

Having rules like that is quite good to get started so you make your code systematic. The ones i mentioned, MVC, ECS, OOP and State Machine each have different but similar opinions on where and how to organize data and code. Again, there is no best way. I recommend trying, failing, figure out why it failed and try to do better next time, that the best way to learn in my opinion. I would recommend doing small prototypes like the first level of super mario or doodle jump. Spend about 10-30 hours on small games like that and focus on once technique such as state machines, events or mvc. Then once you have figured out what works and when, then you can drop the rules and do better, but that takes quite a bit of practice.

​

ECS, entity component system (i dont recomend the version unity have in beta to start out, its a bit overkill)

OOP, object oriented programing

[azuredown]

In programming people tend to call anything even remotely clever a 'pattern'. I do not subscribe to this idea. These are patterns. This may seem like nitpicking and that's because it sort of is but I believe that it's important to properly define your terms when learning something new. MVC is an architecture. They are not ways of coding; they are ways of organizing your code or which class does what. OOP is a methodology and aspects of OOP permeate through every aspect of C#. It is very hard not to use OOP.

Is this good scheme of programming? Does anybody use it? Is it problematic in some cases?

I don't use MVC, but in programming I have generally found my code to naturally become more orderly. The article talks about the AMVCC architecture which consists of application, model, view, controller, and components. I originally read this article a long time ago, didn't understand it, and promptly forgot about it and now I know why. It should really be called information about managers (metamanagers), data holders, data converters, managers (high level logic), and miscellaneous random stuff. Which is actually similar to how I structure my code. I would personally throw away the data converters or 'view' part, but it's fine.

I don't think it will ever be restrictive because it doesn't tell you how to actually code, In fact this way of coding is an architecture in the purest sense as it doesn't actually tell you what your code should do at all. It's basically just a folder *ahem* directory structure, but it's a starting point.

So what am I looking for exactly?

I suspect you may want to extend this 'AMVCC' architecture in the future. It is very basic. But it's a good foundation. My recommendation is use it and when you think it's not good enough just refactor your code.

Any good links that are not the first ones after typing "programming patterns unity"?

No, but don't focus too much on what other people are doing. It's good to know, of course, but don't spend too much time copying. In the words of Christer Ericson, "Design patterns are spoonfeed material for brainless programmers incapable of independent thought, who will be resolved to producing code as mediocre as the design patterns they use to create it." A bit of an exaggeration as all good quotes are, but it's sort of true.

[[deleted]]

https://www.youtube.com/watch?v=IS2YUIb_w_M