Release 7

Author: HenrikPoulsen

.gitignore

@@ -31,3 +31,4 @@ TwoStickShooter/Pure/Library/AnnotationManager
 !PackageRepos/ECSJobDemos/UnstablePrototypes/Asteriods/Assets/Packages/Unity.Multiplayer/Plugins/gamesocket.native.pdb
 
 *.pyc
+StreamingAssets.meta

Documentation/content/ecs_concepts.md

@@ -1,26 +1,112 @@
 # ECS concepts
 
-If you are familiar with [Entity-component-system](https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system) (ECS) concepts, you might see the potential for naming conflicts with Unity's existing __GameObject__/__Component__ setup. Below is a list comparing how ECS concepts map to Unity's implementation:
+If you are familiar with [Entity-component-system](https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system) (ECS) concepts, you might see the potential for naming conflicts with Unity's existing __GameObject__/__Component__ setup. 
 
-### Entity → Entity
+The purpose of this page is:
+1. Clarify and disambiguate the concepts as used in the ECS.
+2. Provide a brief introduction to each concept as an entry point to a new user.
 
-Unity did not have an __Entity__ to begin with, so the structure is simply named after the concept. Entities are like super lightweight GameObjects, in that they don't do much on their own, and they don't store any data (not even a name!).
+### EntityManager
+Manages memory and structural changes.
 
