Leaderboard

Hola a todos, les presento mi más reciente proyecto Bubbles and Puzzles, espero que sea de su agrado y puedan apoyarme con su feedback, les estaré muy agradecido. Se trata de un juego tipo fruit cut, pero en vez de cortar las frutas, tienes que cortar las burbujas y rescatar las frutas de su interior para completar el nivel y así poder avanzar. El rescate tiene que ser en el orden indicado ya que de lo contrario iras perdiendo vida hasta el punto del Game Over. La meta es llegar lo más lejos posible y conseguir la mejor puntuación para posicionarte en el Tablero de Ranking, tienes la oportunidad de compartir tu dispositivo con hasta 5 jugadores para así hacerlo más competitivo. Sin más les dejo estas imágenes del juego. Disponible en la Play Store.

Buenos días compañeros!!, por fin he solucionado mis problemas con el Animator, aunque no del todo, pero quiero dejar aquí la solución para que no le pase a nadie mas. Unity tiene un orden de transiciones, pero ese orden al menos en la versión 4.7.2 que es la que uso yo, no funciona correctamente hasta que no aprendes a utilizar "Atomic", que es una casilla que por defecto viene marcada, pero que al desmarcarla significa "NO PASAR A ESTA ANIMACIÓN SI ANTES ESTÁ EJECUTANDOSE OTRA QUE ESTÉ PRIMERO EN EL ORDEN DE TRANSICIONES". Quiere decir, que si le damos a correr y a saltar al mismo tiempo, Unity podría intentar hacer la animación de correr y después la de saltar creando una pose extraña, mientras que si destildamos la casilla Atomic y colocamos en la lista de transiciones la pose de saltar en primer lugar, Unity antes de iniciar la animación de correr iniciará la de saltar porque tiene prioridad. Esto me ha solucionado el 90% de los errores de animación, pero aún hay otros como que por ejemplo esté realizando una transición y quieras interrumpirla, que creo que lo voy a tener que hacer con programación, porque esta versión de Unity no tiene el Has Exit Time. Saludos.

Perdón por responder tan tarde! No, no es requerido, las referencias a componentes se buscan automaticamente. La estructura que yo propongo es una estructura óptima, es decir que puedes hacer varias cosas interesantes separando la parte visual de la parte física (collider + rigidbody). Lo que sí o sí es requerido es que todo lo relacionado al personaje esté contenido dentro de un "root" u objeto maestro (padre). No, de hecho CCP no hace referencia a los huesos de ninguna manera. En la "Demo" mi personaje es un humanoide, gracias a esto puedo usar el avatar que Unity ofrece para acceder a los IK (por ejemplo). Por ejemplo (estado LadderClimbing ) public override void UpdateIK( int layerIndex ) { if( !useIKOffsetValues ) return; UpdateIKElement( AvatarIKGoal.LeftFoot , leftFootOffset ); UpdateIKElement( AvatarIKGoal.RightFoot , rightFootOffset ); UpdateIKElement( AvatarIKGoal.LeftHand , leftHandOffset ); UpdateIKElement( AvatarIKGoal.RightHand , rightHandOffset ); } void UpdateIKElement( AvatarIKGoal avatarIKGoal , Vector3 offset ) { CharacterStateController.Animator.SetIKPositionWeight( avatarIKGoal , 0f ); Vector3 originalRightFootPosition = CharacterStateController.Animator.GetIKPosition( avatarIKGoal ); CharacterStateController.Animator.SetIKPositionWeight( avatarIKGoal , 1f ); CharacterStateController.Animator.SetIKPosition( avatarIKGoal , originalRightFootPosition + offset ); } Ahora mismo el método usado para movimiento es muy pero muy simple, un MoveTowards que modifica la velocidad linealmente con el tiempo. El base speed limit indica el target del MoveTowards (función de Vector3) del walk (no de run). Este valor será el valor final de velocidad obtenido, es decir que técnicamente no es posible, ya que mayor límite de velocidad + aceleración implica obtener una velocidad mayor. Ya que es un MoveTowards (incluso si fuese un Lerp), quizás lo que más te importe a la hora de modificarlo es su "t factor" (el tercer argumento de este método). Si tienes el control de "t" entonces puedes controlar la velocidad como quieras, independientemente de sus límites. En mi caso uso acceleration/deceleration como variables "t". Jugar entre los valores de velocidad y los umbrales (threshold) del animator es fundamental. Quizás tratar de cubrir varios tipos de movimiento (parada, arranque suave, trote, correr, etc) todos al mismo tiempo (usando una simple funcion lineal) no sea una buena solución en tu caso. Si realismo en las animaciones es lo que necesitas se pueden hacer dos cosas: Mejorar el script de movimiento. Meter curvas para lograr un movimiento menos lineal y más personalizable es algo que voy a introducir en 2.0.0. Ya esto pasa por el lado de la implementación de la lógica (por parte del usuario) y escapa al alcance del asset. De todas formas siempre trato de meter este tipo de cosas, de manera de facilitar un poco la parte del gameplay. Usar root motion, piensa en GTA 4/5 por ejemplo. No hay scripts ni nada de eso, el clip contiene la información de movimiento y solamente se lee el input del player. Con 1.3.3 puedes usar root motion para planar velocity y seguir usando la gravedad de NormalMovement.

