¿Qué archivos debemos incluir en Git para un proyecto de Unity?

Si aún no tienes tu proyecto de Unity a buen recaudo, en un repositorio de Git como GitHub, deberías hacerlo cuanto antes. 

Las principales razones para añadir un repositorio de versiones a tu rutina de trabajo son:

• Tener tu proyecto en un repositorio remoto (como GitHub, GitLab o Bitbucket) asegura que no pierdas tu trabajo si algo le pasa a tu ordenador.
• Git te permite rastrear cambios en tu proyecto, revertir a versiones anteriores si algo sale mal y entender qué modificaciones se hicieron y cuándo.
• Si trabajas en equipo, Git facilita que múltiples personas trabajen en el mismo proyecto sin conflictos, usando ramas y merges.
• Puedes usar ramas para experimentar con nuevas funciones o correcciones sin afectar la versión principal, manteniendo el proyecto ordenado.
• Muchas plataformas de CI/CD y herramientas de desarrollo se integran con Git, lo que agiliza flujos de trabajo como pruebas automáticas o despliegues.
• Usar Git es un estándar en la industria, y dominarlo te prepara para trabajar en entornos profesionales.

Sin embargo, no debes subir todos tus ficheros a un repositorio Git. Por ejemplo, no tiene sentido subir los compilados porque cualquiera los puede generar si cuentan con el código fuente. Subir los compilados sólo incrementaría innecesariamente el tamaño del repositorio, haciéndolo más caro de mantener e incrementando los tiempos de sincronización del resto del equipo de desarrolladores.

Por eso, para proyectos de Unity, asegúrate de incluir un archivo .gitignore adecuado para evitar subir archivos innecesarios. Git espera encontrar este fichero en la raíz del proyecto (al mismo nivel que la carpeta Assets). Su contenido enumera el listado de nombres de fichero y carpetas que Git debe evitar incluir en el repositorio para mantenerlo limpio. En internet, puedes encontrar abundantes ejemplos de ficheros .gitignore adecuados para Unity. Si usas Rider, JetBrains tiene un plugin oficial (denominado .ignore) que te ofrece un wizard para generar un .gitignore adecuado al proyecto que te traigas entre manos (incluido Unity). Otra fuente puede ser GitHub, que tienen un repositorio oficial con archivos .gitignore para los frameworks de desarrollo más populares, y tampoco falta el de Unity. 

Qué debes dejar fuera del repositorio

Si optas por construirte un fichero .gitignore a mano, debes excluir lo siguiente:

• Carpetas de Unity: Excluye Library, Temp, Obj, Build, Logs y UserSettings, ya que son generadas automáticamente por Unity y no deben versionarse.
• Archivos de compilación: Archivos como .csproj, .sln y otros generados por Visual Studio o Rider no son necesarios en el repositorio.
• Caché y assets: Excluye caché de Addressables, StreamingAssets y paquetes para reducir el tamaño del repositorio.
• Archivos del sistema operativo: Ignora .DS_Store (macOS) y Thumbs.db (Windows).
• Editores y herramientas: Excluye configuraciones específicas de editores como VS Code o Rider, pero permite incluir configuraciones compartibles (como .vscode/settings.json).
• Archivos grandes: Si no usas Git LFS, excluye archivos comprimidos o pesados como .unitypackage.

Qué debes incluir en el repositorio

Eliminado lo anterior, tu repositorio debería contener sólo las siguientes carpetas:

• Assets
• Packages
• Project Settings

La más crítica de las carpetas anteriores es la de Assets ya que contiene todo el código del proyecto, así como los modelos, texturas, música, sonidos, y todos los elementos con los que está construido nuestro proyecto. 

La pregunta de siempre: ¿Qué hago con los ficheros .meta?

Si usas el explorador de ficheros para examinar la carpeta Assets, verás que cada uno de los elementos anteriores lleva asociado un fichero con extensión .meta. Dado que Unity se encarga de generar automáticamente esos ficheros .meta, mucha gente se pregunta si deberían incluirse en el repositorio. Para responder a esa pregunta, primero hay que entender para qué sirven.

