Sign in to follow this  
wuh84

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

Recommended Posts

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

Share this post


Link to post
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 this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Announcements

  • Forum Statistics

    • Total Topics
      628379
    • Total Posts
      2982353
  • Similar Content

    • By sveta_itseez3D
      itSeez3D, a leading developer of mobile 3d scanning software, announced today a new SDK for its automatic 3D avatar generation technology, Avatar SDK for Unity. The Avatar SDK for Unity is a robust plug-n-play toolset which enables developers and creatives to integrate realistic user-generated 3D avatars into their Unity-based applications. SDK users can allow players to create their own avatars in the application or integrate the SDK into their own production processes for character design and animation.
      “Virtual avatars have recently become increasingly popular, especially in sports games and social VR apps. With the advance of VR and AR, the demand to get humans into the digital world is only increasing”, said Victor Erukhimov, itSeez3D CEO. “Our new Avatar SDK for Unity makes it super-easy to bring the avatar technology into any Unity-based game or VR/AR experience. With the Avatar SDK for Unity now every developer can bring face scanning technology into their games and allow players to create their own personalized in-game avatars, making the gameplay much more exciting and immersive.”
      Key features of the Avatar SDK for Unity:
      Automatic generation of a color 3D face model from a single selfie photo in 5-10 seconds (!). Works best with selfies, but can be used with any portrait photo.
      Shape and texture of the head model are unique for each person, synthesized with a deep learning algorithm crafted by computer vision experts
      Head models support runtime blendshape facial animations (45 different expressions)
      Generated 3D heads include eyes, mouth, and teeth
      Algorithms synthesize 3D meshes in mid-poly resolution, ~12k vertices, and ~24k triangles
      Six predefined hairstyles with hair-recoloring feature (many more available on request)
      Avatar generation API can be used in design-time and in run-time, which means you can allow users to create their own avatars in your game
      Cloud version is cross-platform, and offline version currently works on PCs with 64-bit Windows (support for more platforms is coming soon)
      Well-documented samples showcasing the functionality.
       
      Availability
      The Avatar SDK for Unity is offered in two modes - “Cloud” and “Offline”. The “Cloud” version is available at http://avatarsdk.com/ and the “Offline” version is available by request at support@itseez3d.com.
      ###
      About itSeez3D
      At itSeez3D, we are working on the computer vision technology that turns mobile devices into powerful 3D scanners. itSeez3D has developed the world's first mobile 3D scanning application that allows to create high-resolution photorealistic 3D models of people's' faces, bodies and objects. The application is available for iOS and Windows OS mobile devices powered with 3D cameras. In 2016 the company introduced Avatar SDK that creates a realistic 3D model of a face from a single selfie photo. To learn more about itSeez3D scanning software and 3D avatar creation technology, please visit www.itseez3d.com and www.avatarsdk.com.

      View full story
  • Popular Now