next »

[SimplyRivet]

I am currently looking at making a game in unity, and after a taking a few jabs at it, I realized I don't know which chunks of code deserve their own components.

For the most part, anything that controls one object is easy. All the player movement logic is grouped with the player controller, and so on. The problem is when I try to add functionality like fading.

Do I want to add a "fade out" component, that when I add it to an object it fades on death? Should it be part of a larger "effects" component that I add whenever I want to do anything with fading, changing the tint on the sprite, or anything in that realm? Do I take the middle ground add make a "fade component" which deal with fading and only with fading?

Is there even a best way to handle this? I am interested in your thoughts.

[Geti]

Anything separable enough to be useful. There's nothing worse than components that eat 40 lines in the inspector and try to do 30 things; a single fade out (ideally that you can add/attach at runtime) sounds fine. If you want a heap of effects, group them all in a sub-folder, you can always attach them all to something that needs them all.

Consider approaching it a little differently too though; a fade is just a lerp of alpha or multiply colour or similar over time - you may want to encapsulate that instead of the specific case of fading out/in, because you might want to fade or adjust several properties as your project goes on -  and a component might not be the best approach to encapsulating that behaviour all the time (for fades/lerps/whatevrr, consider coroutines)

If this was in your own engine I'd have a few other things to say but it's not so I won't add extra noise, hope this helps

[jgrams]

Also consider not separating something out until you're actually using it in two to four places. That way you have some use cases to suggest what should be separated out, and how, and to help you avoid overgeneralizing, or generalizing the wrong thing. But it's still only a few uses so you don't have to be replacing code all over the place.

[RandyGaul]

I actually hate granular components. You'll get a lot of different answers depending on who you ask.

[manabreak]

Also consider not separating something out until you're actually using it in two to four places. That way you have some use cases to suggest what should be separated out, and how, and to help you avoid overgeneralizing, or generalizing the wrong thing. But it's still only a few uses so you don't have to be replacing code all over the place.

I like this answer. I apply this in my development quite thoroughly - if I can't immediately see that a feature should be encapsulated into its own component, I'll just write it there where I need it. If I run into a situation where I need the same feature again, that's when I pull out the first version and write the component. Or, in the case of prototyping, I might do it after the third or fourth one, depending on the amount of code needed. If it's something that takes five lines, I usually don't bother writing a whole new class for it. If it's 100 lines, then it's a different thing.

[nikki]

If this was in your own engine I'd have a few other things to say but it's not so I won't add extra noise, hope this helps

what wisdom, I immediately feel the need to compare a 'fadeout' with a larger collection of 'eases' which all work very similar (and just have another single line function behind them), all of those eases could be managed by a EaseManager/TweenManager, in the context of a component entity architecture it -to me- look like a system thats more similar to your Physics System then a real System for components, in any way I would prolly not make a FadeComponent but would make a EaseComponent, that would, among others things, be able to fade an arbitrary property.

Al of ths blabla might not at all be applicable to your design, so yeah.

[Geti]

If it's something that takes five lines, I usually don't bother writing a whole new class for it.

Sometimes, the elegant implementation is just a function.
Not a method. Not a class. Not a framework. Just a function. (link)

Food for thought for those still infected with OO-itis; hard to help myself some times

[Taelen]

If it's something that takes five lines, I usually don't bother writing a whole new class for it.

Sometimes, the elegant implementation is just a function.
Not a method. Not a class. Not a framework. Just a function. (link)

Food for thought for those still infected with OO-itis; hard to help myself some times

Yes. Came across this quote a while back in another discussion about component systems. It really changed my coding style.

[jgrams]

I think I'm happy I cut my teeth on Basic and assembly language and C -- of course then the endemic disease is premature optimization, but I feel like that's easier to cure than OO-itis.

[Geti]

Definitely. I see so many people in uni with Java as their first language who really have trouble breaking out of that model of thinking. Premature optimisation generally leads to localised mud balls at worst, OO-itis is globally pervasive.

[OnslaughtMike]

I agree withe jgrams. I spend way to much time trying to write overgeneralized components to find I only use it once or in 1 specific way. It ends up taking away to much time from the main goal of getting my game done.

[nox]

Code:

Do I take the middle ground add make a "fade component" which deal with fading and only with fading?

This is the decent option, but I would think about what a "fade" really is. It's just a tween of a value, and there are things other than fades for which a general tweening mechanism would be useful. I don't know about Unity in particular, but I'm sure you can define a component that consists of animation functions coupled with start times and end times. When you attach the component to the entity, you can specify which aspects of the entity should be tweened and with which animation functions. Fade out is just one of many possible animation functions, and Here are some more.