Unity asocia un fichero .meta a cada uno de los ficheros assets que se incluyan en el proyecto. En los ficheros .meta se guardan los parámetros para importar cada asset en el proyecto. Esto es especialmente importante con assets como las texturas o los sonidos ya que, si no incluimos los ficheros .meta en el versionado, otros desarrolladores del equipo pueden importar los mismos recursos con diferentes parámetros, lo que puede darnos problemas.

Dado que Unity tiende a generarlos automáticamente si no los encuentra, es muy importante insistirle a todo el equipo en que, cuando creen un nuevo asset, lo incluyan en el repositorio junto con su respectivo archivo .meta. Si alguno se le pasase incluir en el repositorio el fichero .meta del recién creado asset, los próximos desarrolladores que se lo bajasen generarían un fichero .meta para él (lo haría el editor de Unity de manera automática al echarlo en falta) por lo que tendríamos un potencial conflicto al hacer los merges, dado que tendríamos diferentes ficheros .meta (uno por desarrollador) para un mismo asset. Es una situación fea que da para recurrentes preguntas en reddit. 

Moraleja: bajo ningún concepto te olvides de incluir los ficheros .meta en el repositorio de versiones.

Conclusión

Con lo anterior, ya tienes lo básico para saber si te falta algo importante en tu repositorio. Luego, operar con ese repositorio es un capítulo aparte que da para muchísimo. Usar un repositorio de Git es fácil, pero hacerlo de manera efectiva, y sin liarla, tiene mucha más miga.

Si quieres profundizar en este tema, le dedico el capítulo 15 de mi libro "Reconstrucción de un juego mítico con Unity".

Game Engines basados en Blender

Blender se ha erigido, por derecho propio, como una de las grandes herramientas de modelado, animación y rendering del mercado. Su calidad, unida a su carácter open-source y gratuito, ha disparado su popularidad aupándola a una posición en la que puede mirar de tú a tú a grandes "monstruos" comerciales como Maya o 3D Studio.

Lo que no sabe tanta gente es que Blender también fue un engine para construir juegos. Se llamaba Blender Game Engine (BGE), y estuvo integrado con Blender desde comienzo de la década de los 2000. Permitía la creación de aplicaciones interactivas directamente desde Blender, sin necesidad de herramientas externas. Para la lógica, permitía no sólo programar en Python sino también emplear un lenguaje visual, muy similar a los actuales Blueprints de Unreal Engine.

El engine permitía crear juegos tanto 3D como 2D, con física en tiempo real (usando la librería Bullet Physics). También permitía crear shaders básicos y animaciones. Como estaba integrado en Blender, ya no hacía falta exportar los modelos a otros motores.

Para demostrar las capacidades del engine, la fundación Blender desarrolló el juego "Yo Frankie!" en 2008. El juego era vistoso, pero pronto quedó claro que que se quedaba atrás respecto a lo que podían ofrecer otros engines como Unity o Unreal. Frente a estos, el BGE no podía ofrecer más que un rendimiento limitado en proyectos complejos, adolecía de falta de soporte para plataformas móviles modernas y su interfaz de desarrollo estaba menos pulido.

Al final, la fundación Blender tuvo que tomar una decisión. Para mantenerse a la par que otros engines, el BGE requería en exclusiva de un equipo de desarrolladores que la fundación no podía dedicar. Además, la comunidad de desarrolladores de BGE, ajenos a la fundación, era muy pequeña y eso hacía que el ritmo de actualizaciones fuera muy lento. BGE se iba quedando atrás a ojos vista e iba lastrando al resto del proyecto de Blender. Al final se optó por abandonar el BGE, para poder concentrar los recursos de desarrollo en aquello que mejor se le daba a Blender: las herramientas de modelado, animación y renderizado (como Cycles).

La eliminación formal del BGE tuvo lugar en 2019, con la versión 2.80 de Blender. A partir de ahí, la fundación recomendó usar Blender como herramienta de modelado y exportar desde allí los assets a motores más avanzados.

Afortunadamente, como suele pasar en el mundo open-source, el cierre de un proyecto no suele ser tal, sino más bien su traspaso. Otros desarrolladores, interesados en continuar con el proyecto, recogieron el código fuente de BGE y lo hicieron evolucionar a partir de ahí. Gracias a eso, dónde antes teníamos un engine (BGE) ahora tenemos dos descendientes de aquel y uno fuertemente inspirado en él. Vamos a analizarlos:

