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

Best Practices for Scripting Game states and Logic

Discussion in 'Scripting' started by Copywright, Mar 3, 2013.

  1. Copywright

    Copywright

    Joined:
    Apr 17, 2012
    Posts:
    21
    Hey,

    I've been working in Unity for a few months now, and I feel as if I get the ins and ous, so far. However, I'm curious before I delve deper on how to set up my structure of scripts. I understand that you're supposed to have manager classes like Game Manager, GUIManager, InputManager, etc., but I'm still a bit fuzzy on the concept.

    I'm looking for examples or advice on how I should be making these scripts,like should the GameManager also store game logic, like score, money, etc.? How would you have these manager classes persist through many scenes? I know about DestroyOnLoad, but is there any more efficient way?
     
  2. shaderbytes

    shaderbytes

    Joined:
    Nov 11, 2010
    Posts:
    900
    Surely you mean "DontDestroyOnLoad" ?

    Why would you think of this as inefficient? There are several approaches to building code frameworks and books on Design patterns etc that are good to read. The God object is used often by many , others hate it .. same for singletons.. guys who are into unit testing think singletons are from hell ( although having a single instance of a class is not so long its singularity is not maintained by the class itself ) Game logic is normally best handled via state machines and events.

    Managers can be engineered to be reloaded on a new scene or persistent .. the choice should be based on the benefits for each direction .. scalability , Flexability etc.. but I dont think you can ever get away from having some sort of core structure for you code. and normally this core is persistent and does not need to reload.

    for example my core class is name "ApplicationManager" and uses "DontDestroyOnLoad" but it does not contain any game logic . Its always best to split the concerns of code into smaller pieces that handle only what they need to handle.

    As you delv deeper into this topic you will find much debate about best practices for all of this .. a well known paradigm in the OOP coding world is to learn to code towards an interface and not an implementation , you should definately look into reading about what that means in detail .. im still learning