koobas.hobune.stream
Question is off-topic or not relevant
Organizing classes in Unity?
Hi everyone!
I've been fiddling around with Unity for a while now and what an amazing engine/tool it is.
After going through some tutorials, testing some cool stuff out, I am now starting to develop my first project.
Are there any best practice tutorials or something (I've tried to find some but failed) when it comes to organizing your classes (scripts) with the objects?
To try to clarify my question: I have created an empty game object called GameMaster which, right now has the prefab of the player object as a public property. I used the inspector to drag the player prefab into the GameMaster-script1 "StartLevel". The scripts Instantiates the player and then the game starts.
Now for example I want a GUI telling me at what speed the player is travelling. Would you:
Create a GUI Game Object as a child to the GameMaster.
Create a GUI Layer as a component of the GameMaster.
Not have a GameMaster whatsoever.
Create GUI programatically from within the GameMaster object.
Other possible solution?
And how would you go about passing the Player Object to the other classes that needs it?
Local property with a set function that gets called from the GameMaster.
Call a get function in GameMaster from the other classes.
Use FindObjectWithtag and tag the Player Object with the Player tag.
Obviously there are tons of different approaches to this problem. I realize we are blessed with the endless possibilities, but I just can't see the tree because of this big forest you know?
I am looking for some write up of best practice or some tutorial of different approaches.
Thanks a lot!
There's no real objective answer to this. For discussion, please use the forums.
To answer your first question, I would create a new GameObject named something like GuiManager which, with its children have all GUI responsibility. That is to say, only scripts that are either in the GuiManager or one of its children have the void OnGUI() method. This is because I find that once GUIs get complex, one gets tempted to put OnGUI-calls all over the place...
Currently, in my project I have only one OnGUI() call that goes though a list of GUI components, displaying them in an order of my choosing.
As for your second question, the best solution I have found is to make all Managers as singletons ( a static getter which returns the same instance to all calles), whereby getting access to them (and their properties) can be done easily from anywhere in the code.
I find that pretty much all Object Oriented design works (with slight modifications) on Unity design. A few good practices from OO design are to separate as much game logic as possible away from MonoBehaviours. This allows for easy unit testing and I think the project hierarchy is less cluttered with different folders for Logic and MonoBehaviours (and ScriptableObjects should you need them). I also try to program to interfaces, not implementation, as this allows me to change parts of my code in case of i.e. a server change or even during runtime. Also try to have your GameObjects and scripts have only a single responsibility and name it accordingly. I think this improves readability and clarity. As a rule of thumb, if you ask yourself "what does this do?" and the answer contains "and", you need to keep separating responsibilities. For eaxample, don't have a GameObject or script that keeps track of the player's stats AND shows them on the GUI.
In reality, it comes down to experience: create your project, and every once in a while look at the structure and design of your project, and see if it makes sense to you. Then try to think about how to make it less messy. Also have a read of http://devmag.org.za/2012/07/12/50-tips-for-working-with-unity-best-practices/
You might want to take a look at these:
**Stack Exchange - Programmers**: excellent resource for program architecture and coding style.
Read the Design Patterns and Anti Design Patterns **over in this site**.
Read the subsections of the **Unity Script Reference homepage**.
After all that.... it's up to you and your game's needs. There's no One Ring when it comes to coding, but there are good advises. :)