Ostia! Vine a actualizar el hilo del asset, y me di cuenta que nunca lo había creado 😅 ... bueno aquí va... Links: Asset store Demo (Desktop) Demo (webGL) Features Documentación (en ingles) Breve descripción: Character Controller Pro es un controlador de personaje (o character controller) de tipo dinámico que funciona con físicas 2D/3D, y tiene forma de cápsula. El paquete se separa en 3 partes: Core: El character controller con todo lo necesario para que exista y funcione por si solo [Lógica no implementada] Implementation: incluye un sistema construido encima del controlador que ayuda a 1) administrar inputs (sin importar su origen, viejo sistema de Unity, nuevo sistema, Rewired, etc) para luego convertirlas en acciones, y 2) proveer de una maquina de estados (FSM). [Lógica no implementada] Demo: Dentro del paquete se incluyen escenas de demostración, estados (implementaciones de lógica de gameplay), acciones predefinidas (movement, jump, crouch, etc), y más. [Lógica implementada]

¡Hola! He pensado que podría ser interesante ir poniendo aquí los avances que voy haciendo en la preparación de nuestro siguiente proyecto. He comenzado un devlog (con idea de que sea semanal o por lo menos quincenal). Espero que os guste y me hagáis llegar vuestros comentarios. No estaba seguro de su publicar aquí o en proyectos, si algún amable admin quiere recolocarlo al sitio apropiado lo agradezco 😅 https://oniria.world/2021/03/15/devlog-1-avances-con-el-oniria-engine/

Gracias francoe1 Les comparto un pequeño video para ver de que va el juego

Gran asset, lo compré hace un tiempo y es muy versátil, además el bueno de @lightbug tuvo el detalle de ayudarme a configurarlo en mi proyecto y resolverme algunas dudas.

Mil gracias, tu post me ayudo muchísimo, tanto que ya solucione el problema jejejej, yo pensaba que la función OnMouseDown era común para todo, el plan que tenias que configurar con condicionales si clicabas en un sitio o otro. Por si no quedo claro soy nuevo en esto de unity jejejej XD pero muchas gracias por tu ayuda

hola, he visto este "trailer" de un proyecto que esta en kickStarter me parece una pasada y una locura. solo queria compartirlo porque me ha alucinado. os dejo tambien el enlace de kickStarter por si teneis mas curiosidad, salen mas cosas ahi. https://www.kickstarter.com/projects/esbenkongorange/vokabulantis

