Search Unity

  1. We are migrating the Unity Forums to Unity Discussions by the end of July. Read our announcement for more information and let us know if you have any questions.
    Dismiss Notice
  2. Dismiss Notice

GameObject vs Object for no physics, menu driven game

Discussion in 'Getting Started' started by Abelabumba, Mar 9, 2015.

  1. Abelabumba

    Abelabumba

    Joined:
    Jan 14, 2015
    Posts:
    45
    I'm doing a sports manager simulation type game with no physics involved. Currently I have a Player.cs which defines a class Player with stats and so on which I create ingame by new Player(list of arguments).

    Originally I did it like this because I already knew how to, and my initial try to make them GameObjects instead didn't work out (I think it was because I didn't know how to refer to them once created, now I'd just put them in a list like I do now, anyway - is that correct?).

    So now that I know (or can figure out) how to make all players (and teams) GameObjects, are there actually any benefits to this? I guess editing their value directly in the editor while playtesting is one, but are there others? Are there any disadvantages by switching to GameObjects on the other hand?

    In my layman brain I think GameObjects need more resources due to them having more variables, but I'd guess that doesn't make a difference as long as there are a couple hundred of them live at any time, max?
    No animation needed on them, either.
     
  2. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Anything that has a representation in the scene must be a GameObject. If it doesn't have a visual representation then you can use regular classes. I do this frequently for data structures.

    Ultimately your code still has to start somewhere in a MonoBehaviour attached to a GameObject.
     
  3. Abelabumba

    Abelabumba

    Joined:
    Jan 14, 2015
    Posts:
    45
    Thanks, yes I know this - currently everything is working just fine, I'm just wondering if using game objects instead has any (dis-) advantages; the only reason I switched away from them in the first place was my lack of knowledge.

    The players (or rather, their values) do get represented visually in the scene in a way, like with buttons showing their name, or text fields showing their stats, but for that I simply use a List<Player>, the button scripts have a public int slotNumber and refer to playerList[slotNumber].playerName for example.
     
  4. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Then it sounds like you have no need for GameObjects for most of this stuff then. The only other drawback is you have to do some trickery around coroutines if you aren't in a MonoBehaviour.