Storing variables on game objects?

Unity Engine
1

I’m currently thinking about creating my own mini strategy game, and I expect there to be a lot of cloned Game Objects with their own stats. What would be the best way to handle this? Can I just attach a C# file with the right integers (etc) to a single Game Object and clone it relentlessly? Or should I store all the stats individually in some kind of massive giga-table? If I take the first option, how would I keep track of everything? Is there some sort of Object ID code I could keep track of? How would I go about tweaking the stats of an object?

2

There’s a bazillion different ways to approach this.

You can stand everything up as MonoBehaviours hanging off of GameObjects, but then if in the future you want those GameObjects to swap out, you’ve created a dependency.

You can create a table of all the things in your game and then use Unity GameObjects only as “output” to show them.

And you can do any variation of the two things above you can imagine.

For Day 1 I would put the data in a MonoBehaviour and work with it for a bit, see how it goes.

ALSO: don’t just throw a bunch of data in and object and start banging on those variables from all over your program, or you will make spaghetti soup. Instead, define the transactions you will do to the variables, such as “deal damage” and whatnot, and make functions. That way if your underlying data storage changes, you have one function to change, you don’t have to find everywhere you say thing.health -= 10; in your code.

The important thing is to get stuff going ASAP in the simplest way possible, and reason about how the progress goes. Expect to make mistakes and refactor. That’s how engineering works.

3

Thanks for your help!

Ah, that could be an issue! Could I solve this by attaching the script to an empty game object, and attaching that to it as a child? If so, it shouldn’t be too much of an issue.

Ah! Good catch! Thank you! By that I’m assuming you mean that I should attach all methods directly to the Game Object and then activate them externally? I don’t suppose there’s a tutorial on doing that?

4

What’s the point of attaching it to GameObject then??

What I would do:

  • have a main script that stores the board (this lives on a single GameObject)
  • it keeps custom data structures for your game logic in some kind of collection (like a 2D array)
  • 100% of all game logic uses this board for reference
  • when the board detects changes, it calls another script to display them, either all at once at startup, or as things change.

This would be where linkages are maintained from a cell out to the relevant GameObject.

Close: I’m saying keep your logic as centralized as possible on each thing, don’t make the entire game have to know what an enemy units needs when it needs to lose health.

5

It would be to keep the data attached to the object it refers to so I can just use an int for health and so on and don’t need to look a unit up on a table to damage it? I dunno. This doesn’t seem like a big difference to me. The only way I can see it going wrong is if the parent object gets targeted instead of the child for something. It could make the unit immortal.

Ah, okay. I think I understand what you’re saying.