Couldn’t the “TrollTransform” System do the following:
1) Create a new “TransformedTroll” Component, which has troll-data as well as an empty list of the blocked Components.
2) Remove all the mage’s Components that should be blocked, moving them to the “TransformedTroll” Component’s list of blocked Components.
3) Apply the “TransformedTroll” Component to the mage.

Then the System that eventually cancels (removes) the “TransformedTroll” Component would reapply the removed Components, which it would have access to through the “TransformedTroll” Component. In essence, the removed Components are just blocked (unseen by the Entity & Systems that would use them), and treated as data as part of the “TransformedTroll” Component.

Only downside that immediately pops out at me is that two Systems rely on one another in this example, unless there was a clean way to do it in a single system… I can think of an easy way off the top of my head, but it seems like a hack:

When the mage is to be turned into a troll, simply apply the “TransformedTroll” component with a boolean data flag marking that it has yet to change. The “TrollTransform” System would depend on this one component, and could handle both stages of the troll: transform into troll and transform back to normal.

Comments/opinions/criticism welcome.

—–in the game class—–

private var _resortLayers:ResortLayers = new ResortLayers(); //ResortLayers is a signal the same as Render/Update etc..

override protected function startUp():void
{
var renderNodes:IFamily = entityManager.getEntityFamily(RendererNode);
renderNodes.entityAdded.add(renderableEntityAdded);

injector.mapValue(ResortLayers, _resortLayers);
}

private function renderableEntityAdded(renderNode:RendererNode):void
{
_resortLayers.dispatch();
}

//! there will also need to be a dispatch sent for when an entity changes its layer depth and when an entity is removed.

—–in the rendering & sorting system—–
public class RenderSystem implements ISystem
{
[Inject]
public var render:Render;

[Inject]
public var resortLayers:ResortLayers;

private var _sort:Array = [];

public function onRegister():void
{
render.add(onRender);
resortLayers.add(onResortLayers);
resortLayers.dispatch(); //without this the array will stay empty if the system is created after the last entity.
}

public function onResortLayers():void
{
_sort = [];
for (_renderNodes.start(); _renderNodes.hasNext; _renderNodes.next())
{
_sort.push(_renderNodes.currentNode);
}
_sort.sortOn(“layer”);
}

public function onRender():void
{
for (var i:int = 0; i < _sort.length; i++) //maybe this is actually faster than using the _renderNodes access methods anyway?
{
node = _sort[i];
//the usual….
}
}
}

—–change to give renderNode a property to sort on—–

public class RendererNode extends Node
{
public static const componentClasses:Array = [SpacialComponent, GraphicComponent];

public var spacialComponent:SpacialComponent;
public var graphicComponent:GraphicComponent;

public function get layer():int
{
return graphicComponent.layer; //graphics can now have their rendering order changed with an added layer property.
}

public function RendererNode(entityID:String, components:Dictionary)
{
super(entityID, components);
spacialComponent = components[SpacialComponent];
graphicComponent = components[GraphicComponent];
}
}

I came up with some not so optimal solutions, so I was wondering if the next iteration of ember has a solution built in, or whether there is a clean way to sort nodes.

My solution involved having an array in the render system which contained the rendernodes and can be signalled to update/re-sort when a rendernode is added/removed. – its obviously a bit hacky and defeats the purpose of the system.

override protected function mapInjectors():void{
injector.mapValue(EntityManager, entityManager);
super.mapInjectors();
}

to SpeedTestGame.as of the bunny demo

Ill probably hold of on too much more blind fiddling in eager anticipation of the updates now.

I think its a great system so far.
thanks.

Error: Injector is missing a rule to handle injection into target [object RenderSystem]. Target dependency: com.tomseysdavies.ember.base::EntityManager

ill go through the swiftsuspenders/robotlegs docs since im new to dependency injection, but is there any possibility of getting a complete working demo, or a hint to fix the problem.

After reading up on the entity system approach, im thinking its worthwhile using it for a game engine im working on now, since its rendering code would be interchangable/easier to replace with future gpu enhanced methods etc. in theory anyway, id like to keep that door as open as I can.

-Jayden

thanks for the info. Nice presentation . I’ll check your blog at a later time for updates. Good luck with your stuff.

- Plamen

In the bunny demo’s there are examples of inter-system-communication. In the game context we map a signal class like this

injector.mapSingleton(Tick);

then we can inject it into a system needed

[Inject]public var tick:Tick;

Simple as that. Not much progress on the engine at the moment im afraid. Im over busy with other work but hopefully I will get a chance later this year.

Tom