[Archetypes] preset component fields

[DaanVanYperen]

Here's some observations after eating the dogfood. I'm certainly seeing the benefits of Archetypes on the horizon! They'll add a lot of value when initialization of entities is in.

Right now it's leads to a bit of verbose, error prone and unnecessarily spread out process though, since as an end user you need to specify all the components off-site, and it's easy to forget a component and try to set values for it afterwards.

This specific ticket is very high on my wish list. Adding this and the convenience methods from entitymanager will add the most value to Archetypes for me.

[junkdog]

I think I have a design in mind which should work; shouldn't be more than a day's worth of work (+ some time for polish). I'll run the design by you before i start, sometime tomorrow.

[snorrees]

My impression from all this Archtype stuff: Creating entities for maximum throughput is now a two step process - first create the archetype with required components, second initialize the entity via mappers.

So any (mine ;)) entity-factory which today rely on edit.create will have to be chopped up to support this; create the archetype once, initialize entities created with archetype via mappers instead of edit.create. Is that correct?

[DaanVanYperen]

So any (mine ;)) entity-factory which today rely on edit.create will have to be chopped up to support this; create the archetype once, initialize entities created with archetype via mappers instead of edit.create. Is that correct?

Basically, though 0.7.0 just introduces the scaffolding for Archetypes. I wouldn't convert legacy factories until some more of the archetype tickets have been completed.

Edit: mainly because it becomes a bit messy right now.

[junkdog]

I'll try to write up my API idea before going to bed, so that anyone can chime in before I start implementing it tomorrow; the goal is to produce something which is flexible, with a minimum of boilerplate (ie; less code than today + fluent interface) without sacrificing performance.

[junkdog]

Hopefully, preset + params will be covered with what i have in mind. Similar to how EntityBuilder works, but strongly typed.

[DaanVanYperen]

Hopefully, preset + params will be covered with what i have in mind. Similar to how EntityBuilder works, but strongly typed.

I'll give you a :cookie if there's some fallback to feed archetype builders pojo primitive field components, so I can load them with json without having to write loads and loads of adapter code ;)

[junkdog]

How about consuming the json directly? On Sep 26, 2014 3:22 PM, "Daan van Yperen" notifications@github.com wrote:

Hopefully, preset + params will be covered with what i have in mind. Similar to how EntityBuilder works, but strongly typed.

I'll give you a :cookie if there's some fallback to feed archetype builders pojo primitive field components, so I can load them with json without having to write loads and loads of adapter code ;)

— Reply to this email directly or view it on GitHub https://github.com/junkdog/artemis-odb/issues/166#issuecomment-56960219.

[snorrees]

I'm a lifedeprived xml-consumer O_O I'll leave things as is for now, and do the archetypes for the next project.

[junkdog]

Filthy and perverse... (consuming xml or json wouldn't make much of a difference though, it'd be trivial to add xml support) On Sep 26, 2014 3:31 PM, "snorrees" notifications@github.com wrote:

I'm a lifedeprived xml-consumer O_O I'll leave things as is for now, and do the archetypes for the next project.

— Reply to this email directly or view it on GitHub https://github.com/junkdog/artemis-odb/issues/166#issuecomment-56961330.

[DaanVanYperen]

How about consuming the json directly?

Could work. That would standardize it at the cost of flexibility on the end user side though. For me personally I'd want to expand the serialization with other things, like hierarchical assembly of multiple archetypes, archetypes composed out of multiple superarchetypes.

[DaanVanYperen]

That's not to say Artemis can't provide a stock load strategy. Would just be cool if we can swap in our own as well.

[snorrees]

I have inheritance built into the xml-dsl. Just give me an archtype/entity assembly api, and I'll be happy.

Or more concrete: I define all entity definitions in a data-file. Data-fields have their own semantics for easy inheritance/randomization ( -> 5 + rand(3) + 1 * parentLifetime -> feel free to sue me).

The data is loaded into an entity-template which defines EntityAttributes for all component types. These types are reflectively instantiated, with default ect annotated on the fields. The attributes are removed from the template if it is missing in the input-data. Inheritance is supported via , and if the entity-template is missing an entityattribute, and an entity-template in the inheritance-list contains it, the template will simply refer to the template attribute.

When i call template.create() an entity is created, it is passed to all the active entityAttributes, which each have the responsibility of creating and instantiating relevant components for the given attribute. Originally (pre-odb) i used the enable/disable feature and an per-template entity pool (very messy). Now I use edit.create, where odb does the pooling. Much, much better.

If I have to refactor into creating archtypes on template load, and use mappers/parameterizer when instantiating components, it wouldn't be THAT big of a change.

[junkdog]

Just to clarify; serialization is coming in a later release.

Having the freedom to write custom strategies is pretty much required. Might start off with a single stock one though (json).

Not sure how much freedom they'll provide, but it should aim to match the full API. On Sep 26, 2014 3:49 PM, "snorrees" notifications@github.com wrote:

