Unity a problem about the design of components-based game object system

This topic is 3048 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Share on other sites
hao,

Welcome to the world of compromises, trade offs and design iteration.

Don't think of an animation as a component. Instead, think of an AnimationCollection as a component that contains one or more animations.

Don't confuse the resource data with the component. Just because you have a Model component does not mean you have a Texture component for each texture that model uses.

On the flip side, don't paint yourself into the corner of having only one component of each type allowed. There will be cases when you need this. You can't know now what they are, but you will.

In our case it had to do with how prop states were created, or particles. There are always work-arounds, but if you design support from the start it should work.

In our engine you still find components by type, but we also support finding a range of types with an iterator so you can say GetComponents<Particle>( entityID ) and it will return an Iterator<Particle> which can can call ++ and IsDone() on.

best of luck with your design

S.

Share on other sites
S,

I realize it is a tough question to line up between metaphors. Is a texture a component or just a resource aggregated into models or materials or such. What I feel a good way to answer is assume myself as a user of my code. Which way is the much more human-readable and understandable I feel like, I will then choose to.

I think AnimationCollection as a component is a good choice. First time I saw the name, Animation State Machine, I was really excited. To make the engine code easy to use and fast to produce, many facilities will be great helpful. I mean ASM could be done in many ways or even there is not one. It all depends on how you want your user use your code.

I know program to interface is a best practice, but when I do a real coding, I always lost myself into deeper details, which somehow lead me to somewhere I totally lose control...

The way of components lookup you mentioned looks tricky and decent. Yes you are right, don't assume anything when you design, just think of how to make it as easy to use as possible. Through the whole night thinking, I finally decided to allow multiple instances of single components, although coming from different ways of thoughts:P

Anyways, thank you again. This really helps me out of mad.

p.s. since resource data mentioned here, I am a little confused about between objects' serialization and resources' loading. I think the difference between is that objects could be copyable but resource not. In other words. objects could be modified and then deserialized, but resources are only data that are loaded from disk or somewhere and persistent all the time and also resources ane shared data over the game life. does this make any sense at all?

hao

Share on other sites
Quote:
 Original post by wuh84p.s. since resource data mentioned here, I am a little confused about between objects' serialization and resources' loading. I think the difference between is that objects could be copyable but resource not. In other words. objects could be modified and then deserialized, but resources are only data that are loaded from disk or somewhere and persistent all the time and also resources ane shared data over the game life. does this make any sense at all?hao

In our engine we consider resources like any other constant value - immutable and unchanging. Our resources (models, textures, sounds, animations ) are shared among many instances of the same components in a read only fashion. Our rational was that they are authored in distinct tool sets and come to the game-entities as largely opaque collections of data. The designers and programmers rarely worry what is inside them, focusing exclusively on the game entities.

Share on other sites
Quote:
 Original post by wuh84I took a look at Unity3D tools. It allows each object only contain one instance of each component. But if I say, a soldier has 10 animations, it is not wrong. I stuck with this trade-off.

A soldier has animation component - which means it can be animated. Whether it is a single animation or multiple - it is still animation component.

Animation component has single method:
animate();

There is behavior component, which is a state machine, which has single method:
void setBehavior(string behavior);

When animation runs, it asks behavior component. If entity has no behavior, or currently selected behavior doesn't have an animation, or that animation cannot be applied to current model - then default animation is played. Otherwise, specific animation is played.

Everything besides interface is a matter of implementation.

Share on other sites
Quote:
 Original post by AntheusThere is behavior component, which is a state machine, which has single method:void setBehavior(string behavior);When animation runs, it asks behavior component. If entity has no behavior, or currently selected behavior doesn't have an animation, or that animation cannot be applied to current model - then default animation is played. Otherwise, specific animation is played.

Hello Autheus,

Please forgive my ignorance. I not quite understand the behavior component you mentioned.

What is the animation supposed to ask behavior for? which animation should be run? which property will be animated? Did you mean that animation component would be a collection of animations and how to apply the animated value into porperties of game objects is decided by behavior component, in which update should be overidden. Is that a case?

hao

Share on other sites
Quote:
 Original post by SphetIn our engine we consider resources like any other constant value - immutable and unchanging. Our resources (models, textures, sounds, animations ) are shared among many instances of the same components in a read only fashion. Our rational was that they are authored in distinct tool sets and come to the game-entities as largely opaque collections of data. The designers and programmers rarely worry what is inside them, focusing exclusively on the game entities.

Yeah! This is it!

1. 1
2. 2
Rutin
19
3. 3
4. 4
5. 5

• 14
• 12
• 9
• 12
• 37
• Forum Statistics

• Total Topics
631435
• Total Posts
3000056
×