Managers

[Michael Cann]

A little while ago I introduced the concept of managers into Swft as a way to manage collections of Entities. 

PBE has a concept of managers, except in PBE everything are entities so that a manager just becomes another component on an entity. Now this is were im not sure about. My personal preference is that Entities should be the actors in your game. They can move about interact with each other, render (or not), collide (or not) things like that. They have a number of components that they 'manage', they listen for events, and call actions on them.

Then there are the managers that look after the entities, their creation / destruction and other actions that can be applied to those groups. 

So that the relationship looks something like this:

(https://cacoo.com/diagrams/t4WNlqoSojM7Wv1C)

This way, it seems to me you get a better cleaner distinction of the various roles of the different class types, rather than making absolutely everything a component or an entity.

Having said that there are issues with this. 

For example with the BloonBlaster prototype game I have the situation with the WindManager class

http://github.com/mikecann/Swift-Examples/blob/master/BloonBlaster/src/co/uk/swft/bblaster/mangers/WindManager.as

This is a tricky one. As its not exactly managing a group of entities rather its looking after a certain knot of functionality. It contains the wind direction that is used by the balloon entities to determine which direction to move about in. Every so often the wind changes direction and so the balloons move too. 

So, where do you put this code then? Is it an entity? Is it a manager? Or is it neither?

Im not too sure on this one. It obviously needs to listen for updates, so for this reason it may be wiser to make it a component, so it can listen for updates like the rest of the updateable components. But then again it needs to be accessible for the Balloons (and anything else that needs wind). Also by my previous definition it isn't strictly an entity as it doesnt really exist anywhere or need to be managed by anything rather just a lone component that is happy to do its job and have its properties accessed.

Anyone else have any thoughts on this one?

--
Mike Cann
http://www.mikecann.co.uk/
http://www.artificialgames.co.uk/

[Jos Yule]

Hello.

The wind itself _could_ be considered an Entity, no? Can entities have other entities injected (be dependant on) into them?

If that kind of composition is not ideal, then i'd say the Wind is a component (model), which is a singleton which is injected into each entity.

This might work for this particular example, i don't know if it is a general solution to "game wide" data...

j

[Michael Cann]

HI Jos,

My thinking at the moment is in the RobotLegs like arena. So in my thoughts in RL you have Actors (Proxys) that 'manage' VO's and properties and expose methods for modification to those VOs and properties. In Swft we have Managers that contain entities and properties and expose methods for modification to those entities and properties.

I suppose it would be possible to have singleton entities and the like so they can be injected into other entities, tho I wonder if it would not be better just to have the managers and singletons then expose the entity through an accessor there. So for example, rather than having a singleton Player entity, you would have a player manager entity with a "player" property which would be the player entity.

I think this gives a nice separation. So components are concerned about thier data and other components data. Entities are concerned about the components and their events. Managers are concerned about the entities they manage.

Thoughts?

Mike