UPBGE (Uchronia Project Blender Game Engine)

Este engine fue creado, junto con otros colaboradores, por Porteries Tristan, uno de los desarrolladores del BGE original 

Inicialmente, UPBGE pretendía ser una bifurcación que mejorase el código de BGE, limpiando su base y experimentando con nuevas características, pero con vistas a acabar incorporándose en el código principal de BGE. Sin embargo, la eliminación de BGE en la versión 2.80 de Blender llevó a UPBGE a adquirir identidad propia e independiente. A partir de entonces, UPBGE ha continuado su desarrollo asegurándose de sincronizar su código con el de Blender, para mantener la compatibilidad.

UPBGE está completamente integrado con Blender, permitiendo modelado, animación y desarrollo de juegos en un solo entorno sin necesidad de exportar assets.

Utiliza el motor EEVEE de Blender para renderizado en tiempo real, con soporte para sombreado PBR, reflejos SSR, oclusión ambiental GTAO, bloom, sombras suaves y volumétricos.

Usa la biblioteca Bullet Physics para simulaciones en tiempo real, incluyendo cuerpos rígidos, simulación de obstáculos y búsqueda de caminos.

Además, incluye un motor de audio basado en OpenAL y Audaspace, con soporte para sonido 3D

Para la lógica de los juegos, mantiene el sistema de "logic bricks" del BGE original y añade Logic Nodes, facilitando la creación de comportamientos interactivos sin programar. También soporta scripting en Python para los que prefieran programar a golpe de teclado.

A la hora de importar y exportar elementos, permite los mismos formatos que Blender, principalmente FBX, Collada, glTF, OBJ y STL.

Se trata de un proyecto muy activo, con un equipo pequeño pero muy implicado de desarrolladores, que sacan actualizaciones regulares cada pocos meses y mantienen el engine sincronizado con las evoluciones de Blender.

A nivel de funcionalidades, los desarrolladores planean añadir características modernas como SSAO, profundidad de campo (DoF), herramientas para modo en línea o luces de área.

Por tanto, se trata de un proyecto muy interesante y prometedor, al que sólo se puede poner un pero y es que el rendimiento que se puede esperar en escenas complejas, con muchos polígonos o riqueza de efectos, puede ser más limitado que el que se puede conseguir con engines como Unity o Unreal.

También hay que tener en cuenta que hereda la licencia GPL de BGE. Los juegos desarrollados con UPBGE no están obligados a ser de código abierto si solo usan los datos del proyecto (modelos, texturas, scripts, etc.) y no distribuyen el ejecutable de UPBGE (blenderplayer). Sin embargo, si un juego incluye el blenderplayer o partes del código de UPBGE, debe cumplir con la GPL y ser distribuido con el código fuente.

Range Engine

Este engine no es un fork del BGE original, sino de UPBGE. Se originó en 2022, como consecuencia de determinadas decisiones de diseño que se tomaron para UPBGE 3.0. Algunos desarrolladores entendieron que dichas decisiones alejaban a UPBGE del espíritu del BGE original y por eso decidieron escindirse a través de un fork.

Por ese motivo, Range Engine conserva un interfaz mucho más cercano al que había en el BGE original. Frente a UPBGE, Range Engine prima la sencillez de uso.

Range Engine prioriza la compatibilidad con proyectos antiguos de BGE y la sencillez en el flujo de trabajo de los desarrolladores.

Su juventud, y su relativamente menor base de desarrolladores, explican que sus funcionalidades y ritmo de actualizaciones sean menores que los de UPBGE. 

Aun así, parece que han conseguido optimizar el apartado de animaciones frente a UPBGE. Por otro lado, también se han observado limitaciones de rendimiento cuando se utiliza este engine con grandes escenarios abiertos. 

Al igual que UPBGE, está licenciado con GPL. Sin embargo, incluye Range Armor, un formato proxy que permite empaquetar datos de juego separadamente del ejecutable blenderplayer, posibilitando la creación de juegos bajo licencias más flexibles como MIT, lo que facilita la distribución comercial sin restricciones estrictas.

