7 years ago · 01d015a770
--- a/ECS/note.txt
+++ b/ECS/note.txt
@@ -1,111 +0,0 @@
 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<RaycastHit> Done;

        public RayCastJob(Ray direction, float distance, Action<RaycastHit> OnDone)
        {
            rayVector = direction;
            range = distance;
            Done = OnDone;
        }
    }

    public class RayCastEmployer
    {
        public event Action<RayCastJob> onJobassigned;

        public void AssignJob(RayCastJob data, Action<RaycastHit> 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.