Hay varios tipo de colisiones que se pueden detectar. Vamos a arrancar por el más “fácil” de implementar, aunque no estoy seguro de que sea el más “fácil” de usar. Para ello vamos a usar un Job que nos va a avisar cuándo dos Triggers colisionen… Peeeeeero…

Antes de arrancar con esto tenemos que agregar un paquete más a nuestro proyecto. Ese paquete adicional va a ser el encargado de nuestras físicas. Recordémos que al convertir nuestros objetos a entidades, Unity reemplaza los componentes por los equivalentes en cada caso en particular. Habrán notado que cada una de nuestras entidades no dispone de elementos de física. Esto es porque el paquete de físicas para ECS no está agregado al proyecto. Pero lo podemos agregar siguiendo un procedimiento similar al que ya hicimos cuando agregamos un package a Unity desde Git. Abrimos nuevamente el Package Manager en Windows => Package Manager y agregamos el package desde esta dirección: com.unity.physics

De esta manera, vamos a ver que nos descarga un nuevo paquete con la parte de físicas de ECS. Si todo sale bien (no tendría por qué salir mal pero lo aclaro), no tendríamos que hacer nada nuevo. Ahora verán que desde ahora en adelante las entidades tienen más componentes, entre ellos, sus respectivos colliders y rigidbodies agregados como entidades (en realidad, agrega sus equivalentes).

Como verán en la imagen que pongo más abajo, se agrega el módulo de físicas para ECS y consume además varias herramientas.

Ahora sí ya estamos listos para ver algo de colisiones.

Esta interfaz nos permite realizar un job que nos avisará cuándo dos entidades físicas estén colisionando. Para ello vamos a crear primero nuestro sistema, ya que va a ser este el encargado de procesar nuestro job.

Podemos ver que hay bastantes cosas nuevas. Vamos a empezar a nombrarlas de a poco, pero en principio noten que es un sistema como cualquiera de los que hicimos hasta ahora.

1. StepPhysicsWorld. Este tipo de dato tiene adentro una variable llamada Simulation que nos va a pedir este Job. Así que en principio lo único que hacemos es cargarla y guardarla en una variable para su pase.
2. ComponentDataFromEntity<T>. Este tipo de dato contiene todos los componentes de tipo T (donde T es un IComponentData), de las entidades que se van procesando. O sea que acá vamos a almacenar y leer dichos componentes. Es algo así como un diccionario donde las claves son las entidades y los valores serían los tipos T que obtenemos.
3. TriggerJob constructor. Acá lo único que vamos a hacer es construir el Job y pasarle por parámetro nuestro nuestros componentes.
4. Dependency. Anteriormente pasábamos otro job acá en lugar de este parámetro. Pero ahora Unity agregó esa variable para facilitarnos esa tarea. Así que siempre que tengamos que hacer Schedule de nuestros jobs estando dentro de un sistema, podemos pasar este valor por parámetro que ya viene incluído en nuestros sistemas. Anteriormente Unity tenía algo como un JobComponentSystem, pero ahora no es necesario porque nuestros sistemas ya pueden correr con jobs. Así que tenemos esa variable para esos casos.

Al haber una colisión que implique a un “trigger” se ejecutará el método Execute() y nos pasará dentro del evento a las dos entidades involucradas en dicha colisión, por lo cual podremos evaluar la lógica.

Recuerden que no podemos, dentro de un parallel job, destruir entidades (no de una manera sencilla). Por lo cual lo que recomendaría hacer, de momento, es crear un sistema y un componente para esto. Básicamente podrían crear un componente con una variable que indique si un objeto está destruído, y en el sistema eliminar dicha entidad destruía, mediante un LINQ que termine en “WithStructuralChanges().Run()”.

CONTINUARÁ…