I have inheritance built into the xml-dsl. Just give me an archtype/entity assembly api, and I'll be happy.

Or more concrete: I define all entity definitions in a data-file. Data-fields have their own semantics for easy inheritance/randomization ( -> 5 + rand(3) + 1 * parentLifetime -> feel free to sue me).

The data is loaded into an entity-template which defines EntityAttributes for all component types. These types are reflectively instantiated, with default ect annotated on the fields. The attributes are removed from the template if it is missing in the input-data. Inheritance is supported via , and if the entity-template is missing an entityattribute, and an entity-template in the inheritance-list contains it, the template will simply refer to the template attribute.

When i call template.create() an entity is created, it is passed to all the active entityAttributes, which each have the responsibility of creating and instantiating relevant components for the given attribute. Originally (pre-odb) i used the enable/disable feature and an per-template entity pool (very messy). Now I use edit.create.

If I have to refactor into creating archtypes on template load, and use mappers/parameterizer when instantiating components, it wouldn't be THAT big of a change.

— Reply to this email directly or view it on GitHub https://github.com/junkdog/artemis-odb/issues/166#issuecomment-56963512.

[junkdog]

Crap, running low on batteries. 4% left. Shitty nexus. On Sep 26, 2014 3:57 PM, "Adrian Papari" junkdog@angelhill.net wrote:

Just to clarify; serialization is coming in a later release.

Having the freedom to write custom strategies is pretty much required. Might start off with a single stock one though (json).

Not sure how much freedom they'll provide, but it should aim to match the full API. On Sep 26, 2014 3:49 PM, "snorrees" notifications@github.com wrote:

I have inheritance built into the xml-dsl. Just give me an archtype/entity assembly api, and I'll be happy.

Or more concrete: I define all entity definitions in a data-file. Data-fields have their own semantics for easy inheritance/randomization ( -> 5 + rand(3) + 1 * parentLifetime -> feel free to sue me).

The data is loaded into an entity-template which defines EntityAttributes for all component types. These types are reflectively instantiated, with default ect annotated on the fields. The attributes are removed from the template if it is missing in the input-data. Inheritance is supported via , and if the entity-template is missing an entityattribute, and an entity-template in the inheritance-list contains it, the template will simply refer to the template attribute.

When i call template.create() an entity is created, it is passed to all the active entityAttributes, which each have the responsibility of creating and instantiating relevant components for the given attribute. Originally (pre-odb) i used the enable/disable feature and an per-template entity pool (very messy). Now I use edit.create.

If I have to refactor into creating archtypes on template load, and use mappers/parameterizer when instantiating components, it wouldn't be THAT big of a change.

— Reply to this email directly or view it on GitHub https://github.com/junkdog/artemis-odb/issues/166#issuecomment-56963512 .

[junkdog]

Diffs is another important feature, esp for level editors. On Sep 26, 2014 3:49 PM, "snorrees" notifications@github.com wrote:

I have inheritance built into the xml-dsl. Just give me an archtype/entity assembly api, and I'll be happy.

Or more concrete: I define all entity definitions in a data-file. Data-fields have their own semantics for easy inheritance/randomization ( -> 5 + rand(3) + 1 * parentLifetime -> feel free to sue me).

The data is loaded into an entity-template which defines EntityAttributes for all component types. These types are reflectively instantiated, with default ect annotated on the fields. The attributes are removed from the template if it is missing in the input-data. Inheritance is supported via , and if the entity-template is missing an entityattribute, and an entity-template in the inheritance-list contains it, the template will simply refer to the template attribute.

When i call template.create() an entity is created, it is passed to all the active entityAttributes, which each have the responsibility of creating and instantiating relevant components for the given attribute. Originally (pre-odb) i used the enable/disable feature and an per-template entity pool (very messy). Now I use edit.create.

If I have to refactor into creating archtypes on template load, and use mappers/parameterizer when instantiating components, it wouldn't be THAT big of a change.

— Reply to this email directly or view it on GitHub https://github.com/junkdog/artemis-odb/issues/166#issuecomment-56963512.

[junkdog]

Ugh, began mocking some code, but I'll have to continue tomorrow. Time to retreat.

[JesseTG]

Are Archetypes useful at all if I already load my game entities from a file?

[DaanVanYperen]

Depends if you are talking about having your game state serialized or having your own template system. There's a performance benefit instancing entities from archetypes.

[JesseTG]

In my particular game, I don't care about saving entities to files. Data like high scores, sure, but I handle that separately. I'm only talking about loading entities. I did this before Archetypes were introduced.

[junkdog]

Covering this in #160.

Are Archetypes useful at all if I already load my game entities from a file?

Not unless you're having some sort of archetype-like concept (like "enemey01", "star" etc), but better wait until #160 get completed.

edit: Closing this as it'll be covered by the issue mentioned above.

[junkdog]

Updated #160 with suggestion