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.
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.
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, the button scripts have a public int slotNumber and refer to playerList[slotNumber].playerName for example.
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.