Put together an experimental component system (Style is closer to that of an Entity System) for haXe over the last few days. I've had the idea for a while now, but never found a way to implement it. Once again, haXe macros save the day. The goal is to maintain the flexibility of a component system, while reducing the performance loss of messaging and component communication.
I'm a bit limited on time today, so no detailed post. Just a bit of code and a demo.
Demo:
The main application code:
Components:
Systems:
what is "EACH" and "HAS" ???
ReplyDeleteEACH(identifier,{...block...}) is responsible for delegating entities to the system. It will loop through all the entities that contain components you access within the code block.
ReplyDelete[handle].[component].[property]
entity.CVelocity.vy
The GravitySystem for example is delegated all entities containing CVelocity.
HAS functions much like an if statement, but causes no branching, and no conditionals.
HAS([Component],{..true..},{..false..})
Looks somewhat similar to my Composure library (https://github.com/TomByrne/composure-hx).
ReplyDeleteI love the implicit way everything is bound together.
Do the Entities add themselves to the System?
Systems do not maintain lists of entities. All entities are grouped by structure, and then each buffer of identical structures (entities) are sent to systems that want that particular set of data.
DeleteThere is no cost for fetching a "component", and it's very cache friendly.
However, it pays heavily during modification of entity structure (add/remove component). There is also no way to point to an entity in memory. It has some disadvantages.