Y aquí vendría el artículo de esta semana. He estado liando con animaciones procedimentales. https://oniria.world/2021/03/22/devlog-2-animaciones-procedimentales/ ¿Sois de los que en español decís procedural o procedimental?

Interesante aproximación, me pondré manos a la obra, gracias!

Buen día señores, Aplique una solución a otro problema pero creo q podría ser útil aquí, (para que tengas de donde escoger) Cuando se presione la tecla puedes empezar a acumular time.deltatime en una variable, y cuando el tiempo que quieras se cumpla entonces entras con un "if" a la función que quieras que se ejecute. Saludos a todos.

Este sábado pasado presentamos #RayuelaJam2021. Aprovechamos el tirón para hacer una retrospectiva de nuestra participación como estudio en las ediciones pasadas. https://oniria.world/2021/04/12/devlog-5-rayuelajam-retrospectiva/

Otro vídeo del curso un poquitin mas avanzado de creación de NPC's con ML-Agents. Ahora vemos como con una cosa tan tonta como trabajar con un segundo componente RayPerceptionSensor3D (que son 5 o 10 minutos) se puede mejorar la navegación de nuestro agente. Lo que demuestra que mas vale perder tiempo en pensarse un poco las cosas, que en la fuerza bruta de horas de entreno 😮 como me ha pasado a mi. O incluso mejor que entrar en el mundo de cometer errores tocando los hyperparameters del fichero .yaml!

Buenas. No sé si te valdrá...yo para los controles hago uso de los ejes virtuales de Unity. Dichos ejes se mueven entre valores -1 y 1 y poseen dos parámetros que puedes ajustar y que indican cuan lento o rápido pasas de 0-1 o de 1-0 (y con el negativo). Podrías controlar con un IF si el valor llega a 1. En ese caso (según el ajuste que tengas) ya llevarás un tiempo pulsada la tecla y podrías poner el código que quisieras en ese caso. Te paso un enlace del manual que he hecho para Unity por si te sirve de algo: https://wiki.cifprodolfoucha.es/index.php?title=Unity_Gestión_Dispositivos_de_Entrada#Entrada_est.C3.A1ndar La propiedad es Sensitivity y ya tienes un eje llamado Jump configurado para hacer uso de la barra espaciadora.

puedes usar un float para contar el tiempo que mantubiste la tecla pulsada, y si estubo pulsada menos de 0.25f segundos, saltas, pero si estubo pulsada mas, pues haces la orra accion. tendrias que contar el tiempe entre el "down" y el "up" de la tecla

Sin ver cómo tienes montado tu código es un poco jugar a la lotería, pero te sugiero que pruebes con Input.GetKey, este te devuelve True mientras la tecla esté pulsada, si estás usando Input.GetKeyDown prueba a cambiarlo por lo que te digo, y si puedes, enséñanos tu código y será más fácil.

Gracias! 😀 No me quedó bien claro si no supiste/pudiste hacer funcionar este asset o ese "FPS" (?). Gracias Bydark! Espero que siga funcionando 😄 Ya que estoy, la version 1.3.3 debería estar lista dentro de algunas horas. Una cosa que no he mencionado aquí es la existencia de un bug que imposibilita descargar versiones actualizadas de asset (afecta a todos sus asset). Versiones con el fix incluido: 2021.1.0b3 o mayor 2020.2.3f1 o mayor 2019.4.19f1 o mayor Fix manual: Ir a C:/Users/***your-user-name***/AppData/Roaming/Unity/Asset Store-5.x/ Encontrar al autor del asset (/Lightbug/) Borrar "Character Controller Pro.unitypackage" Ir al package manager y descargar el asset nuevamente.

Este fin de semana de pascua, Rubén Sánchez, uno de los administradores de Spain Game Devs, me ha invitado a su sobremesa digital junto con Tel-K Gaming para charlar de varios temas referentes al futuro de Oniria, el arte de Oniria Crimes, y el estado de la industria del videojuegos español. https://oniria.world/2021/04/05/devlog-4-sobremesa-digital-con-tel-k-y-ruben-sanchez/

