Hi there, I searched some articles about components-based game object system and there have been some topics about it. I have also just read Jason's book, of which some chapters are talking about game objects. I was going to take a try to implement game system in this way but I met a small problem, hoping someone here could figure me out. My question is this. I name my game object a pure game object as what jason said in the book, which is only a handle/id that every component it has points to. So the component composes a single object id, which indicates whom it belongs to, and other component data. Many components managers maintain their own type of components. In a data-driven system, a type of game object could be written as a list of components. Problem arises here. Should I constrain that each game object can hold only one instance for every type of component? For example, can a game object have manys aniamtions? The obvious answer is yes. But it seems a little out of road of my initial design. In my first print, I think each components manager will have only one copy instance of a component for a single game object, meaning only the type matters. this way components manager only needs to index the game object handle, because there is no duplicate. But here, I need to remember the name of this type. This way, components lookup becomes not as simple as what I expected. I 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. I also think it might be a game object definition question. I am willing give the script ability to define a new type of game object. So, I am confused about name, type and value situations. Should I only specify the type of components, or along with a corresponding name to it? How to assign the default value for a component? or should I? Things are like you are defining a c++ class and you need to take a thoughtful consideration of how to organize your symbol table, which mades me mad... So, could anyone help me out? Thanks in advance hao

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.

S,

Your reply does really enlighten me.

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

Quote:Original post by wuh84

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

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.

Quote:Original post by wuh84

I 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.

Quote:Original post by Antheus
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.

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

Quote:Original post by Sphet
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.

Yeah! This is it!