Hi all,
I just started a new blog on Unity and OO programming. My first blog post is about a pattern I use very often in my games.
Would love to get some feedback.
Also I’m not too happy about the way the code snippets look, would really appreciate if you could point me to some better sites than the one I’m using ( http://dotnetfiddle.net )
The problem with your first example that uses an interface are the calls in OnCollisionEnter to GetComponent. You should really avoid calling GetComponent as much as possible, especially the generic version, which tends to be nearly twice as slow as the non-generic counterpart. It should be cached on Awake() into a variable, and referenced only through that.
Oh I didn’t know there was a performance difference with the non-generic version. Duely noted
however caching on Awake makes no sense in this case because you’re not always colliding with the same object.
The only alternative would be to use SendMessage instead of getting the component, but that’s a completely different subject
Yes obviously caching on awake in this case wouldn’t work, I’m just saying that’s how GetComponent should be used.
You have two alternatives, create an object cache, each time there is a collision, check the cache, if the colliding doesn’t exist, add it to the cache.
Or use Sendmessage as you said to broadcast the collision to all subscribers.
Thanks for the suggestion. I guess I now have a subject for my next blog post. I have a generic object pool pattern, guess I could use the pool as object cache.
Also if you want a strongly typed event system, much better than SendMessage, check this out, I love it.
http://www.willrmiller.com/?p=87
But if it’s about interfaces, there’s no point complicating the example with caching. I mean, there are a million other possibly useful things you could cram in. And anyway, it’s at best a tiny speed-up - you’re only colliding a few times a second and it’s not like you have 400 components. The extra memory it uses may slow you down.
What do you mean about non-generic getComponent? The one with a string is slower: GetComponent"Collider"), but that was for back in unityscript. The other two typeOf(Collider) (which is also not generic), or angle-brackets-collider, seem about the same.
Yeah I think GetComponent is only a performance issue if you’re doing it on update. A raycast is apparently more expensive from what I read. And like you said, caching is beside the point of my blog post. Still it’s interesting to know that there are alternatives.
Regarding vs typeOf(Component) I read an article dating back from 2014. Not sure if it’s still relevant. Would have to make some profiling to know for sure. I don’t see why it would be different though, unless it did some hidden stuff under the hood
Oh don’t get me wrong, I love the observer pattern 
just beyond the scope of my tutorial. I’m doing Event driven architecture any time I can
To get around the problem I sometimes add the component to a dictionary were transform is key and component instance is value. Then I can use that at a o(1) expense from oncollide.
Problem is you can never know how often OnCollide will trigger also some problems require OnCollisionStay. For example we have networked physics and if you touch one item that touchs another item that touches another item you should take ownership of all these items recursively. Otherwise physics will be calculated on the remote client and look a bit jerky.
Here is an example when I take ownership of a bunch of remote owned items
Yup that’s exactly what @Meltdown means by object cache
He means a cache to a single object, not a lookup dictionary. But yeah, they are both caches
Btw, I agree withyou, examples and tutorials should focus on the problem they try to explain. Not go out of scope. Though I would probably have changed GetComponent to a custom method. That way the reader just knows that you fetch the reference, not how. That way they are not led to believe GetComponent is the silver bullet to all problems.
Honestly the getcomponent is only there to illustrate a use case. I use this interface pattern everywhere I can. I actually use it for observer (Listener interface), object pooling (Poolable interface), and just about every time I need a list of objects that implement similar functionality
Don’t sweat it. There is nothing at all wrong with GetComponent as it is used in your example.
Actually, I’m not too sure what to think, is the use of getComponent the only noteworthy thing about my blog post? I had expected to get some feedback about the actually pattern, or the presentation, the tone, grammar, structure or just about anything else than the example use case used to Illustrate my point :shrug:
The same thought came to me, and for that reason I nearly didn’t comment at all. Honestly, the GetComponent part is perfectly normal and did not stand out to me whatsoever. I only posted in case the previous posts here were making you think it was a problem. Alas, I only skimmed the rest, so can’t yet give informed/useful feedback on it, and am just heading off for the evening so I’m unable to do so at the moment.
I only commented on the others, can read it and get back with feedback
So, using an interface is now a pattern.
What a progressive world we’re living in.
The pattern is not called “Interface Pattern” but rather “Interface Component Pattern”. There’s a difference.