Está muy pero que muy chulo, Mi único problema con unity es que compré 2 veces y pedí reembolso pero no por el material comprado, es que no tengo ni idea como poner esto en unity para que luego pueda funcionar correctamente. Me aparecen 100 carpetas y ni sé como ordenar o hacer que funcione. lo que me compré fue algo de FPS y al final ni lo usé por no tener ni idea como se usan -_-¡. Pero tu proyecto es muy chulo!!! Es increíble la verdad.

Esta semana he escrito sobre reflexiones personales con el español https://oniria.world/2021/03/29/devlog-3-la-desventaja-competitiva-del-espanol-en-el-desarrollo-de-videojuegos Es un tema complicado... y controvertido. Ojalá fuese más fácil para los españoles salir al mercado internacional.

Buenas! En el apartado de Import Settings (cuando haces clic en el sprite dentro de Unity), debajo pon la opción de "Compression" como "none", o bien como "high quality". Así esto se soluciona.

¡Muchas gracias frnacoe1! 🙂 el sistema esta genial estoy tratando de implementarlo, veo que esta optimizado y funciona para un montón de cosas !

Buenas a todos!, Empecé no hace mucho con Unity y estoy cacharreando con un plataformas 2D. El caso es que quiero hacer que mi personaje active un checkpoint cuando "choca" con él, y esto lo hago con "OnTriggerEnter2D", pero me gustaría que mi personaje lo atravesase. ¿Alguna sugerencia? Gracias de antemano! Edito: se supone que marcando el collider a "isTrigger" no debería de colisionar (o eso creo). Eso no me servía porque igualmente estaba lanzando un raycast desde el personaje para detectar colisiones, así que simplemente he hecho una comparación de tags y que ignore si es X tag. Se puede dar el tema por zanjado, gracias.

Hola, así es, un trigger no debería generar colisiones de ningun tipo (lo que hace que un rigidbody dinámico responda). Te recomiendo que uses Physics2D.queriesHitTriggers para esto. https://docs.unity3d.com/ScriptReference/Physics2D-queriesHitTriggers.html Si lo pones en true cada query (raycast, sphereCast, etc) va a detectar triggers (cosa que en este caso no querés, debe ser falso). El tema es que cada vez que lo usas lo tenés que restablecer (es static!). Por ejemplo: // Guardas el estado actual queriesHitTriggers bool previousQueryHitTriggers = Physics2D.queriesHitTriggers; // Usas lo que vos quieras (en este caso falso) Physics2D.queriesHitTriggers = false; // Hacés el query RaycastHit2D hitInfo = Physics2D.Raycast(...) // Lo repones Physics2D.queriesHitTriggers = previousQueryHitTriggers;

Con rostro por supuesto. Yo te añado los nombres: Mora Dora, Melón Pelón y Coco Loco 😄

Gracias francoe1 ! Creo que tomaré la opción del mapa grande, supongo que en Parodius utilizarán la mecánica de un mapa grande.

Hola buenas, hace unos días empecé un proyecto de videojuego en unity, es un juego en 2d y en el mismo creo un mapa de forma dinámica con unos sprites, intente convertir esos sprites en botones pero después lei que el componente button solo se puede usar con elementos de la categoría ui, así que se me ocurrió otra forma de hacerlo pero no doy conseguido que funcione. Lo que pretendo hacer es que al hacer click en una parte de ese mapa el programa me identifique que gameobject estoy cliqueando y si es el que quiero yo que cambie de escena. Si pudieseis ayudarme con la función que tengo que usar o que tengo que hacer para que funcione os estaria eternamente agradecido. Un saludo.

ok gracias por responder. entonces si el sprite tiene un collider puedo saber que gameobject estoy clickando por lo que entiendo

