systems do not hold component data, but only system states systems cannot be injected systems are SRP and OCP systems communicates between component, mediators, producer/consumer, observers. producer/consumer and observers must be defined in the layer of the engine. systems can have injected dependencies components don't have logic components can have only getter and setter components cannot define patterns that requires logic. components cannot issues commands High Cohesion[edit] Main article: Cohesion (computer science) High Cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable and understandable. High cohesion is generally used in support of Low Coupling. High cohesion means that the responsibilities of a given element are strongly related and highly focused. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system. Alternatively, low cohesion is a situation in which a given element has too many unrelated responsibilities. Elements with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to maintain and averse to change.[3] Low Coupling[edit] Main article: Loose coupling Low Coupling is an evaluative pattern, which dictates how to assign responsibilities to support: lower dependency between the classes, change in one class having lower impact on other classes, higher reuse potential. events, observers and mediators have the inconvience to hold the reference to the engine, which forces to use cleanup if the engine must be removed. Observers are easy to clean up from the engine. Mediators needs to be integrated to the framework to be simple to clean up. Component events need the clean up function. producer/consumer has the inconvienent to force check the number of jobs available everyframe Engine can't be removed, they can only be disabled, but the logic of disabling must be handled by the engine itself Should components have just one element? Should engines use just nodes? Components are ditacted by the entities and Nodes by the engines http://thelinuxlich.github.io/artemis_CSharp/ differences: components no events, everthing must be update give more responsabiltiy to the user, semplicity https://github.com/sschmid/Entitas-CSharp/wiki/Overview no groups, no queries http://entity-systems.wikidot.com/es-articles http://www.ashframework.org/ it's very important to give a namespace to the engines. In this way it's impossible to create semantically wrong nodes (PlayerNode Vs TargetNode) ToDo: it's not safe to remove an engine without having called being denitialised internal states. A special ClearOnRemove function must be added for each engine namespace GameFramework.RayCast { public class RayCastEngineEngine { public RayCastEngine(RayCastEmployer jobList) { jobList.onJobassigned += OnRaycastRequested; } public void Add(IComponent obj) {} public void Remove(IComponent obj) {} void OnRaycastRequested(RayCastJob job) { RaycastHit shootHit; Physics.Raycast(job.rayVector, out shootHit, job.range, _enemyMask); job.Done(shootHit); } RayCastEmployer _employer; int _enemyMask; } public struct RayCastJob { readonly public Ray rayVector; readonly public float range; readonly public Action Done; public RayCastJob(Ray direction, float distance, Action OnDone) { rayVector = direction; range = distance; Done = OnDone; } } public class RayCastEmployer { public event Action onJobassigned; public void AssignJob(RayCastJob data, Action onJobdone) { onJobassigned(data); } } } if your code can be read as A tells B to do something is direct A register B event is indirect althoggh if B tells A something through event is direct again. B must say something like I don't know who you are, but this just happened. you say B.SomethingHappenedToMe() not B.YouMustDoThis(); un engine non deve mai avere concetti di un altro engine. dire all'engine sonoro suona morte � sbagliato. � l'engine death che triggera l'evento e l'engine sound ad ascoltarlo.