@Bobby_Anguelov 2. My main concern with the MCPT combined with a flat entity model is that you lose cohesion of the concept "head", "arm", etc. E.g.: A backpack is rarely only a mesh, but often more info - how/where do you store this? How do I get all "backpack" components from the flat entity?
@Bobby_Anguelov Thanks for taking the time to do a follow up!
Two questions, on the Character Setups slide (around 5:30):
1. The multiple-component-per-type also seems to imply that you allow attaching components to components (the hierarchy), is that correct?
@Bobby_Anguelov@ajmmertens And thus far more robust implementation when working with programmers of varying expertise.
IMHO it's far easier to explain a link-based granular entity approach than a heavy one. (although again, I do agree on the benefits that it brings w.r.t. multi-threading)
@Bobby_Anguelov@ajmmertens Definitely looking forward to having a conversation on this, and I think it'll help to come at it with real world examples from both sides.
For us, the primary benefit was the flexibility it gave in terms of iteration and design.
@Bobby_Anguelov@ajmmertens Note, I do acknowledge the strength that argumentation gives you. But I disagree that the mere existance of links will immediately give any programmer a significant mental burden (enforcing data locality in these situations IMHO gives more through an overloaded fat model)
@Bobby_Anguelov@ajmmertens I haven't found the need yet to hard-enforce that no links between entities exists in these situations. Yes, cycles are theoretically an issue, but practically there wasn't a single case where we want both support for a cycle and logic iteration that was multithreadable.
@Bobby_Anguelov@ajmmertens Note that I'm squarely in the camp of separating it out as much as possible precisely to keep it simple. Interestingly the inventory problem you presented is one we implemented in Xenonauts 2 in ECS fashion as well.
@Bobby_Anguelov@ajmmertens IMHO, this only works as long as all the entities you are collating into one are trivial in the information they represent. The moment more info needs to be attached to them, they'd be better served as separate entities (complexity wise, loading wise).
@Bobby_Anguelov@ajmmertens Which IMHO doesn't seem to be an ECS vs GOC vs OOP discussion. It would help though if you would model the problem in another domain (per example OOP) to help it become more clear whether that is the issue, or whether I'm misinterpreting it.
@Bobby_Anguelov@ajmmertens I meant pretty much any other model, pick your poison. Your argument seems to be more between collating models into one (single entity) under the header of data locality versus separating the information over multiple entities.
@Bobby_Anguelov@ajmmertens Watched your talk, read the blog post and reading the threads here now. Could you expand on how this is any different from traditional OOP according to you? (I assume that the items, attachments etc still would use distinct objects so you'd end up with 30 objects there as well)
A good milestone in any project :-) #indiedev#gamedev#madewithunity@junkdogAP Made with the Entity framework we discussed! https://t.co/Na6XTR4CKZ https://t.co/Na6XTR4CKZ