Armory 3D

A diferencia de los dos anteriores, no se trata de un fork directo de BGE, sino de engine de juegos independiente que usa a Blender como complemento para el modelado, texturizado, animación y composición de escenas. Además, enriquece lo anterior con herramientas relacionadas como ArmorPaint (para pintura de texturas PBR) y ArmorLab (para creación de texturas con IA), ambas integradas con el motor Armory.

Basa su editor de lógica en scripts de lenguaje Haxe. Algunos dicen que este lenguajes es más flexible que el Python utilizado en BGE. También ofrece un editor visual basado en nodos, a los que recientemente se han añadido uevos nodos para interpolación (tweening) de valores, vectores y rotaciones, nodos de dibujo de cámara, nodos de pulso para controlar tasas de disparo, y mejoras en la jerarquía de nodos lógicos.

A nivel multimedia, este engine se apoya en el framework Kha. Utiliza un renderizador físicamente basado, compatible con pipelines HDR, sombreado PBR y efectos de posprocesamiento, todo ello de forma muy personalizable.

Al igual que BGE, utiliza Bullet Physics, como motor de físicas, y soporta cuerpos rígidos, colisiones y físicas blandas. También permite configurar el motor de físicas Oimo como alternativa. Además, ofrece soporte para sistemas de partículas (emisor y cabello) con instanciación por GPU para mejorar el rendimiento

Armory 3D tiene mayor compatibilidad para exportar tu juego a diferentes plataformas y ofrecer un rendimiento optimizado de las animaciones. Actualmente soporta Windows, macOS, Linux, Web, Android, iOS y consolas (con configuraciones específicas).

A diferencia de los anteriores, Armory 3D está impulsado principalmente por un único desarrollador (Lubos Lenco) y eso se nota en que las actualizaciones llegan con cuenta gotas. Aun así, poco a poco se van incrementando las colaboraciones y aportaciones externas conformando un primigenio núcleo de desarrolladores.

En cuanto a la licencia, una ventaja respecto a los herederos directos de BGE es que Armory 3D usa la licencia Zlib, más permisiva que la GPL de Blender, permitiendo mayor flexibilidad para proyectos comerciales.

Conclusiones

Como puedes ver, el desarrollo de juegos con Blender está muy vivo, y no sólo usándolo como herramienta complementaria de modelado y animación, sino como un engine en si mismo.

A día de hoy no ofrece un rendimiento equiparable al que se puede obtener con engines dedicados como Unity, Unreal o Godot Engine, pero la posibilidad de poder concentrar en una misma herramienta tanto la programación como el modelado, texturizado y rigging de assets, puede simplificarle mucho la vida a los que quieran iniciarse en el mundo de los videojuegos. Sin contar con que lenguajes como Python o Haxe son realmente sencillos para aprender a implementar los algoritmos típicos de un juego.

Mi consejo, si quieres iniciarte en este tipo de engines, es que empieces con UPBGE y luego pruebes los otros dos, a ver qué valor diferencial te pueden ofrecer.

Cómo implementar un cono de visión en Unity

Un cono de visión en videojuegos es un mecanismo utilizado principalmente en juegos de sigilo o estrategia para simular el campo de visión de un personaje no jugable (PNJ), como un enemigo o un guardia. Se representa como un área cónica que se origina en los ojos del PNJ y se extiende hacia adelante en un ángulo determinado, definiendo el rango y la dirección en la que el PNJ puede detectar al jugador u otros objetos. Si no hay obstáculos por medio, todos los objetos que se encuentren dentro del cono de visión del jugador son visibles para este.

Puedes encontrar algunos ejemplos célebres de uso de este concepto en juegos como Commandos o Metal Gear Solid. En Commandos el cono de visión de los enemigos es visible en la ventana principal  para mostrar el área de vigilancia de los soldados enemigos.

Conos de visión en Commandos

En Metal Gear Solid los conos de visión no se muestran en la ventana principal sino en el minimapa de la esquina superior derecha, para permitir que el jugador pueda planear sus movimientos para desplazarse por el escenario sin ser detectado.

Conos de visión en Metal GearSolid

