I noticed there is no 'scene' or 'project' script anywhere. Things like global variables, such as player lives, number of enemies in the scene, game states, etc. What do people 'normally' do for things like this? My first instinct is to create an empty game object, give it a script, and thats it. Is there a better way to do this?
Set DontDestroyOnLoad() on an object that stores variables between scenes or use something like PlayerPrefs
Here is a cute piece of code to handle reloading a level when you already have a persistent controller object. Just don't name the object "myGameController" Code (csharp): function Start(){ if(GameObject.Find("myGameController")){ Destroy(this); return; } this.name="myGameController"; DontDestroyOnLoad(this); }
You might realign how you think about your game logic. Unity operates most fluidly within the Composite pattern. For player lives, the typical Unity way to do it would be to create a script that has a field for currentLives (or somesuch), and handles the logic for incrementing or decrementing it, and notifying the appropriate entity to load the main menu or bring up a specific GUI when no lives remain. It can also contain a variable for the number of lives the player starts with and in this way, you can tweak these values in the Inspector. You'd then attach this script to your player. For your number of enemies in the scene, I'd create a spawner with a variable that sets the number of enemies in the scene and a list of possible Transforms where enemies could spawn. Again, doing it this way, you could use that same object from scene to scene and alter the number of enemies and their spawn locations from the Inspector. In general, the "Standard" way of doing things in Unity is to let each GameObject be responsible for its own behavior by segregating logic into discrete Components and allowing them to interact only when necessary. It can be difficult for some to get out of the "main loop" mentality, but I've found it to be more rewarding for Unity development in the long run.
or use a singleton for your Managers. BigMisterB's example is one, or you can use a static instance variable to make sure there are none already around, as demonstrated in the link. The nice thing about using the singleton methodology is you can use static accessors to get to the singleton from any other object. The down side is that if you find you ever need more than one instance of the singleton, it's a giant pain to refactor.
The last point is why I never use singletons. It's easier to start without them than change the whole game when you want to add a second player for example.
Yea, I like the idea of modular design. So if I wanted to stick with that, say for a simple 'breakout' example, you start with 3 lives. This I could put in the script attached to the paddle mesh. So now I want to load a scene for one reason or another. Would I just put the 'DontDestroyOnLoad(gameObject)' command on the paddle mesh? I am also assuming this would have to be done with UI elements too... like if you are using planes for the UI, you obviously want these to be persistent between levels. Would it be better to just keep an array of all added objects, then delete them, and reload the new list of objects inside the same scene, or actually load an entirely new scene? You are correct burnumd, I am having to rethink the way I do things, and could use any advice along the way. Thanks for all the tips and ideas guys.
The only object that should persist through your levels is the GameController.. (The object that keeps track of vital information) The rest of the objects ask the GameController what those values are. So in the case of Breakout, your game controller would have the overall score, the style of bar that you have and stuff like that. The bar, would ask the game object what style it should be in, and do it. If you collect a power up, the bar should tell the game object it has changed. GUI's are in the GameController, but not the same. It really depends on how you want to do it. If you change the gui from level to level, it should not be part of of it, but should relay the information stored in it. Just remember, If you want a persistent object, you MUST make sure that object cannot be replicated. Hence the script I wrote above does that perfectly. For every persistent object, you need to use a script that keeps it singular.