December 30, 2016 at 07:4320 bad tips for developing games on Unity
Gamedev is a truly fascinating activity, especially when the team has both experienced programmers and beginners. Unlike engines like Unreal and CryEngine, Unity has a fairly low entry threshold, and often .NET veterans and beginners begin to figure out relationships that end in a fight using office furniture.
In this article, I tried to collect tips that will help you and your team finally agree on how to write code, and hopefully a good laugh. And so, let's go!
1. Write to UnityScript
One language in a project is boring. Diversify the life of your colleagues, let them learn to be polyglot. C # is Microsoft, and generally strong typing is not yours.2. Do not use var
Unity itself forbids * to do this, and in general it is not clear what type of variable. When they tell you about IntelliSense tips - roll your eyes, Microsoft brain! Your Notepad ++ cannot do this.3. Mix styles
So what? Unity itself violates the C # Style Guide and figs camelCase in property, what are you worse? If you use MonoDevelop, do not forget to periodically change the tabs to spaces and vice versa. At the same time, tell everyone that in MonoDevelop “settings have flown” - 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 all this. If you change the signature of a foreign method, do not update the XML Doc - so reading autodocumentation will be more fun.5. Do not use namespace
Writing using is too dreary, and in general, why do this if you can do without it. All scripts should be in the Script folder - it’s easier to find them alphabetically.6. Link components
The more connections - the better! Each component must reference each other component - but it’s easier! Your character should have a link to the opponent, a door, a game manager, a canvas bar on canvas, to any other objects on the stage. Otherwise, how to work with it?7. When creating references, hide them through [SerializeField] private GameObject myGameObject;
So your reference can only be edited through the editor, and they will not get in the code. When it turns out that you still need to change something through the code, just remake private to public.8. Do not use design patterns other than singleton
When you are told about Dependency Injection or other patterns, roll your eyes. What nafig patterns, here you do not enterprise!9. GameObject.SendMessage - an amazingly convenient 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 events are for suckers, especially since they are not displayed in the inspector. Unity did not come up with their own events for nothing.Expose everything through the inspector. Divide your code into parts and set 5 different methods when you click on the button - it will be more fun to search for which button to call this method!
11. When subscribing to an event through AddListener, forget to register RemoveListener
There is nothing more fun than debiting and looking for why the code works several times at the same time. Especially when this does not happen all the time.12. Cache all components on GameObjects
Even if you do not use them or use once when you click on the button. You need to start optimizing as early as possible! Remember to cache transform; those who say transform is already cached are liars.13. Do not use properties
Properties are slow, like a method call, and access to a field is much faster. All the advantages of the properties are invented. When someone starts talking to you about private set, backward compatibility and the need to recompile assembly if the field changes to a property, look at them like fools - what other 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 the field to a property?14. Do not use foreach
Well, they’ve talked about this more than once. Unity itself forbids the use of foreach. Once you find foreach in your colleague’s code, replace it with for and read the 10-minute lecture on how foreach creates garbage, for convincing show your benchmark where you go through the list every frame.15. Do not use Linq
Linq is slow, complex, and generally Microsoft. For 10 lines is much prettier (we don’t use foreach - forgot?). If someone dares to write Query Expressions, then look at him as an idiot - Mayeskyu El mixed up with Unity!16. Do not use strings
A string is the allocation of memory that the GC will then collect. Use char [] - it’s not for nothing that you passed a link in the university. You do not need any Unicode - there is nothing to drive extra bytes, you still have bitmap fonts.17. Do not use Generics
Generics are slow and hard, 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 using 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 - this is much more convenient, because everything is collected in one place.19. As soon as a new version of the engine comes out, put it and feed the ProjectSettings folder
Let your colleagues learn to keep updated tools. So what, what project to hand over in 2 days, and a new version with bugs? It is not your problem that Unity cannot be released normally! But there is a new particle system that you want to play with.20. Do Not Use Asset Text Serialization
She slows down the editor. Binary serialization is much faster. When someone says about merge, roll your eyes - what is he, a fool, to keep the scene? When you need to be controlled, just roll back other people's changes. It was necessary to say what kind of asset you are working on so that others would not touch!About var and foreach
1. In their Bitbucket, Unity repositories really indicate that you cannot use var or foreach in pull requests. Interestingly, in the same place they write not to use the m_k_ prefixes, etc., although they themselves do it in a huge number of places, in violation of the C # Style Guide standard.
The article was partially inspired by this article on optimization and periodic pearls, which are given by familiar programmers.
In order not to arrange 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 expanded by the compiler into a regular for), and secondly, if you do not bypass 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 arrange 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 expanded by the compiler into a regular for), and secondly, if you do not bypass large lists in each frame, in 99% of cases this is not a problem.
PS Have a nice weekend, and Happy New Year!