En general, el cono de visión es clave para crear mecánicas de sigilo, ya que obliga al jugador a planificar movimientos, usar el entorno (como coberturas o distracciones) y gestionar el tiempo para evitar ser detectado. También añade realismo, ya que simula cómo los humanos o criaturas tienen un campo de visión limitado, no omnidireccional.

En este artículo vamos a ver cómo podemos implementar un cono de visión en Unity. La idea es crear un sensor que simule este modo de detección, de tal manera que podamos añadirlo a nuestros PNJ.

Características principales de los conos de visión

• Ángulo: El cono suele tener forma de triángulo o sector circular en 2D, o un cono tridimensional en juegos 3D. El ángulo de visión (por ejemplo, 60° o 90°) determina la amplitud de campo que el PNJ puede "ver".
• Distancia: El cono tiene un alcance máximo, más allá del cual el PNJ no detectará al jugador, incluso si está dentro del ángulo de visión.

Puedes añadirles más adornos, pero un cono de visión se define sólo por esos dos factores.

En muchos juegos, el cono de visión se muestra gráficamente al jugador (especialmente en vista cenital o en interfaces específicas) para indicar dónde debe evitar ser visto. Puede cambiar de color (por ejemplo, verde para "sin alerta" y rojo para "alerta"). En este artículo no cubriré la parte visual porque tampoco aporta mucho. Quiero enfocarme a implementar lo que el PNJ puede ver y lo que no, no a la representación del cono.

En Unity, lo normal es que el componente que implemente el cono de visión exponga esas dos características en el inspector, tal y como se puede ver en la captura siguiente:

Campos básicos para implementar un cono de visión

En mi caso, detectionRange (línea 15) implementa la distancia, mientras que detectionSemiconeAngle (línea 18) implementa el ángulo.

En el caso del ángulo, mi código parte de unas premisas que hay que tener en cuenta. La primera es que he usado un atributo [Range] (línea 17) para poder configurar el valor de este campo con un control deslizante y para limitar el rango de valores pasibles al intervalo entre 0 y 90 grados. Si bien es cierto que el ángulo de visión de una persona es superior a los 90º grados laterales, en los juegos sería demasiado difícil esquivar a un personaje con ese cono de visión así que lo normal es no superar los 90º, siendo los 45º lo más habitual. La segunda premisa es que trato al ángulo como un semiángulo. Es decir, lo mido desde la dirección que considere frontal (Forward, en mi caso) en un sentido, y luego se replica especularmente en el otro sentido para generar un cono simétrico. 

Los dos parámetros que definen un cono de visión

En mi ejemplo, estoy trabajando en 2D, así que he definido que Forward sea el eje +Y local, tal y como se puede ver en la siguiente captura. 

 

Definición del vector frontal (Forward)

En la línea 20 de la captura de código he incluido un campo más, layersToDetect, que vamos a usar de filtro, como veremos un poco más adelante.

Cómo detectar si una posición está dentro del cono de visión

Definida la distancia y el ángulo, tenemos que valorar si la posición a comprobar está a menos de esa distancia y si el ángulo entre el vector de posición relativa y el vector Forward del cono es inferior al ángulo de este. En Unity, es muy fácil calcular ambas cosas.

 

Método para determinar si una posición está dentro del cono de visión

La manera más sencilla de calcular la distancia es usar el método Vector2.Distance(), tal y como hago en la línea 126 de la captura, pasándole como parámetros la posición del cono de visión (coincidente con su vértice) y la posición a chequear.

Para el ángulo, podemos usar el método Vector2.Angle(), tal y como se ve en la línea 127. Este método devuelve el ángulo absoluto entre dos vectores, por eso le paso por un lado Forward (línea 128) y por otro el vector de la posición a chequear, relativa al origen del cono (línea 129).

Si tanto la distancia, como el ángulo, están por debajo de los umbrales definidos en el cono, entonces la posición chequeada está dentro de este.

Filtrado de objetos

Podríamos dejar aquí el artículo y tendrías un cono de visión funcional. Te bastaría con recopilar todos los objetos potencialmente visibles del escenario, e ir pasando sus posiciones (uno a uno) al método PositionIsInConeRange() definido antes. Habría que hacer esta comprobación periódicamente, quizás en el método Update() o en el FixedUpdate().