-You can add Components to Entities; similar to how you add Components to GameObjects.
+### ComponentData
+Parallel streams of concrete, [blittable](https://docs.microsoft.com/en-us/dotnet/framework/interop/blittable-and-non-blittable-types) data. 
 
-### Component → ComponentData
+e.g.
 
-We are introducing a new high-performance ComponentType. 
+| Position | HitPoints |
+| ---------- | -----------|
+| 64,30 | 69 |
+| 58,55 | 70 |
+| 95,81 | 81 |
+| 10,50 | 19 |
+| 36,24 | 38 |
+| 67,33 | 40 |
 
-```
-struct MyComponent: IComponentData
-{} 
-```
+See: [IComponentData in detail](ecs_in_detail.md#icomponentdata)
+
+
+### Entity
+An ID which can be used for indirect component lookups for the purposes of graph traversal.
+
+e.g.
+
+| Entity | Position | HitPoints |
+|--- | ---------- | -----------|
+|0 | 64,30 | 69 |
+|1 | 58,55 | 70 |
+|2 | 95,81 | 81 |
+|3 | 10,50 | 19 |
+|4 | 36,24 | 38 |
+|5 | 67,33 | 40 |
+
+See: [Entity in detail](ecs_in_detail.md#entity)
+
+### SharedComponentData
+Type of ComponentData where each unique value is only stored once. ComponentData streams are divided into subsets by each value of all SharedComponentData.
+
+e.g. (Mesh SharedComponentData)
+
+__Mesh = RocketShip__
+
+| Position | HitPoints |
+| ---------- | -----------|
+| 64,30 | 69 |
+| 58,55 | 70 |
+| 95,81 | 81 |
+
+__Mesh = Bullet__
+
+| Position | HitPoints |
+| ---------- | -----------|
+| 10,50 | 19 |
+| 36,24 | 38 |
+| 67,33 | 40 |
+
+See: [SharedComponentData in detail](ecs_in_detail.md#shared-componentdata)
+
+### EntityArchetype
+Specific set of ComponentData types and SharedComponentData values which define the subsets of ComponentData streams stored in the EntityManager.
+
+e.g. In the above, there are two EntityArchetypes:
+1. Position, HitPoints, Mesh = RocketShip
+2. Position, HitPoints, Mesh = Bullet
+
+See: [EntityArchetype in detail](ecs_in_detail.md#entityarchetype)
+
+### ComponentSystem
+Where gameplay/system logic/behavior occurs.
+
+See: [ComponentSystem in detail](ecs_in_detail.md#componentsystem)
+
+### World
+A unique EntityManager with specific instances of defined ComponenetSystems. Multiple Worlds may exist and work on independent data sets.
+
+See: [World in detail](ecs_in_detail.md#world)
+
+### SystemStateComponentData
+A specific type of ComponentData which is not serialized or removed by default when an Entity ID is deleted. Used for internal state and resource management inside a system. Allows you to manage construction and destruction of resources.
+
+See: [SystemStateComponentData in detail](ecs_in_detail.md#systemstatecomponentdata)
+
+### JobComponentSystem
+A type of ComponentSystem where jobs are queued independently of the JobComponentSystem's update, in the background. Those jobs are guaranteed to be completed in the same order as the systems. 
+
+See: [JobComponentSystem in detail](ecs_in_detail.md#jobcomponentsystem)
+
+### EntityCommandBuffer
+A list of structural changes to the data in an EntityManager for later completion. Structural changes are:
+1. Adding Component
+2. Removing Component
+3. Changing SharedComponent value
+
+See: [EntityCommandBuffer in detail](ecs_in_detail.md#entitycommandbuffer)
+
+### Barrier
+A type of ComponentSystem, which provides an EntityCommandBuffer. i.e. A specific (synchronization) point in the frame where that EntityCommandBuffer will be resolved.
+
+See: [Barrier in detail](ecs_in_detail.md#barrier)
 
-The __EntityManager__ manages the memory and makes hard guarantees about linear memory access when iterating over a set of Components. It also has zero overhead on a per Entity basis beyond the size of the struct itself.
 
-In order to differentiate it from the existing component types (such as __MonoBehaviours__), the name refers directly to the fact that it only stores data. __ComponentData__ can be added and removed from Entities.
 
-### System → ComponentSystem
 
-There are a lot of "systems" in Unity, so the name includes the umbrella term, "component" as well. __ComponentSystems__ define your game's behavior, and can operate on several types of data: traditional GameObjects and Components, or pure ECS ComponentData and Entity structs.

Documentation/content/ecs_in_detail.md

@@ -419,6 +419,8 @@ As you can see, the API is very similar to the entity manager API. In this mode,
 
 Again let's look at the two stick shooter sample to see how this works in practice.
 
+### Barrier
+
 First, a barrier system is declared:
 
 ```cs
@@ -462,3 +464,5 @@ ECS ships with the __GameObjectEntity__ component. It is a MonoBehaviour. In __O
 TODO: what do you mean by "the GameObjectEntity component creates an Entity with all components on the GameObject" in the sentence above? do you mean all required components that this GameObject should have in that particular case? or is there a pre-defined set of components that will always be added? It's a little unclear.
 
 > Note: for the time being, you must add a GameObjectEntity component on each GameObject that you want to be visible / iterable from the ComponentSystem.
+
+## SystemStateComponentData

Documentation/content/job_system.md

@@ -210,15 +210,19 @@ public struct MyParallelJob : IJobParallelFor
 
 ```C#
 var jobData = new MyParallelJob();
-jobData.a = 10; 
-jobData.b = 10;
-jobData.result = result;
+jobData.a = new NativeArray<float>(new float[] { 1, 2, 3 }, Allocator.TempJob);
+jobData.b = new NativeArray<float>(new float[] { 6, 7, 8 }, Allocator.TempJob);
+jobData.result = new NativeArray<float>(3, Allocator.TempJob);
 
 // Schedule the job with one Execute per index in the results array and only 1 item per processing batch
-JobHandle handle = jobData.Schedule(result.Length, 1);
+JobHandle handle = jobData.Schedule(jobData.result.Length, 1);
 
 // Wait for the job to complete
 handle.Complete();
+
+jobData.a.Dispose();
+jobData.b.Dispose();
+jobData.result.Dispose();
 ```
 
 ## Job System tips and troubleshooting
@@ -239,4 +243,4 @@ Due to the lack of [ref returns](https://docs.microsoft.com/en-us/dotnet/csharp/
 
 ### Always call `JobHandle.Complete`
 
-Tracing data ownership requires dependencies to complete before the main thread can use them again. This means that it is not enough to check `JobHandle.IsDone`. You must call the method `JobHandle.Complete` to regain ownership of the `NativeContainers` to the main thread. Calling `Complete` also cleans up the state in the jobs debugger. Not doing so introduces a memory leak. This also applies if you schedule new jobs every frame that have a dependency on the previous frame's job.
+Tracing data ownership requires dependencies to complete before the main thread can use them again. This means that it is not enough to check `JobHandle.IsDone`. You must call the method `JobHandle.Complete` to regain ownership of the `NativeContainers` to the main thread. Calling `Complete` also cleans up the state in the jobs debugger. Not doing so introduces a memory leak. This also applies if you schedule new jobs every frame that have a dependency on the previous frame's job.

GalacticConquest/Assets/GalacticConquest.meta

@@ -0,0 +1,76 @@
+%YAML 1.1
+%TAG !u! tag:unity3d.com,2011:
+--- !u!21 &2100000
+Material:
+ serializedVersion: 6
+ m_ObjectHideFlags: 0
+ m_CorrespondingSourceObject: {fileID: 0}
+ m_PrefabInternal: {fileID: 0}
+ m_Name: Green
+ m_Shader: {fileID: 46, guid: 0000000000000000f000000000000000, type: 0}
+ m_ShaderKeywords: _GLOSSYREFLECTIONS_OFF _SPECULARHIGHLIGHTS_OFF
+ m_LightmapFlags: 4
+ m_EnableInstancingVariants: 1
+ m_DoubleSidedGI: 0
+ m_CustomRenderQueue: -1
+ stringTagMap: {}
+ disabledShaderPasses: []
+ m_SavedProperties:
+ serializedVersion: 3
+ m_TexEnvs:
+ - _BumpMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _DetailAlbedoMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _DetailMask:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _DetailNormalMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _EmissionMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _MainTex:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _MetallicGlossMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _OcclusionMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _ParallaxMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ m_Floats:
+ - _BumpScale: 1
+ - _Cutoff: 0.5
+ - _DetailNormalMapScale: 1
+ - _DstBlend: 0
+ - _GlossMapScale: 1
+ - _Glossiness: 0
+ - _GlossyReflections: 0
+ - _Metallic: 0
+ - _Mode: 0
+ - _OcclusionStrength: 1
+ - _Parallax: 0.02
+ - _SmoothnessTextureChannel: 0
+ - _SpecularHighlights: 0
+ - _SrcBlend: 1
+ - _UVSec: 0
+ - _ZWrite: 1
+ m_Colors:
+ - _Color: {r: 0, g: 0.6132076, b: 0.06537688, a: 1}
+ - _EmissionColor: {r: 0, g: 0, b: 0, a: 1}

GalacticConquest/Assets/GalacticConquest/Materials.meta

@@ -0,0 +1,76 @@
+%YAML 1.1
+%TAG !u! tag:unity3d.com,2011:
+--- !u!21 &2100000
+Material:
+ serializedVersion: 6
+ m_ObjectHideFlags: 0
+ m_CorrespondingSourceObject: {fileID: 0}
+ m_PrefabInternal: {fileID: 0}
+ m_Name: Grey
+ m_Shader: {fileID: 46, guid: 0000000000000000f000000000000000, type: 0}
+ m_ShaderKeywords: _GLOSSYREFLECTIONS_OFF _SPECULARHIGHLIGHTS_OFF
+ m_LightmapFlags: 4
+ m_EnableInstancingVariants: 1
+ m_DoubleSidedGI: 0
+ m_CustomRenderQueue: -1
+ stringTagMap: {}
+ disabledShaderPasses: []
+ m_SavedProperties:
+ serializedVersion: 3
+ m_TexEnvs:
+ - _BumpMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _DetailAlbedoMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _DetailMask:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _DetailNormalMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _EmissionMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _MainTex:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _MetallicGlossMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _OcclusionMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ - _ParallaxMap:
+ m_Texture: {fileID: 0}
+ m_Scale: {x: 1, y: 1}
+ m_Offset: {x: 0, y: 0}
+ m_Floats:
+ - _BumpScale: 1
+ - _Cutoff: 0.5
+ - _DetailNormalMapScale: 1
+ - _DstBlend: 0
+ - _GlossMapScale: 1
+ - _Glossiness: 0
+ - _GlossyReflections: 0
+ - _Metallic: 0
+ - _Mode: 0
+ - _OcclusionStrength: 1
+ - _Parallax: 0.02
+ - _SmoothnessTextureChannel: 0
+ - _SpecularHighlights: 0
+ - _SrcBlend: 1
+ - _UVSec: 0
+ - _ZWrite: 1
+ m_Colors:
+ - _Color: {r: 0.6226415, g: 0.6226415, b: 0.6226415, a: 1}
+ - _EmissionColor: {r: 0, g: 0, b: 0, a: 1}