Genial lo del outline! Como lo dije en su momento, el outline sienta mejor con el juego, además de (creo) ayudar en el gameplay 😉. Para el caso del fill, una alternativa podría ser implementar un blend entre el fill y el color original (50-50 por ej). El script de animación está muy bueno también, me encantan ese tipo de enfoque, sobretodo porque soy pésimo animando 🙃. Tengo pensado implementar la famosa rueda (sacada de aquí). No solo podés controlar la velocidad de animación sino también la sincronización con el movimiento. Por ej, en un momento dado determinas la rotación de la rueda, definis la pose objectivo (ej el frame "i") y luego usas el "ease" que quieras desde el frame actual al target.

Todo eso me suena a que no estás haciendo 2 cosas: Seteando la prioridad de las transiciones, Selecciona un estado y fijate que en el inspector te figuran en order, de arriba (más prioridad) a abajo (menos). Configurando la fuente de interrupción de cada estado (https://docs.unity3d.com/Manual/class-Transition.html#TransitionInterruption), ya que se puede dar que una transición esté pasando, pero un estado (el actual o el siguente) tenga una transición valida al mismo tiempo. Respecto a 2, esto dice la doc: Value Function None Don’t add any more transitions. Current State Queue the transitions from the current state. Next State Queue the transitions from the next state. Current State then Next State Queue the transitions from the current state, then queue the ones from the next state. Next State then Current State Queue the transitions from the next state, then queue the ones from the current state. Ejemplo de un personaje que está en el estado "caida" y pasa a "suelo" al caer (isGrounded = true). En plena transición le das a la tecla de salto, es decir, deberías pasar de "suelo" a "salto". Volviendo al isGrounded = true, un trigger se llama, ahora está en plena transicion a "suelo". Vamos a suponer que todavía no estás en "suelo" (que es el proximo estado, el "next"), entonces sigues en "caida" (el actual o "current"), por lo que si presionas la tecla de salto no pasa nada (a nivel animación, probablemente el objeto físico salte, eso no nos importa de momento). La cosa que la animación no cambia, todo termina en "suelo" eventualmente. Si configuras que la fuente de interrupción sea "Next", lo que va a pasar es lo siguiente: Hay una transición que require accionarse ya mismo ("suelo -> salto" dió válida) Dicha transición pertenece al estado siguiente "suelo" (next). Recordar que los estados contienen a las transiciones si tienen su cola (no su punta). En este caso suelo contiene "suelo -> salto", salto tendrá "salto -> caida", caida tendra "caida -> suelo" , y así... El estado actual (caida) tiene como fuente de interrupción el estado Next ("suelo", quien contiene la transición a salto y encima es válida) El sistema suma dos más dos y termina interrumpiendo la transición actual de inmediato, en base a la "interruption source" de arriba. Todo esto no hubiera terminado bien si tuvieras current como fuente de interrupción. Si no estás seguro metele "Current state then next state". Documentación. Como dijiste, esas son las dos más usadas, Play reproduce de una, Crossfade te da una transición de donde estés hacia el estado target. Pasa que eso es muy confuso, que pasa si estás saltando (que se yo, 100 metros en el aire) y a los 3 segundos (llegaste al pico) no presionas nada? tenés que andar leyendo el estado actual, y en base a eso determinar si das Play/Crossfade a X animación... terminas creandote la misma herramienta dentro del código. Creeme que yo vengo puteando con Mecanim desde hace años, y todos los problemas (excepto los más estúpidos y fáciles de solucionar) tienen su vuelta. Te recomiendo lo de las prioridades y las fuentes de interrupciones.

Finalmente, liberamos la herramienta! pueden acceder a ella totalmente gratis! http://www.modelatorsystem.com

Estoy leyendo el libro "Unity Game Optimization" que está en Packt y la tercera edición es de noviembre de 2019. He hecho un resumen de los apartados dedicados a scripting que me parecen muy buenos. Algunos los conoceréis, otros no y otros es posible que no supiérais porqué utilizar una manera u otra. En todos los casos el concepto de optimización ve sus frutos cuando es un desarrollo de cierto tamaño. Desde mi punto de vista, si empiezas con buenos hábitos, luego no tendrás los mismos problemas de rendimiento que el resto de desarrolladores. La optimización se debe realizar desde el día 1. Paso a relatar. Optimización 1 Eliminar las callbacks vacías de Start() y Update() al crear un script si no son necesarias. El tenerlas afectará a la inicialización de la scene y al instanciar prefabs. La de OnGUI() es especialmente problemática ya que puede llamarse más de una vez por frame. En la de Update() se realiza un Native-Managed Bridge, o sea, hay que enlazar el modo managed de C# con el del código nativo dependiente de plataforma. En general no dejar nunca una callback vacía. Optimización 2 Cómo obtener los componentes de un GameObject. Hay tres maneras de hacerlo, aunque a la práctica se utilizan dos de ellas. Los datos hablan por si mismos para 30.000 objetos. // 6413 ms test = (TestComponent)GetComponent("TestComponent"); // 89 ms test = GetComponent<TestComponent>(); // 95 ms test = (TestComponent)GetComponent(typeof(TestComponent)); El mejor es del uso del template o tipo genérico. Como en C++ ;) Optimización 3 Cachear los GetComponent, preferiblemente en el Awake. Esto es realmente crítico si se realiza en el Update. Al final obtendremos un mejor rendimiento a cambio de un coste de memoria mínimo (entre 32 ó 64 bytes por item dependiendo de la plataforma). Optimización 4 El uso de funciones dentro de Update. Si las acciones no requieren se llamadas en cada frame es mucho mejor convertirlo a un InvokeRepeating que puede llamarse en el Start y cancelarse en el OnDestroy: private void Start() { InvokeRepeating("ProcessAI", 0f, _aiProcessDelay); } Optimización 5 La comparación de objetos null. La llamada directa de "gameobject == null" genera una conversión Native-Managed Bridge con la consiguiente sobrecarga. Es mucho mejor utilizar el ReferenceEquals que no utiliza la conversión. Por eso se incluyó en Unity: if (!System.Object.ReferenceEquals(gameObject, null)) { // No es null } Optimización 6 La comprobación con Tag directa genera memoria adicional y hará actuar al GC posteriormente. Utilizar el CompareTag no utiliza memoria ya que evita el Native-Managed Bridge completamente y tarda la mitad de tiempo: // Asignación de memoria y GC. Tarda el doble de tiempo if (gameObject.tag == "Player") { // realizar acción } // Evita el Native-Managed Bridge totalmente. No asigna memoria adicional if (gameObject.CompareTag ("Player")) { // realizar acción } Optimización 7 Dictionary vs List. Las List son mejores para iteraciones. Los Dictionary son mejores para búsquedas aleatorias. El Dictionary es peor para las iteraciones debido a que debe realizar una comparación hash para cada uno de los elementos. De todos modos tener los dos tipos en algunas situaciones no es mala idea. Optimización 8 La Transform. Cuando instanciamos un nuevo GameObject con GameObject.Instantiate(), uno de sus argumentos es el componente de la Transform del parent que queremos asignar, que por defecto es null y colocará el GameObject en el root. Todas las Transforms que está a nivel root necesitar crear un buffer de memoria para poder almacenar los children que tienen más aquellos que vendrán después. Esto no ocurre con las Transforms que son child. Pero si una Transform en root le cambiamos el parent una vez creada y la reasignamos, se procederá a descartar el buffer de memoria que iniciamos en el Instantiate. Para evitar esto es mejor proveer del parent en la función. Otro apartado interesante es que, hay una propiedad en la Transform llamada hierarchyCapacity. Si somos capaces de estimar el número de Transform child de este objeto root, podremos reducir el número de asignaciones de memoria. Optimización 9 World Position, World Rotation, World Scale. Cuánto más profundo esté en la jerarquía un objeto mayores cálculos son necesarios para determinar el resultado final de su estado. Esto significa que es mucho más eficiente utilizar los elementos de Local que de World. Optimización 10 Cambios en la Transform. Si es posible, agrupar todos los cambios en una Transform y no realizarlos hasta el final de todos los cálculos y en FixedUpdate. Esto evitará movimientos extraños o teleportaciones de los objetos debido a que Unity lanza eventos internos cada vez que una Transform es modificada. private bool _positionChanged; private Vector3 _newPosition; public void SetPosition(Vector3 position) { _newPosition = position; _positionChanged = true; } private void FixedUpdate() { if (_positionChanged) { transform.position = _newPosition; _positionChanged = false; } } Optimización 11 SendMessage y Find. El método SendMessage() y la familia de métodos GameObject.Find() so especialmente costosos y deben evitarse en su totalidad. El método SendMessage() es como 2,000 veces más lento que una simple llamada a una función, y el coste de Find() se escala pobremente según la complejidad de la scene aumente ya que tiene que iterar por todos los GameObject de la misma. Optimización 12 No solamente Occlusion Culling/Frustum Culling. Para los objetos que solamente tienen renderizado es factible utilizarlas únicamente. Otros objetos que utilicen cálculos internos de manera constante continuarán consumiendo a pesar del Culling. Una buena solución a este problema es utilizar las callbacks OnBecameVisible() y OnBecameInvisible(). Como los nombres dicen, estas callbacks son invocadas cuando un objeto renderizado se ha vuelto visible a una cámara o invisible respecto a todas las cámaras de la scene. Además, cuando hay múltiples cámara en la scene (por ejemplo en un juego multiplayer) las callbacks son solamente invocadas cuando es visible para una cámara o invisible para todas ellas de igual modo. Esto significa que las callback serán llamadas en el momento preciso que se necesitan. Si nadie puede ver el objeto se llamará a OnBecameInvisible(), si como mínimo un player puede verlo se llamará a OnBecameVisible(). Optimización 13 Distance vs sqrMagnitude. El cálculo de raíces cuadradas para las CPU implica bastante proceso comparado con otras instrucciones. Cuando tengamos que utilizar un cálculo de distancia, y si no requerimos de una precisión extrema, es mejor utilizar sqrMagnitude y valor a comparar por su potencia de 2. // Utilizar la raíz cuadrada en Distance() float distance = (transform.position – other.transform.position).Distance(); if (distance < targetDistance) { // dentro de distancia } // No realiza el proceso anterior float distanceSqrd = (transform.position – other.transform.position).sqrMagnitude; if (distanceSqrd < (targetDistance * targetDistance)) { // dentro de distancia } Optimización 14 Datos de Prefab a un Scriptable Object. Si tenemos muchos diferentes tipos de Prefabs que contienen datos que pueden compartirse entre ellos, como fuerza, velocidad, puntos, etc. entonces todos estos datos serán serializados en cada Prefab que luego se instancie. Una mejor solución es serializar estos datos en un ScriptableObject. Esto reduce la cantidad de datos a serializar en el Prefab, el tiempo de deserialización y el tamaño del Prefab en sí mismo reduciendo el tiempo de acciones que serán repetitivas. Optimización 15 Update(). Una mejor solución al problema del Update() es no utilizar nunca, o mejor dicho, una sola vez. Cuando Unity llama al callback Update(), o cualquiera relacionado, cruza la ya comentada frontera del Native-Managed Bridge que es una tarea costosa en términos relativos. En otras palabras, el coste de procesamiento de 1.000 Update() independiente será mucho más costoso que la ejecución de un Update() con 1.000 funciones. Para poder minimizar este problema es mejor agrupar todos los Update() en un solo Update() global que luego llame a las diferentes funciones que requieran la acción.