Sin embargo, esto no sería muy eficiente ya que el escenario podría ser enorme y y contener multitud de objetos. Sería mucho mejor si pudiéremos hacer un filtrado previo, de manera que sólo le pasásemos a PositionIsInConeRange() los objetos mínimos e imprescindibles.

Filtrado por capas

El primer filtrado que podríamos aplicar es por capa. Podemos distribuir los objetos del escenario en distintas capas y configurar el cono de visión para que sólo tuviese en cuenta los objetos de una capa determinada. Ese era el propósito del campo layersToDetect mencionado antes. Extendido, este campo tiene un aspecto como el de la captura.

Campo layersToDetect de tipo LayerMask

Este tipo de campos permite selección múltiple, por lo que puedes definir que tu cono analice varias capas simultáneamente.

Una vez que sepas qué capas quieres analizar, discriminar si un objeto está o no en alguna de esas capas es aparentemente sencillo, como puedes ver en la siguiente captura.

Cómo saber si un objeto está en alguna de las capas de un LayerMask

Digo "aparentemente" sencillo porque, aunque puedes limitarte a copia-pegar este código en el tuyo, entenderlo del todo tiene su miga.

Para empezar, un LayerMask tiene un campo value que es un entero de 32 bits en el que cada uno de ellos representa las 32 capas posibles en una escena de Unity. Puedes imaginarte una sucesión de 32 unos y ceros. Si en el campo layerMask incluyes dos capas, en el campo value aparecerán 2 bits con valor uno y el resto serán ceros. El valor entero final del campo dependerá de la posición de esos unos aunque, en realidad, dicho valor es indiferente porque lo importante es qué posiciones tienen un uno.

Por otro lado, todos los objetos de Unity tienen un campo llamado layer que contiene un entero con valores que van desde el 0 al 31. Este entero lo que señala es el índice de la capa a la que pertenece el objeto, dentro del LayerMask de todas las capas posibles de la escena. Por ejemplo, si el campo layer de un objeto tiene un valor 3, y esa capa está incluida en un LayerMask, entonces dicho LayerMask tendrá un uno en su bit de índice 3.

Para saber si la capa de un objeto está dentro de las marcadas en un LayerMask tenemos que hacer una comparación, usando para ello la capa del objeto como máscara. El truco es generar un entero cuyo valor binario esté lleno de ceros y meter un uno en la posición que corresponde a la capa a comprobar. Ese entero es lo que llamamos la máscara. Compararemos dicha máscara con el LayerMask, haciendo un AND binario, y veremos si el valor resultante es o no distinto de cero. Si fuese cero significaría que el LayerMask no incluía la capa que queríamos comprobar.

De ve mejor representando el ejemplo de antes. Mira la siguiente captura. 

Operación para comprobar si una capa está contenida dentro de un LayerMask

En ella he representado un LayerMask que con dos capas, la de índice 1 y la de índice 3 (son las posiciones que tiene a uno). Supón ahora que queremos comprobar si el LayerMask contiene la capa 3. 

Lo que hemos hecho ha sido genera una máscara con todo ceros, salvo el uno de la posición 3, y hemos hecho AND con el LayerMask. El hacer AND con una máscara hace depender el resultado final del valor que tuvieran los dígitos del LayerMask en las posiciones marcadas por la máscara. En este caso, la máscara señala la posición 3 por lo que el resultado final será cero o diferente a cero dependiendo de si la posición 3 del LayerMask es cero o diferente de cero. En este caso será diferente de cero.

Filtrado por cercanía

Con el filtrado por capas evitaremos llamar a PositionIsInConeRange() por objetos que estén en capas que no nos interesen. Eso supondrá una mejora en el rendimiento, pero podemos mejorarlo más.

Otro filtrado previo que podemos hacer es descartar aquellos objetos que estén demasiado lejos del cono como para que exista la posibilidad de estar en él.

Como puedes ver en la captura, todo cono de visión puede encajarse en un caja que lo envuelve.

Caja envolvente de un cono de visión

Si esa caja fuese un sensor volumétrico (en términos de Unity: un collider en modo trigger), podríamos pasarle a PositionIsInConeRange() sólo los objetos que entrasen en el sensor volumétrico y fuesen de las capas que nos interesasen.

