GameController Gets added twice to Hierarchy

When i loose the game and restart the game it adds another GmaeController to my Hierarchy. That new GameController Prefab breaks the game it has no references to any objects in the game.

Is the code below creating another instance of the Game controller in the hierarchy?
I cant find any code instantiating a new Game controller. IE - Instantiate(gamecontroller)

IF this code below isnt adding it to the Hierarchy what other ways are prefabs added to hierarchy?

Code (CSharp):

1. public class GameController : MonoBehaviour
2. {
3.     // CONSTANCE
4.     const string GS_TAG = "GameSpot";
5.  
6.     // GENERAL OBJECTS
7.     public MovePlayer moveplayer;
8.     public GameObject lightBeam, player, playerSpawnSpot;
9.     public EnemyManager enemyManager;
10.     private GameObject enemyCollider;
11.  
12.     // GAME SETUP OBJECTS
13.     static GameController _instance;
14.     public static GameController Instance
15.     {
16.         get { return GameController._instance; }
17.     }
18. }

 

I would look at the Singleton implementation on the Unify wiki(http://wiki.unity3d.com/index.php/Singleton).

 

Thanks I read the article but im such a newbie that I dont understand how to relate it to my script.

 

You need to preserve the singleton instance between loads by using DontDestroyOnLoad. You also need a way to check if the application is quitting so that all new calls to get the singleton instance return null. Normally getting the singleton instance is thread safe and will automatically create a new instance if one doesn't exist.

 

I cover this in one of my tutorials I made. A simple script called MasterObject

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4.  
5. public class MasterObject : MonoBehaviour {
6.  
7.     private string originalName = "";
8.  
9.     void Awake() {
10.         // if we find another game object with this name + _Master
11.         // this means that this is not hte master.
12.         GameObject other = GameObject.Find(gameObject.name + "_Master");
13.         if (other != null && other != gameObject)
14.         {
15.             DestroyImmediate(gameObject);
16.         }
17.         else
18.         {
19.             // we didnt find one, so set this one to be the master.
20.             gameObject.name = gameObject.name + "_Master";
21.             // make sure it doesnt get destroyed.
22.             DontDestroyOnLoad(transform.gameObject);
23.         }
24.     }
25. }
26.  

http://clarksvillegamedesign.net/learn/tutorials/worm-game-interface/

 

The example you posted isn't a singleton... Singletons are also not meant to be destroyed during runtime. Your software has gone horribly wrong somewhere if your singleton is destroyed or duplicated and should result in the application closing.

 

hah, no, it is a singleton, but it is designed that if you reload the same file, where the original came from, then you would have 2 of them in the scene, both, then becoming singletons. If that happens then you run into problems with your game.

You should look at what that code is doing before you comment on it.

 

Your "singleton" is missing one of the key implementation details that would otherwise make it a true singleton.

 

I wish for you to Prove that this implementation does not fulfill the requirements of the OP

 

You have no global access. Your class is not a singleton and fulfills only half the requirements of the OP. Just because your class searches for and destroys any duplicate instances, does not make it a singleton.

 

The OP asked why the object appeared twice. I gave him a way to remove the object, and you say, I didn't?

Making this a singleton does not remove the second object at all. So, making it a "singleton" does not fulfill the OP's requirements. Since, the OP said nothing about singletons, he had no requirement for that. Please, Feel free to PM me, because this is just going to be a stupid flame post about why X and Y are not the same. In the end, I will tell you "I DON'T CARE ABOUT YOUR OPINION"...

 

The OP's class is a poorly implemented singleton. As a result of the poor implementation, he is obtaining duplicate copies of the object. The fact you don't seem to understand this means you shouldn't be replying to this thread.

 

OMFG... why didnt you start by posting code, rather than a poor explanation.... again... your opinion doesnt matter..... You spent more time writing your stupid posts and trying to argue a point, rather than helping.

 

Did you even click the link I originally replied with? It shows an actual functioning singleton class that he could simply copy/paste into his project. There are even instructions on how to use it. The bastardization of what you originally posted and assumed was a singleton will most likely only serve to confuse the OP.