Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualsmr

Posted 03 January 2013 - 05:04 PM

Right. Do what makes sense.

 

But I wonder what benefits there would be to implementing your UI elements as entities. I would think that UI elements are not a part of the game simulation, thus wouldn't be represented by entities within that simulation.

 

As far as your question about "traditional classes," component/entity systems /are/ traditional classes. They're just a specific way of organizing your relationships between classes. In my opinion if you implement OOP in the manner intended, most of your programs will tend to look like entity component systems in that you avoid deep hierarchies, keep classes small and single-purpose, etc.


#2smr

Posted 03 January 2013 - 05:01 PM

Right. Do what makes sense.

 

But I wonder what benefits there would be to implementing your UI elements as entities. I would think that UI elements are not a part of the game simulation, thus wouldn't be represented by entities within that simulation.

 

As far as your question about "traditional classes," component/entity systems /are/ traditional classes. They're just a specific way of organizing your relationships between classes. In my opinion if you implement OOP in the manner intended, most of your programs will tend to look like entity component systems.


#1smr

Posted 03 January 2013 - 05:00 PM

Right. Do what makes sense.

 

But I wonder what benefits there would be to implementing your UI elements as entities. I would think that UI elements are not a part of the game simulation, thus wouldn't be represented by entities within that simulation.

 

As far as your question about "traditional classes," component/entity systems /are/ traditional classes. They're just a specific way of organizing your relationships between classes. In my opinion if you implement OOP in the manner intended, most of your classes and will tend to look like entity component systems.


PARTNERS