Resolves 5 - Entity Component System

[smudge202]

Some basics added for the Entity Component System.

For the time being, I've assumed Components can be assigned to different instances of an entity (so state management is instance based for entities).

However, only one Component of a given type can be assigned (Type based, not instance). I can't really explain why I thought the inconsistency was a good idea, other than I had a hunch. Personally, I would rather Components are responsible for their own Aggregation than having the State engine try to handle it.

This also provides some foundations as per #2 . The TFM's are subject to change, but I believe netcore50 is accessible to UAP10 (I'll confirm this at some stage), making us compatible with the Universal Windows Platform.

We're on the latest stable DNX dependencies (beta 7) but beta 8 is due for release; we'll cross that bridge when it arrives.

//cc @herecydev @sblackler @danielcirket @mattridgway

^ let me know if anyone should be added or would prefer to be removed from cc lists on this repo.

Also... win a t-shirt! https://hacktoberfest.digitalocean.com/

[smudge202]

Latest update addresses (I believe) everything mentioned except the redundant .gitattributes which I could care less about. :)

I've changed the API to a more consistent Assign/Get approach (with no exceptions being thrown anywhere).

@herecydev You had a comment about the Get (previously StateFor) performing a GetOrAdd. I originally started writing out a lengthy description about why I hadn't followed your suggestion, but the more I discussed it with myself in this comment, the more I changed my mind. I think with the c#6 null propagation (elvis) there should be no harm done. For example:

// previous API
var singleComponent = _components.Get(entity).Get<Component>();
// ^ had the side effect of adding a state for the entity if it had no components

// new API
var singleComponent = _components.Get(entity)?.Get<Component>();
// ^ requires elvis for the entity state, but no longer has side effects. 
// Awesome trade off in my opinion (if elvis wasn't about I'd be dubious)

[smudge202]

Now includes the Unassign/Remove methods mentioned in #5 .

[herecydev]

Not sure If I still agree. I feel Get should only be used for retrieving. The unknown Add in the implementation just isn't reflected in the API in my opinion, producing a side effect of adding. My suggestion would be to call the method GetOrAdd.

To me the null propagation has no impact here. You're only asserting that the first Get could return null, which is fine. That doesn't mitigate the side effect above.

Thoughts?

[smudge202]

@herecydev did I get drunk on relentless or did you not check the code? I thought the new implementation was side effect free?

[herecydev]

@smudge202 totally didn't read!

[ghost]

:shipit: