Global Scripts/Variables

Obviously, you have the option of just using static classes for this, but from a software design perspective that's pretty stinky.

Why do you think it's stinky? I would do it as static without hesitation. $$anonymous$$aybe not the whole class, but as static property:

 public static Vector2 Ratio
 {
     get { return ratio_calculation_expression; }
 }

I think it's stinky because it breaks the rules of object oriented program$$anonymous$$g. There's pretty widespread discussion on this subject elsewhere, but this page pretty well sums up my feelings on the matter.

Interesting, so what are my less stinky options?

Well, initially I would have suggested that 'empty gameobject/DontDestroyOnLoad()' thing, but you say that causes problems for you. Care to elaborate? It's what I've always done, and it's never given me any trouble.

I took a look at the page you linked. I haven't read this one before, but you're right - there are many other articles/posts/questions related to this subject (as well as to statics vs singletons, which are sometimes similar).

In my opinion, using statics is still very good option for specific situations. Especially if you just need a read only variable. Without this, we would not have Vector3.zero, Camera.main, Int32.$$anonymous$$axValue etc. For these values, it is perfectly ok to use them without creating class instance. It's not only performance wise - it's just logical.

That's cool sycla I expected as much.

Basically I have a script that grabs the Res when it starts (This object is in the first scene that is loaded.)

 using UnityEngine;
 using System.Collections;
 
 public class ScreenResolutionScript : $$anonymous$$onoBehaviour 
 {
     //Public Variables
 
 
     //Private Variables
     private int nativeResH;
     private int nativeResW;
     private int resRatio;
 
     void Start () 
     {
         DontDestroyOnLoad(gameObject);
         SetResH(Screen.currentResolution.height);
         SetResW(Screen.currentResolution.width);
         resRatio = Screen.currentResolution.height / nativeResH;
     }
 
     public void SetResW(int res)
     {
         nativeResW = res;
     }
 
     public void SetResH(int res)
     {
         nativeResH = res;
     }
 
     public void SetResRatio(int res)
     {
         resRatio = res;
     }
 
     public int GetResH()
     {
         return nativeResH;
     }
 
     public int GetResW()
     {
         return nativeResW;
     }
 
     public int GetResRatio()
     {
         print(resRatio);
         return resRatio;
     }
 }

This works perfectly fine in the first scene, however when I load to the next scene none of my Gets work they all produce 0 values. I get a divide by 0 when trying to find the ratio and printing the values also showed a 0. I set my private variables to public so I could see them in the Editor and the values were correct.

I assume I'm missing something very basic :(

@syclamoth: Static variables and classes are fine - they are in fact extremely useful, and more efficient in places. You do have to be careful how you use them, but that's true of just about any feature. You of course should only use them when really necessary, but saying they are on the whole useless is laughable. Yes, you can write code without them, but you can also write code without arrays, or else blocks: it doesn't mean you shouldn't. In this case, a static variable is the correct approach, as the game will only be rendering to one screen.

Have a look at this page, it explains why actually, static methods and members are GOOD practice, where appropriate: http://www.velocityreviews.com/forums/t117353-advantages-of-static-vs-instance-methods.html

On an unrelated note, are you sure resRatio should be an int? That looks wrong, unless it does something different from what I think it does.

As for the invalid values thing, I can think of 3 things that might be happening:

1: the object is being serialised and deserialised, like what happens when you reload your assemblies at runtime. I can't really tell why that would be happening, but the symptoms are the same.

2: there is a version of the object in the newly loaded scene that is confusing other parts of the system? Now that I think about it this seems unlikely, as it's a pretty obvious mistake to make, but still worth checking. How are you accessing this object elsewhere?

3: Start is being called more than once. Again, this is something that shouldn't happen.

You are completely correct it should be a float.

 public GameObject globalScripts;
 
 //...
 
 ScreenResolutionScript reScript = globalScripts.GetComponent<ScreenResolutionScript>();
 
 

@Hoeloe 'executes faster' and 'good practice' are not always the same thing. Unless performance is your number 1 priority it is generally better to adhere to OOP principles where possible. That link of yours explains that static functions are faster (which, for that matter, is fairly implementation-specific and may not even apply to C#), not that they are better.

Where do you set 'globalScripts'? Is it a game object that gets loaded with the scene, or does it get set after the scene has laoded?

I'm afraid to answer this because it's kind of amature but I just drag it into the public variable box in the inspector.

I guess I could define it at runtime by using

 globalScripts = GameObject.FindGameObjectWithTag("Global");

Haha It works now, it's printing 1s :) and although it wasn't the major issue I wont run into the issue of trying to put a float into an int ^^ cheers syclamoth <3 thanks for the help

@Syclamoth That is true, but in general terms, static variables are also easier to understand and maintain than some of their more roundabout alternatives. While it may not be "strict OOP", I'm a believer in using the tools available to you where appropriate, and not trying to circumvent them simply because it's not strictly part of this type of language. There are a lot of things like this in most OOP languages. Hell, Java has even added lambda notation in Java 8. I do not believe that it is better practice to try and circumvent the tool than to use it in an appropriate manner.