Struggling with understanding Unity's component way of structuring

I was reading the article on Asset store blog about NGUI author talking about it finally clicked for him how to use Unity's component based way of constructing things, instead of his object oriented C++ thinking. Well for me it has not clicked and I'm struggling to understand the "proper" way to structure things.

So I'm going to create a small prototype so that I'm hopefully will get it. But I would need help from you guys. My small prototype is a golf driving range (where you hit golf balls). I have attached an image to more visually show the basics of it. You have NPCs that walks up to a ball machine to receive golf balls, they then walk to a free spot (a mat), "gives" balls to the mat and start hitting them.

I'm not sure about the relationship between the things involved. For example, what is the proper way for the NPC to look for a free spot to hit the balls from? Are those spots (every spot is a prefab I assume) grouped under one gameobject and the NPC then look for mat-objects under that grouping that is free to use? Or should there be an object (class) that has collection of mats where the NPC look? I just don't understand how to structure things so that different objects are aware of each other if they need to.

Or should you have a base object (DrivingRange) that you attach one ball machine object to and X amount of mats? So that the player always know where everything that needs to be interacted with is through that base object? So it would call DrivingRange.GetRandomFreeMat(), DrivingRange.BuyGolfballs(1) etc. I would like to place machine and mats in editor. So I guess I would create public variables that I can drag and drop the objects to, so that they are assigned to the variables in the DrivingRange obeject.

I guess it's the grouping of things that confuses me. I'm not sure where to start.

I would really appreciate if you guys can spare some time and try to explain how the proper way, or your way, would be to implement this. Or if you have a better example that might make it more obvious in how to build things properly.

 

You can have a controlling GameObject (whether it's "real" or not - it doesn't have to be the ball machine for example) and declare an array of DrivingRangeMat components. Then Unity's Inspector will let you set, for the current scene, how many mats there are. Place the mats in the scene, then drag them from the scene hierarchy view onto slots in the DrivingRange's list of mats.

Unity's handling of lists in the inspector kind of sucks, though, so you might be better off letting each mat store a reference to the DrivingRange object, and having them call a method on it to register themselves, in Start().

Players need a reference to the DrivingRange object - they too can store that as a public member varaible. If the players are created statically in the scene file then you can set the relationship up by dragging, again; or if the players are spawned dynamically, then immediately after spawning them you should set the DrivingRange reference.

If all this dragging and dropping is annoying then you can make the DrivingRange object scan the scene on startup and set these references to point to itself. You need to take care to ensure that the other objects don't fall over badly before the reference is set - or fiddle with the script execution order to make sure the DrivingRange object runs first.

You can also use a static member in the DrivingRange class to point to its instance, and again set that correctly in its Start() method. Then all your other scripts can access it without needing their own references. That will make life easier, so long as you're sure you'll never need two DrivingRange objects for any reason.

There is no proper way, and there are lots of different ways to do these things. It's probably best if you just try to implement it somehow, and see whether you think your approach worked well or not.