Add parallelization of systems

[rennomarcus]

Is your feature request related to a problem? Please describe.
Go is a powerful language and it makes it very easy to use threads with go routines.

The ECS architecture makes it very easy to parallelize. We just need to be careful with dependencies between systems.

Describe the solution you'd like
Use go routines in gameloop.
Just need to be careful with maps in Go since they are not thread safe.

It was created sync.Map a while ago that could help. Otherwise, use sync.Mutex to protect the components map.

Some questions that might help you to describe the feature

1. Why is this change important?
   So we can use all cores of the computer
2. Will this break old releases?
   It shouldn't
3. What part of the code would be affected?
   game loop

[rennomarcus]

Won't add this for now, because the performance in the demo game (crazy bird) got worst in almost all the implementations I've tried. The map data structure is not thread safe (aka goroutine), so some work has to be done to work around this problem.

I'll leave this open for a few reasons: 1) to keep in my head for the future (if I learn something on this topic, I will do something about this); 2) if someone else has any interesting in tackling this problem

Approaches I've tried and that failed:

1. Adding the new sync.Map instead of using regular map
2. Adding sync.Mutex in gameloop (this didn't make much sense... this would basically stop the parallelization)
3. Adding sync.Mutex in the Entity structure to handle AddComponent and GetComponent

In all the three solutions above the overhead of the Mutex was far too costly.

4. Changing the map[string]Component to a list. This solution actually worked great. I might change this in the future, but for now since the game I made was simple and I have no idea if other games are being done that require more complexity. Even if implemented, this shouldn't cause any break in the current game code. The main problem (and the reason I won't change it for now) is because if the entity has too many components the reading time can increase significantly in some cases, because we could go through the whole list comparing the component types. In the worst case scenario this would be O(n). A regular list is not really suited for this.