Sometimes you have the time to create custom applications for your customers. Sometimes you don’t. One of the prototypes I worked on recently required conversion into a toolkit of prefabs so that the prototype could be replicated on a number of different models. When I originally created the app, it was built specifically in Unity for the given model. I then converted it entirely to a more flexible set of scripts and prefabs. Since I didn’t have any forethought when I created the original project in regards to customization, I created unnecessary work for myself. Don’t be like me! Here are some tips on how to create projects in Unity with flexibility in mind.
–Draw Pictures.
General Programming advice. However, it’s a personal favorite of mine that was made known when working with Ron Burgess, the HoloLens developer I’ve been working under. Before you start writing code, draw a picture of each of the different objects or parts you’re working with. Physically write out what your code is expected to do, and how it connects between them. Try and simplify your drawing as much as possible. Doing this gives you an idea of the complexity of your code before you even start writing in your IDE.
–Write scripts that only do one thing.
Don’t fall into the habit of loading up a class with multiple bits of functionality. If you ever have to go back and change say a mechanic, having both the movement, scoring, and manager functions all in one script working in tandem can cause problems. If you clump them all together, you now need to account for your changes in one function to work with the others in the same class.
–Use the Editor for clarity’s sake.
Use the inspector for displaying variable information. This can be especially important in debugging, and takes the place of debug logs. For example, if you have an enum to change states of something in your project, [SerializeField] it so that it’s still private, but can be seen changing states in the editor.
–Take advantage of prefabs and tags.
Relying on finding objects through their name, or programming with specific objects in mind doesn’t allow you flexibility in changing your application without breaking things. If you have an object that has a large number of behaviors on it, create a prefab of it. The ability to reuse and instantiate GameObjects already loaded with your desired behavior is nothing to sneeze at.
–Utilize Scene duplication and management.
Whenever you feel you’re at a juncture where whatever you do next in your project could break it, duplicate your scene and make changes in the new one. If whatever you’re doing works, great! Otherwise, you still have access to the original untouched scene.
Don’t be afraid to use all the tools Unity gives you. Hardcoding things certainly relates more to programming outside a game engine, but it isn’t efficient for making games in Unity. Think of your projects as asset store submissions. If you were to upload a project of yours to the asset store for others to download, would they be able to modify it with ease? Would they be able to adjust your variables in the inspector, or would they need to sift through your (hopefully commented) code? If you create projects in Unity with this flexibility in mind, you won’t have a problem modifying your games or apps ever again.