Turn to self-knowledge: Liang Weiguo
Accurately speaking, code is a kind of resource in the Unity project. This issue should be extended to how to organize Unity Resources. Let's briefly talk about our experience:
-Unity has its own conventions, such as the editor and plugins directories in the project as the editor and plug-in directories. Well-known plug-ins store their own directories, such as ngui.
Therefore, our own code, the directory name generally starts with an underscore, such as "_ scripts" and "_ prefabs.
For scenarios, documents, and other directories, use two underscores so that they can be placed at the top.
-Use C # Instead of Js for code. If necessary, use namespace to enclose your code. We use namespace to wrap our accumulated public libraries.
-C # comments must be carefully written. You can complete the comments by typing //. There is no reason to be lazy.
-Each program file must start with a comment to write and modify the log. A simple description of who has changed the log is provided. Even if you use unity version management or git, those logs will be lost after all. Only by carefully writing the log into the code can you consciously optimize it.
-The script logic of unity is generally divided into two types of functions. One is relatively independent. For example, if the script disappears within one second after the explosion, you can simply write a script and bind it to the target.
It is more about interacting with other scripts in the script. Unity provides sendmessage, which has a slightly poor performance. If the call frequency is not high, you can use it at will. Another method is to call it directly through the instance of the object.
Our practice is to write several public controllers so that they can perform their respective duties and take charge of their respective tasks:
-Write globalmanager. CS to control global variables and global methods of the game. Static class mode. For example, the number of major levels and the number of gold coins of players.
-Write a gamecontroller. CS to control the currently off game processes. Single Instance mode. The main loop of the game is also controlled by it. Initialization, victory, failure determination, and so on.
-Write an inputcontroller. CS to control all user input. Single Instance mode. The mouse, keyboard, and touch screen are guaranteed to support the three inputs at the same time, because most of the time is tested on PC.
The connection between gamecontroller and inputcontroller is a bit confusing. Generally, gamecontroller. instance. Foo () is called in inputcontoller to execute the method. Alternatively, you can directly write the listener mode for the input to allow the gamecontroller to listen.
-Other Similar menu controllers, sound controllers, achievement controllers, and IAP virtual prop controllers are also managed in a similar way.
-Operations on playerpref are written in the get/set mode of the static class in a uniform manner. Where to use playerpref operations in a program, read and write them directly.
-If the number of scenarios in your project is small (<5), you can drag resources into the scenario at will. If the number of scenarios is large (dozens, and each level of some puzzle games is a scenario), the number of prefab to be dragged into the scenario must be small.
-To design your prefab resources, you need to imagine whether other people can run the resources directly by dragging them into an empty scenario. At most, you can set a few simple settings. If the resources you designed cannot do this, you have to think about it again.