What is the best way to dynamically parameterize an archtype

[junkdog]

@snorrees wrote (#104):

What is the best way to dynamically parameterize an archtype, would you say? EntityFactory is too explicit for my usecase in that it requires one class per entity-type.

What I'm thinking of creating, but please stop me if this is dumb:

• On load time create archetypes based on data.
• Todo/is this ok?: Create ArchtypeParameterizer based on data. The Parameterizer holds a list of Components found in the archetype, and one ComponentParameterizer per Component.
• Create entities by name->archtype -> entity without parameters
• Use ComponentParameterizers in ArchtypeParameterizer to init each component in the created entity.

(I need to optimize this:)

[junkdog]

At work atm, so a little short on time, but how many unique component compositions do you have? The EntityCompositionTracker may help in collecting that data.

I'll post a more through reply after work.

PS. Looking good :+1:

[snorrees]

Swift replay!

I'm basically reading my entity-templates from an xml-file, so the compositions can be many and varied. Let me try to explain what I'm trying to achieve.

How it is today:

Data-load

• Read entity-template-xml into a EntityTemplate-class.

• EntityTemplate is composite of component-classes. Each component-class is reflectively linked to xml-child-elements of the template-element. If an xml-component is present, populate value-providers inside the component-class (xml-attributes on the child element with some special syntax) .

  Runtime

• When EntityTemplate.createEntity(...) is called, an entity is is created by Artemis.
• Pass entity, along with entity.edit(), to each active component-class.
• Add and initialize whatever artemis-components it needs. Typically edit.create(WhateverComponent).init(params...);
• End result: Parameterized entity.

This seems to be slow, as I have alot of abstractions, I'm not using Archetype and there is alot of redundant checking of values in the component-classes.

Here is what I'm thinking:

Data-load

• Read xml as before, retaining my EntityTemplate with ComponentClasses.
• Create an archetypebuilder per EntityTemplate , and pass into each Component-class during data read.
• Add whatever artemis components are needed. Populate an ArchetypeParametrizer with the same components.

Runtime

• When calling EntityTemplate.createEntity(), use the now fully popluated archetypebuilder and create the entity. Iterate over all Compoent-classes calling init(entity).
• ComponentClass.init(entity) uses mappers to retrieve relevant components and call init(dataProviderValues...)

Sorry for rambling, but does this sound at all like a good idea?

[snorrees]

Just to be clear: All I'm looking for here is a "sure, go ahead and try" or a "no, this is not how archetypes work/are supposed to be used". No work required on your end. I'm asking, because the rewrite will probably bind up my "evening dev time" a little bit.

In other news, I curse myself for not trying out the @Profile annotation before. Its super useful! With a little regex and a shaperenderer I finally have live profiling! YAY THANKS! (This could probably go out in a separate repo after some code-cleanup if there is any intrest).

[junkdog]

Hi, short answer: yes, wrapping an Archetype per EntityTemplate would be faster than manually adding the components to a blank Entity.

The perf gain only applies to creation (EntityObserver#added) at the moment; adding/removing a component to a newly created entity voids the performance gain - so make sure that the EntityTemplate's Archetype represents the fully composed Entity.

The technical bits (it's spread out over a number of closed issues, but don't necessarily agree 100% with the actual implementation, so here's the updated version):

• EntityEdit contains a bitset representation of all components belonging to the edited entity; when the EntityEdits are processed by the world, each component bitset is simplified to a compositionId (a simple int).
• In turn, EntitySystems maintain a cache of which compositionIds are of interest - thereby avoiding matching the component bitset against the entity system's aspect (3 bitsets).
  • All ES compositionId caches are updated each time artemis encounters a new compositionId.
• Since Archetypes know which components make up the entity, the compositionId only needs to be calculated when the archetype is first created, hence forgoing the bitset->compositionId lookup.

Entity Transmuters (#208) aims to do for existing Entities what Archetypes do for created entities, but it's still some time away, but hopefully 0.9.0 will happen sometime during the first half of December (winter is taking its toll on programming, blergh....).

[junkdog]

Glad someone is using @Profile btw ;) It's mostly been sitting there, I think it needs a little more documentation (+ maybe some premade examples) for others to embrace it - I intend to add a few profilers to artemis-odb-contrib, but I need to tidy mine up.

[junkdog]

Submitted my comment too soon.

(This could probably go out in a separate repo after some code-cleanup if there is any intrest).

Absolutely, I suggest artemis-odb-contrib, or a separate repo.

[snorrees]

Superb :) I'll do the refactor and get back to you with the results. It will be a chance to cache additional logic at loadtime as well, so I hope for a significant improvement.

Those graphs where pretty! Are they rendered in a shader, or is there bloom-postprocessing going on? Judging by the spirit-creature there is ;) I'm currently just doing a slow libgdx shape-renderer for my lines, but the fadeout is a nice touch. Per sample-line darken?

As for the actutal profiler, I ended up with a static list of profilers of the same class, which add themselves on initialize. Perhaps not defacto-clean code/testable, but it worked fine.

[Namek]

Hey, @junkdog that looks very inspiring! Is this some kind of attractor? Does it animate? Also, both your and @snorrees profiling remind me of lagometer in Quake 3. Quite promising.

Sorry for total offtop.

[junkdog]

Those graphs where pretty! Are they rendered in a shader, or is there bloom-postprocessing going on? Judging by the spirit-creature there is ;) I'm currently just doing a slow libgdx shape-renderer for my lines, but the fadeout is a nice touch. Per sample-line darken?

Yup, it's a custom, but simplistic shader; iirc, much of the color data etc was massaged on the CPU. I was previously abusing glLineWidth to produce something similar to antialiasing; but I should probably do it properly this time.

Hey, @junkdog that looks very inspiring! Is this some kind of attractor? Does it animate?

Thanks :) It's my pet project; pretty much a sink for all things interesting that don't fit into other projects. The entities are a combination of sine and bezier curves wrapped in an FSM which can interpolate between states (so yes, everything is animated, including a breathing-like effect). Haven't had much time to work on it recently though.