Avoid Unity's Pit

1. Create an abstract prefab to do level editing

As far as possible to make the abstract prefab to do level editing, the prefab should be enough abstract simple (only a gameobject, and then through the gizmo to draw is a good way), or later change (common is to change the art resources), all levels are lost prefab , it is a disaster for planning. Consider using the data Sheet + editor to provide planning operations and no longer need to worry about lost prefab issues. Prefab the simpler the abstraction, the more difficult it is to lose, and the correct way to nest between prefab is by linking instead of hanging underneath the node.

2. Avoid modifying the scene as much as possible, with several methods:

• Organize your scene with data such as XML

• As much as possible to make the scene composed of prefab, so the change is on the prefab

• Using tools to do scene merge

3. Do not rely too much on component features to develop, consider data-driven.

4. Logic easily scattered throughout the editor, can do a central management.

Take advantage of Unity's features

• Organize your hierarchy, whether you are editing or running, you can use tools to streamline your organization's work at the time of editing.

• Allow each scene to run by itself.

• With component-based architectures, you can use inheritance (in C #) as little as possible, and do it more by combining. When we encounter a common interface that requires data access, we can do it in a combination, rather than providing a common base class interface to inherit, as long as everyone knows the common component and can fetch the data. In the case of generic event dispatch, we can distribute the event to the object with a string concatenation to the specified object or to a more parametric combination.

• The framework uses the Star schema + event mechanism, because Unity3d does not have a so-called entry function, which is not conducive to code tracking, such an infrastructure can bring a lot of convenience.

• The Unity interface is very extensible, and with the ability of the CLR (Commom Language Runtime) to reflect, it is easy to develop the interface in C #.

• Do a good job of tag, layer planning, to consider what kind of objects in the business need to interact.

• Get a prefab or gameobject in the code, you can consider using the interface to drag the target, so more intuitive, but also can resist changes, such as the target name is not afraid, but also can save the code amount.

Code

Here for C #, static strongly typed object-oriented itself is a pit, inherited with two responsibilities, one is to reuse code, one is interface inheritance. While performance is less than LUA, because performance bottlenecks are not in the business itself, design problems are much more serious. I think that meta-programming of dynamic languages like Lua is able to implement a single point of truth and derive the truth from each of the systems through meta-programming. Let the code always remain semantic, and I think the most important thing to write business code is to maintain semantics. The simple and effective way to judge the semantics is to look at a function in the class, see if it can read it, and whether multiple interfaces can form a complete solution. Static strongly typed object-oriented languages are better suited to rigorous system development rather than game development, where demand is stable. Easy to go through a lot of planning needs to scour, semantic is easy to distort, a variety of abstract leaks, various hack. Well, it's off the topic.

• Unity3d is easy to crack, because the release version of IL is very easy to decompile, to be confused with consideration. Confusion in Unity3d to consider the effect on the editor.

• Complex types use reference types as much as possible, and value types reflect trouble, are not convenient for serialization, and are made into editors. Value type be careful whether the assignment object is just a temporary object.

• After the reference type is disposed, the pointer referencing it is set to null and can be used with confidence.

• For foreach, LINQ, and Cheng, reflection is used only in the editor.

• Consider encapsulating time to make it easier to pause.

• Consider using a scheduler to complete functionality, rather than maintaining state in the update itself, so it is easy to pause, the code clearer, and the functionality more cohesive.

• Incremental updates want to be clear from the start.

Art

• Unity3d can use the extended editor to work with non-technical editing interfaces, organize fine art resource specifications, paths, and automatically generate prefab. The game scene object also must plan the logical node, this also should through the editor expands well. Complex functions should also be developed through the editor to fine-tune the design, especially to visualize more important modules, such as motion adjustments.

• Make prototype art, let development improve development efficiency.

• There are unified conventions, such as the model is always the center alignment, the role is always the foot alignment, unified scaling, unified animation skeleton naming, resources have a unified path.

• Support Dressup (avatar) to start thinking clearly.

• Resource loading and optimization give the embryonic form as early as possible (just a prototype to help you grasp the need, because you don't know where the hot spot is at this time), because once the asynchronous and resource releases are not planned, congestion and memory spikes are expected. Because of the embryonic form, the code is a bit more indirect and provides room for change.

Avoid Unity's Pit