Método para procesar los objetos que entrasen en la caja

En el código de la captura, OnObjectEnteredCone() sería un event handler que se aplicaría en caso de que un objeto entrase en la caja. En mi caso, el collider en modo trigger lleva asociado un script que emite un UnityEvent cuando el trigger hace saltar su OnTriggerEnter2D. Lo que he hecho es asociar OnObjectEnteredCone() a ese UnityEvent.

Partiendo de ahí, el código de la captura es sencillo. En la línea 159 comprobamos si el objeto está en una de las capas que nos interesa, usando el método ObjectIsInLayerMask() que analizamos antes. En caso afirmativo, en la línea 161 se comprueba si el objeto se encuentra en el área cubierta por el cono de visión, usando el método PositionIsInConeRange() que veíamos al principio. Y, finalmente, si ambas comprobaciones resultan positivas, se añade al objeto a la lista de los objetos detectados por el cono de visión (línea 164) y se emite un evento para que los scripts que usen el cono de visión sepan que este ha hecho una nueva detección.

Como te puedes imaginar, hace falta implementar un método recíproco para procesar los objetos que salgan de la caja de detección; sí como otro método para procesar los que pudieran mantenerse dentro de la caja de detección pero se hubiesen salido del área cubierta para el cono. Bastará con enlazar eventHandler a los métodos OnTriggerExit2D() y OnTriggerStay2D() del script del trigger collider de la caja de detección. Ninguna de esas casuísticas tiene especial complejidad, una vez entendido el código de OnObjectEnteredCone(), pero de todos modos te muestro mi implementación de la comprobación de un objeto que permanezca en el área de detección.

Comprobación de un objeto que permanezca en el área de detección

Llegados a este punto, probablemente te estés preguntando cómo dimensionar la caja para que se ajuste al cono de visión. 

Si te fijas en la captura que ponía antes, con la caja envolviendo en cono de visión, verás que la altura de la caja coincide con el parámetro que he denominado detectionRange. 

Lo que tiene algo más de miga es la anchura de la caja, ya que tenemos que recurrir a trigonometría básica. Fíjate en la captura:

Algo de trigonometría para calcular el ancho de la caja

Partiendo de la captura, para encontrar la anchura de la caja de detección necesitamos calcular la longitud de B, que se corresponderá con la mitad de dicha anchura. 

B es uno de los lados del rectángulo creado usando detectionRange como diagonal. Todo rectángulo está compuesto a su vez de dos triángulos rectángulo cuya hipotenusa será precisamente detectionRange. Si nos fijamos en el triángulo rectángulo superior (el de la zona roja), y repasamos la trigonometría que dimos en el colegio, estaremos de acuerdo de que el seno de detectionSemiConeAngle es igual a B dividido entre detectionRange. Por lo tanto, podemos calcular B como el producto entre detectionRange y el seno de detectionSemiConeAngle; siendo la anchura total de la caja de detección el doble de B.

Traducido a código, las dimensiones de la caja de detección se calcularían de la siguiente forma:

Cálculo de las dimensiones de la caja de detección

Puedes hacer este cálculo cada vez que cambies los parámetros del cono de visión, y modificar manualmente las dimensiones del trigger collider con el resultado del cálculo; pero yo he preferido hacerlo automático enlazando el collider con un componente BoxRangeManager que he implementado yo, y que modifica dinámicamente el tamaño del collider según vayas cambiando los campos Range y Width de dicho BoxRangeManager. La implementación de ese componente se basa en lo que expliqué en mi artículo sobre "Sensores volumétricos con dimensiones dinámicas en Unity", así que no voy a repetirlo aquí.

Conclusión

Con esto ya tienes todo lo que necesitas para crear un cono de visión, sencillo, eficiente. Mi consejo es que crees un componente genérico que reutilices en tus diferentes proyectos. Se trata de un elemento tan habitual que no tiene sentido implementarlo desde cero cada vez. Este debería ser uno de los elementos de tu librería  personal de componentes reutilizables.

Espero que este artículo te haya resultado interesante y te sirva para crear mecánicas de juego emocionantes.