20 harmful tips on developing games on Unity
Gamedev is really exciting, especially when there are both experienced programmers and novices in the team. Unlike engines like Unreal and CryEngine, Unity has a low entry threshold, and often .NET veterans and newbies begin to sort things out that end in a fight with office furniture.
In this article, I tried to collect tips that will help you and your team finally agree on how to write the code, and, I hope, laugh well. And so, let's go!
1. Write on UnityScript
One language in the project is boring. Diversify the lives of your colleagues, let them learn to be polyglots. C # is Microsoft, and generally strong typing is not yours.')
2. Do not use var
Unity itself prohibits * to do this, and indeed it is not clear what type of variable. When they tell you about IntelliSense hints - roll your eyes, microsoft brain! Your Notepad ++ does not know how.3. Mix styles
So what? Unity themselves violate the C # Style Guide and fuck it camelCase in the perperty, what are you worse off? If you use MonoDevelop, do not forget to periodically change tabs to spaces and back. At the same time, tell everyone that in MonoDevelop “settings have flown away” - everyone knows about this bug!4. Do not write XML Doc comments
They clog the file, and your code should be clear without additional comments. And in general, your Notepad ++ does not support this all. If you change the signature of someone else's method, do not update the XML Doc - so reading the autodocumentation will be more fun.5. Do not use namespace
Writing using is too dreary, and why bother to do it if you can do without it. All scripts should be in the Script folder - it is easier to find them alphabetically.6. Link the components
The more connections, the better! Each component should refer to each other component - but this is easier! Your character should have a link to the opponent, the door, the game manager, the HP bar on the canvas, to any other objects on the stage. Otherwise how to work with it?7. Creating references, hide them through [SerializeField] private GameObject myGameObject;
So your reference can be edited only through the editor, and in the code they will not interfere. When it turns out that something needs to be changed all the same through the code, just convert private to public.8. Do not use design patterns, except singleton.
When you are told about Dependency Injection or other patterns, roll your eyes. What nafig patterns, here you are not an enterprise!9. GameObject.SendMessage is an incredibly handy tool, use it as often as possible.
If possible, collect the name of the method from several lines - so it will be more fun for your colleagues to look for where the method came from!10. Use UnityEvent wherever possible
Standard event'y - it is for suckers, the more they do not appear in the inspector. Unity knowingly came up with their events.Expose everything through the inspector. Divide your code into parts and expose 5 different methods when you press the button - it will be more fun to look for, by pressing which button this method is called!
11. When subscribing to an event via AddListener, forget to set RemoveListener
There is nothing more fun than debugging and looking for why the code works several times at once. Especially when this does not happen all the time.12. Cache all components on GameObjects.
Even if you do not use them or use them once when you press a button. Optimize should start as soon as possible! Don't forget to transform; those who say that transform is already cached are liars.13. Do not use properties
Properties are slow, like calling a method, and access to the field is much faster. All the advantages of the properties - invented. When someone starts talking to you about private set, backward compatibility and the need to recompile the assembly in case of a field change to a property, look at them as fools - what else compilation, we have a game dev and not an enterprise, we don’t use dll here! And anyway, when was the last time you changed a field to a property?14. Do not use foreach
Well, they have already spoken about this more than once. Unity itself prohibits the use of foreach. Having found a foreach in the code of a colleague, replace it with for and read the 10 minute lecture that foreach creates garbage, show your benchmark where you go around the list every frame for more convincing.15. Do not use Linq
Linq is slow, complicated, and generally it is microsoft. For 10 lines is much more beautiful (we do not use foreach - have you forgotten?). If someone dares to write Query Expressions, then look at him as an idiot - MaeskuEl confused with Unity!16. Do not use strings
A string is an allocation of memory that the GC will collect later. Use char [] - it’s not for nothing that you went through the unhappy university. You don’t need any Unicode - there’s nothing extra bytes to drive, you still have bitmap fonts.17. Do not use Generics
Generics are slow and difficult, and Generic Constraints is even harder. What nafig covariance and contravariance? We have Unity, this is not here! When you need classes with different types, store the class name in a variable and find it with Type.GetType ().18. Do not use Coroutines unnecessarily.
They do not work on inactive objects, and in general, create an additional load. Keep the state in boolean variables, and check them in Update - it is so much more convenient, because everything is collected in one place.19. As soon as the new version of the engine comes out, set it up and commit the ProjectSettings folder.
Let your colleagues learn to keep updated tools. So what if a project is submitted in 2 days, and a new version with bugs? Not your problem, Unity can't release normally! But there is a new system of particles, with which you want to play.20. Do not use text serialization of assets.
It slows down the editor. Binary serialization is much faster. When someone says about merge, roll your eyes - is he a fool to merge a scene? When you need it, just roll back other people's changes. It was necessary to say, on what asset you work, so that others would not touch!About var and foreach
1. In its Bitbucket repositories, Unity really indicates that you cannot use var or foreach in pull-requests. It is interesting that in the same place they write not to use m_ k_ prefixes, etc., although they themselves do it in a huge number of places, in violation of the standard C # Style Guide.
The article was partially inspired by this article on optimization and periodic pearls, which are given by familiar programmers.
In order not to make a holivar, I propose to agree that foreach really creates garbage, which then has to be collected by GC. But firstly, this rule does not always work (sometimes the foreach is deployed by the compiler to the usual for), and secondly, if you don’t bypass the large lists in each frame, in 99% of cases this is not a problem.
The article was partially inspired by this article on optimization and periodic pearls, which are given by familiar programmers.
In order not to make a holivar, I propose to agree that foreach really creates garbage, which then has to be collected by GC. But firstly, this rule does not always work (sometimes the foreach is deployed by the compiler to the usual for), and secondly, if you don’t bypass the large lists in each frame, in 99% of cases this is not a problem.
PS All good weekend, and with the Coming!
Source: https://habr.com/ru/post/318802/
All Articles