Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Standard game logic?

Discussion in 'Scripting' started by Bunzaga, Apr 6, 2011.

  1. Bunzaga

    Bunzaga

    Joined:
    Jan 9, 2009
    Posts:
    202
    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?
     
  2. spinaljack

    spinaljack

    Joined:
    Mar 18, 2010
    Posts:
    992
    Set DontDestroyOnLoad() on an object that stores variables between scenes or use something like PlayerPrefs
     
  3. bigmisterb

    bigmisterb

    Joined:
    Nov 6, 2010
    Posts:
    4,221
    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):
    1.  
    2. function Start(){
    3.     if(GameObject.Find("myGameController")){
    4.         Destroy(this);
    5.         return;
    6.     }
    7.    
    8.     this.name="myGameController";
    9.     DontDestroyOnLoad(this);
    10. }
    11.  
     
  4. burnumd

    burnumd

    Joined:
    May 27, 2008
    Posts:
    367
    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.
     
  5. pakfront

    pakfront

    Joined:
    Oct 6, 2010
    Posts:
    551
    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.
     
  6. Antony-Blackett

    Antony-Blackett

    Joined:
    Feb 15, 2011
    Posts:
    1,778
    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.
     
  7. Bunzaga

    Bunzaga

    Joined:
    Jan 9, 2009
    Posts:
    202
    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.
     
  8. bigmisterb

    bigmisterb

    Joined:
    Nov 6, 2010
    Posts:
    4,221
    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.