Jump to content
  • Advertisement
Sign in to follow this  
WSPSNIPER

Entity System ( Component System )

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

ok im having trouble understanding how this works, in one article i read it stated that you were to stay away from all oop and use arrays and ids to find entities and components. others say that i should have a base abstract component class and an entity class and take an oop approach. im just confused on how this all works, i would love to learn more about component systems and different practices in using them, right now i do use oop when i program.

i would like to know how entities have access / store components and how you use the components on the entitiy. i would also like to see how you guys have done this ... i know i sound like a noob but i would appreciate any help given. Thanks in advance :)

Share this post


Link to post
Share on other sites
Advertisement
Hey!
I suggest you to start with this very useful thread that helped me a much, with my component system (that is still in development).
Also check out this thread that was posted by me.
And check out the T=Machine blog posts.

I hope it will give you some initial information to start with, and if you will have any more question, feel free to ask them!

One last suggestion, try not to think OOP, its hard, and most of the suggestions will look dumb to you (like comparing ES to RDBMS) but believe me the moment you will stop to think OOP, the system will look so simple and so modular to you!

Good luck! =)

Share this post


Link to post
Share on other sites
Quote:
Original post by skwee
Hey!
I suggest you to start with this very useful thread that helped me a much, with my component system (that is still in development).
Also check out this thread that was posted by me.
And check out the T=Machine blog posts.

I hope it will give you some initial information to start with, and if you will have any more question, feel free to ask them!

One last suggestion, try not to think OOP, its hard, and most of the suggestions will look dumb to you (like comparing ES to RDBMS) but believe me the moment you will stop to think OOP, the system will look so simple and so modular to you!

Good luck! =)


Thank your for your responce, the links, and the tip about oop because it is super hard to think in another way but ill try :)

Share this post


Link to post
Share on other sites
Hi,

Quote:

...because it is super hard to think in another way but ill try :)


http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html

Here's my slightly modified version; I found it funny, but then again, I have a strange sense of humour. Perhaps it won't make you giggle, but it'll make you see a subtle, important lesson:

Quote:

The venerable master Qc Na was walking with his student, Anton. Hoping to
prompt the master into a discussion, Anton said "Master, I have heard that
oop is a very good thing - is this true?" Qc Na looked pityingly at
his student and replied, "Foolish pupil - oop is merely a poor man's
component-based system."

Chastised, Anton took his leave from his master and returned to his cell,
intent on studying entity systems. He carefully read the entire "Gamedev.net" series of threads and its cousins, and implemented a small
component-based system with no oop. He learned much, and
looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that oop is truly a poor man's component-based system." Qc Na responded by hitting
Anton with his stick, saying "When will you learn? Component-based systems are poor man's
oop." At that moment, Anton became enlightened.

:)



Once you have to deal with (de)serialization, efficient message passing, object pooling to go easy with allocations etc, you'll realize that even T4 (boring code generation!) is an awesome tool.

Bottom line is: research component systems, but don't let them blind you with their shininess!



ooo shiny

Share this post


Link to post
Share on other sites
Quote:
Original post by skwee
Hey!
I suggest you to start with this very useful thread that helped me a much, with my component system (that is still in development).
Also check out this thread that was posted by me.
And check out the T=Machine blog posts.

I hope it will give you some initial information to start with, and if you will have any more question, feel free to ask them!

One last suggestion, try not to think OOP, its hard, and most of the suggestions will look dumb to you (like comparing ES to RDBMS) but believe me the moment you will stop to think OOP, the system will look so simple and so modular to you!

Good luck! =)


ok just a quick question how do you store components with out OOP i have been trying to read about it but most people use a base abstract component class but i read that T=Machine post and it said not to use he some how stored all the data in arrays and accessed them with an id that the entity held.. could you explain how you are implementing this

Share this post


Link to post
Share on other sites
Quote:
Original post by Rainweaver
Hi,

Quote:

...because it is super hard to think in another way but ill try :)


http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html

Here's my slightly modified version; I found it funny, but then again, I have a strange sense of humour. Perhaps it won't make you giggle, but it'll make you see a subtle, important lesson:

Quote:

The venerable master Qc Na was walking with his student, Anton. Hoping to
prompt the master into a discussion, Anton said "Master, I have heard that
oop is a very good thing - is this true?" Qc Na looked pityingly at
his student and replied, "Foolish pupil - oop is merely a poor man's
component-based system."

Chastised, Anton took his leave from his master and returned to his cell,
intent on studying entity systems. He carefully read the entire "Gamedev.net" series of threads and its cousins, and implemented a small
component-based system with no oop. He learned much, and
looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that oop is truly a poor man's component-based system." Qc Na responded by hitting
Anton with his stick, saying "When will you learn? Component-based systems are poor man's
oop." At that moment, Anton became enlightened.

:)



Once you have to deal with (de)serialization, efficient message passing, object pooling to go easy with allocations etc, you'll realize that even T4 (boring code generation!) is an awesome tool.

Bottom line is: research component systems, but don't let them blind you with their shininess!



ooo shiny


thanks for that... i guess the grass is always greener on the other side :P and they are shiny lol

Share this post


Link to post
Share on other sites
This is a somewhat broad and popular topic. There is not the "One Way" to make a component system work. But generally they are quite "OOP" because composition and single responsibility principle are among the basics of OOP design. You have a whole bunch of choices ahead of you:

In some systems components are owned by entity objects and updated on a per-entity basis, in other systems the entity is simply an ID and components are updated by component "managers" which hold an array of all instances of a given component type.

In some systems components own their own data, in other systems entities own all data, and in yet other systems it's a mix of both. The data itself can be a static blackboard (bunch of member variables optionally packed into their own structure) or a dynamic blackboard (stores any number of different variables with a key association).

In some systems components store pointers to other components they collaborate with, in other systems components communicate over a message bus without knowing anything about what other components exist.

In some systems components have an elaborate interface, in other systems they only export an "onUpdate" and an "onMessage" method.

I think a good way to think about components is as "users" of other systems. For instance, a rendering component typically does not render anything, it simply passes along some data to be rendered later by the rendering system. A collision component does not check for collisions, it simply updates the collision info used by the physics system.

Share this post


Link to post
Share on other sites
Quote:
Original post by lightbringer

I think a good way to think about components is as "users" of other systems. For instance, a rendering component typically does not render anything, it simply passes along some data to be rendered later by the rendering system. A collision component does not check for collisions, it simply updates the collision info used by the physics system.



wow that may have been the most usefull thing i have heard yet.. thanks and thanks to all others who helped and will help in the future :)

Share this post


Link to post
Share on other sites
Some people say Entity systems are so much better than OOP, but for the life of me I can't see the difference between them and the OOP Compositor Design pattern. Maybe I'm just missing something...

Share this post


Link to post
Share on other sites
Quote:
Original post by Echkard
Some people say Entity systems are so much better than OOP, but for the life of me I can't see the difference between them and the OOP Compositor Design pattern. Maybe I'm just missing something...


My understanding is that it basically IS OOP, and that what everyone's comparing it to is not OOP per se, but traditional inheritance-based OO design.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!