Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Framework Design Advice  (Read 9553 times)

0 Members and 1 Guest are viewing this topic.

lezebulon

  • Full Member
  • ***
  • Posts: 235
    • View Profile
Re: Framework Design Advice
« Reply #15 on: June 06, 2014, 12:36:33 am »
I assume with the 2D matrix you're referring to the setting where entities are columns and components are rows? Well, you needn't poll through all the entries and check whether they're there. An entity can hold a list of its components, so you only iterate through those that actually exist.
They it's exactly what I'm referring to. I think the original upside of the implementation is to be able to tell in constant time if a given entity has a given component, so it basically requires the entity to hold a bitset of the size of the total number of components possible (cf https://github.com/alecthomas/entityx).
Anyway I really don't understand the point of it all, except for prototyping maybe. You have a powerful language and you end up just structuring it such that all the elements are int, who hold a set of int, and the actual logic is just delayed "whenever". This really feels like it's "design for primary schoolers"

dabbertorres

  • Hero Member
  • *****
  • Posts: 505
    • View Profile
    • website/blog
Re: Framework Design Advice
« Reply #16 on: June 06, 2014, 04:03:19 am »
To continue the discussion, as I am interested, is there a different design(s) that you would suggest reading about?

Veritas

  • Jr. Member
  • **
  • Posts: 79
    • View Profile
    • Email
Re: Framework Design Advice
« Reply #17 on: June 06, 2014, 06:31:56 am »
I assume with the 2D matrix you're referring to the setting where entities are columns and components are rows? Well, you needn't poll through all the entries and check whether they're there. An entity can hold a list of its components, so you only iterate through those that actually exist.
They it's exactly what I'm referring to. I think the original upside of the implementation is to be able to tell in constant time if a given entity has a given component, so it basically requires the entity to hold a bitset of the size of the total number of components possible (cf https://github.com/alecthomas/entityx).
Anyway I really don't understand the point of it all, except for prototyping maybe. You have a powerful language and you end up just structuring it such that all the elements are int, who hold a set of int, and the actual logic is just delayed "whenever". This really feels like it's "design for primary schoolers"

While this is a common implementation, the entity-component system is not required to work that way. You could even use a hash map for the components. Personally I don't like the data-driven approach of some implementations, as long as performance is good enough I prefer a clean and intuitive design that allows for faster prototyping.

As for your last point, there are no dependencies between classes and so it provides good modularity and decoupling. Maintenance is also easier for the most part.
"Lasciate ogni speranza, voi ch'entrate"

select_this

  • Full Member
  • ***
  • Posts: 130
  • Current mood: just ate a pinecone
    • View Profile
    • darrenferrie.com
Re: Framework Design Advice
« Reply #18 on: June 06, 2014, 12:21:45 pm »
It's the age old problem of "when you have a hammer, everything looks like a nail". It seems to be a fairly common fallacy that a 'one size fits all' framework will be able to solve every problem you come across.

An interesting discussion, to be sure.
Follow me on Twitter, why don'tcha? @select_this

 

anything