Maybe I’m going about this problem all wrong, but here’s what I’m trying to do-
I’m making a target shooting game. On startup, I’m using a loop to instantiate a bunch of targets to reuse throughout the game, stored in a standard array.
for (var i=0 ; i < TargetInstances ; i++ ) {
Target[i] = Instantiate(TargetObject, Vector3(0,0,0), Quaternion.Euler(0,0,0));
}
Each target will also have it’s own unique properties such as how many points it’s worth that needs to be stored with it. Then the most important part is that I somehow need to access the corresponding property on RayCastHit, preferably somehow getting the array index of the object, but I have no idea how.
I had this working fine if I keep the properties in a script attached to each object, but I’m trying to get away from that and keep it all within the one script, and I don’t know how to do it. I’m not sure if I should be using a class for this (I’ve never used them before, so I’m sorta clueless on that), and I don’t know how to find the object index using the RayCastHit. Maybe there’s a better way I should be doing this?
Why do you want to get away from storing object properties directly on the objects via an attached script? That’s the standard way to do things in Unity, and works well in general.
As to the specific question of how to get an array index from a RaycastHit, the short answer is: you can’t; Unity doesn’t know what arrays you’ve stored references to what game objects in. You would have to search through the array element by element looking for a match with the hit result, or build and maintain a lookup table.
There are a few reason I want it in one script in this scenario.
Each target has several parameters I need to read and change, plus I have SpriteManager handling the sprites for each one, and it’s getting messy to access all of these parameters and components across multiple scripts, when having it in the same script makes things a lot easier to me, once I find a good way to match parameters to each object.
Also, this game will be for iPhone, and I’m trying to minimize the number of updates per frame, and I think I could do a lot of these updates more efficiently in the one script rather than having each target with it’s own update code. Each target is changing it’s point value over time, and animating position/rotation/scale through code, and while that is easier to do that per object, I’m not sure what the performance hit will be.
Even if I can’t access an instance number, is there some way to attach properties to each object through one script without doing it with a script on the object? Or do you think having a script per object is still the best solution?
I haven’t used SpriteManager so I don’t know how that factors in to things. The thing is, if the parameters are stored on the object directly (in a script) you don’t need a way to match them up; once you have a reference to an object, you can access its data.
So measure it There’s little point throwing out a working solution for one you can’t quite get working just because you think it might perform better… You should never optimize for performance unless you know there is a performance problem.
It’s the best solution unless you can demonstrate/prove an alternative solution is better in a your particular use case… You could always consider a hybrid of the two: one script attached to the object which holds the data specific to that object instance, and one seperate script with an Update() function that processes all the objects. There’s no reason that update script can’t cache an array of references to the object at runtime, if it makes life easier. But keep the data with the object it applies to, then a reference to the object is all you need to access the data.
I don’t believe SpriteManager attaches the sprites to the gameobjects directly. They’re treated as separate sprites, and I don’t know of any way to refer to them based on gameobject (but I’ve only been using it for a week, so maybe there’s a workaround for that).
I’ll probably try a combination like you suggested. There aren’t all that many targets being used at once, so the performance hit might not even be an issue, even on the iPhone.
There’s little point throwing out a working solution for one you can’t quite get working just because you think it might perform better… 
You should never optimize for performance unless you know there is a performance problem.