Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 04/15/2020 in all areas

  1. 7 points
    En la anterior entrada hablé sobre trigonometría, repasando las razones trigonométricas y viendo el teorema de pitágoras. Si no lo recuerdas o has llegado nuevo aquí, míralo antes de continuar (enlace debajo). Trigonometría Vectores Matrices Funciones Introducción Si estás familiarizado con motores de videojuegos como Unity, conocerás el concepto de vector ya que se usa habitualmente. Pero ¿qué es realmente un Vector? Un vector básicamente es una flecha que apunta en una dirección y que tiene una longitud concreta: Esto sería un ejemplo de un vector y cualquier flecha apuntando en cualquier dirección sería otro ejemplo. Pero ¿cómo representamos esto? Para poder hacerlo tenemos que llevarnos nuestro vector a un sistema de coordenadas (x e y) y establecer el origen del vector en el centro del sistema. Por si no recuerdas que era un sistema de coordenadas, es una forma de visualizar un punto en el espacio. En este caso el espacio es 2D por lo que se representa con dos líneas, una horizontal (representado por el valor X) y otra vertical (representado por el valor Y) que se cruzan en un punto, llamado centro: Así quedaría nuestro vector anterior dentro de un espacio de coordenadas. Esto, por ejemplo, podría representar el movimiento de una nave en su proceso de despegue. Comienza en la posición (0,0) y sigue en la dirección del vector hasta llegar a su objetivo. Teniendo en cuenta que X es el valor horizontal e Y el valor vertical, el vector sería (2,1) Pero ¿qué podemos hacer con esto? Como has visto puedes representar movimientos con ellos, por ejemplo. Pero para ver de forma práctica su uso vamos a usar Unity3D. Cualquier versión te servirá para este propósito puesto que solo vamos a tocar código básico. En mi caso usaré la versión 2020.1. Si usas otro motor la teoría sigue siendo válida pero tendrás que buscar la forma de adaptarlo por tu cuenta. Unity internamente usa vectores para colocar un objeto dentro de la escena (realmente esto es incorrecto ya que usa una matriz, pero no nos adelantemos). Si vas al componente Transform (crea un gameobject nuevo si no tienes ninguno) te encontrarás con este Vector3 (un estructura propia de Unity) que contiene 3 valores: Estos son la posición en X,Y,Z. Pero ¿pero qué son estos valores? Pues al igual que la gráfica anterior nos indican que desde el centro del mundo hasta la posición de este objeto el vector es (0,0,0). Vamos a ver qué podemos hacer con esto. Para ello creamos un objeto de nombre Player y otro de nombre Target. Los colocamos en diferente posición y le asignamos diferentes iconos para poder diferenciarlos: Recuerda que puedes cambiar el icono en la siguiente pestaña: Una vez hecho esto vamos a crear un nuevo script de nombre Player y lo vamos a añadir al objecto Player. En este script vamos a añadir una variable Transform pública de nombre target y vamos arrastrar nuestro Target a través del inspector. Con esto tendremos acceso al vector de posición del Target desde nuestro Player. Ya tenemos acceso a los dos vectores de posición, el del personaje y el del objetivo. Sabiendo esto ¿cómo hacemos que el personaje se mueva hacia el objetivo usando vectores? Pues aquí llega la parte interesante ya que si restas el vector de posición del objetivo con el vector de posición del personaje, el resultado es el vector necesario para llevar el player al objetivo. Veámoslo gráficamente creando la siguiente función: Si pulsamos play al añadir este código, veremos cómo el personaje se mueve hasta la posición del objetivo. Vale parece que se mueve, pero quiero más. ¿Que tal si medimos la distancia que hay entre uno y otro antes de moverlo? Para esto vamos a recordar la trigonometría que aprendimos en la parte anterior. Magnitud La magnitud de un vector es la distancia que hay entre dos puntos. En nuestro caso sería la posición del personaje y nuestro objetivo. Para calcularla solo tenemos que aplicar la fórmula de la distancia. Esta fórmula es simplemente el teorema de pitágoras disfrazado, y lo vamos a ver en la siguiente imagen: Como puedes ver, nosotros lo que queremos calcular es la distancia (h) por lo que podemos convertirlo en un triángulo añadiendo X e Y. Ahora solo tenemos que usar pitágoras para despejar h. ¿Lo recuerdas? Vamos a resolverlo en código. Para ello vamos a crear una clase estática nueva llamada BasicMath donde vamos a ir añadiendo nuestras funciones matemáticas a partir de ahora. Seguiremos usando Mathf (Unity) o Math (System) para realizar las operaciones básicas que se salen del objetivo de este tutorial. Mencionar que todos los cálculos e igualdades que haremos aquí serán basados en 2 dimensiones. Una vez se han entendido correctamente los cálculos, solo hay añadir la componente z. Esta sería nuestra implementación del teorema de pitágoras. Para ver la distancia simplemente podemos añadir un log en nuestra función MoveToTarget: Si estás familiarizado con Unity ya sabrás que por defecto nos soluciona todos los problemas de vectores con su estructura Vector. Podemos acceder directamente a la magnitud de un vector desde dentro del mismo de la siguiente forma: Como puedes ver, ambos resultados son iguales, aunque nuestra implementación es menos óptima que la que usa internamente Unity. Por lo que esta clase BasicMath y todo lo que contenga es únicamente para uso educativo. La magnitud tiene un pequeño problema y es que hacer una raiz cuadrada es algo costoso a nivel computacional. Por eso habitualmente se usa el valor antes de pasar por la raiz cuadrada. Seguirás teniendo un valor que representa la distancia pero será más eficiente. Podemos crear esta implementación de la siguiente forma y equivale al SqrMagnitud de la clase Vector: Esto es genial, tenemos al personaje moviéndose al target y conocemos su distancia hasta él. Pero no queremos que el player avance directamente hacia el objetivo, sino que lo haga poco a poco a la velocidad que nosotros queramos. Para esto vamos a necesitar normalizar nuestro vector. Normalización Normalizar un vector es cambiar su longitud a 1, manteniendo su dirección. En nuestro caso de ejemplo, el vector “dir” que tenemos. Al cambiar su longitud a 1 podemos controlar la velocidad de movimiento mediante un valor multiplicador. ¿Cómo calculamos el vector normalizado (no confundir con el Vector normal)? Dividiendo el vector por su magnitud: Podemos implementar rápidamente esto en nuestra clase BasicMath: Podemos ver que equivale al valor normalized de la clase Vector: Una vez tenemos el valor normalizado, podemos multiplicarlo por un valor y hacer que el personaje se mueva en función del tiempo: Vamos a tener que pasar nuestra normalización a Vector3 ya que estamos trabajando en dos dimensiones y la posición añade la Z (aunque como este caso sea 0). Si modificamos el valor speed podremos hacer que el personaje cambie su velocidad al moverse a través del vector. Antes de continuar me gustaría darte otra forma de mover un vector de un punto a otro. Pero en lugar de basado en la velocidad, basado en un valor comprendido entre 0 y 1. Cuando el personaje está en su posición inicial, el valor es 0 y cuando llega a su objetivo es 1. Esto es llamado interpolación (Lerp). Interpolación Para interpolar un vector simplemente vamos a sumarle al vector inicial, el vector de dirección al objetivo por un valor t (comprendido en 0 y 1). Veámoslo en código: La primera línea limita la t entre 0 y 1. La segunda simplemente suma al vector de origen, el vector dirección multiplicado por t. Si la t es cero devolverá el valor “a” y si es 1 devolverá el valor “b”. Con el siguiente código podremos probar esta funcionalidad nueva: Tenemos que crear un valor t (el atributo Range nos ayudará a limitarlo entre 0 y 1) y un Vector3 que guarde la posición inicial. Esto es necesario porque si le pasamos la posición actual al Lerp los resultados se irán actualizando al ir moviéndose y el resultado no será el que buscamos. Comentamos la anterior MoveToTarget y añadimos la nueva en la función Update. De esta forma si pulsamos Play tendremos un valor t en el inspector que si vamos moviendo entre 0 y 1 hará que nuestro player se desplace más o menos cerca del target. Hay otros tipos de interpolación que veremos en el apartado de Funciones en próximas partes de este tutorial. Una vez tenemos esto, vamos a pasar con una de las operaciones con vectores más importante. Producto Escalar El producto escalar (dot) es una operación entre dos vectores que nos devuelve un valor. Este valor nos da información muy útil sobre estos dos vectores: Si este valor es cero: el ángulo entre los dos vectores es 90 grados por lo que son totalmente perpendiculares. Si este valor es negativo: el ángulo es mayor a 90 grados. Cuanto menor sea este valor, mayor será el ángulo. Si este valor es positivo: el ángulo es menor que 90 grados. Cuanto mayor sea este valor menor será el ángulo. Aquí puedes experimentar visualmente con estos conceptos: https://www.fisicalab.com/apartado/producto-escalar La fórmula del producto escalar, siendo “a” y “b” dos vectores, es la siguiente: dot = ax * bx + ay * by Ya conocido el concepto vamos a practicar con él. Primero lo añadimos la función a nuestro BasicMath. Ahora añadimos la función Dot de testeo con lo siguiente: Esto calculará el producto escalar entre el vector del personaje y el vector de dirección. Como ves hemos utilizado el transform.up en lugar de la posición. Este valor indica la dirección del vector hacia arriba teniendo como referencia el tranform. Ya conocerás estos vectores si estás habituado a trabajar con Unity. Podemos verlos mejor aquí: Si usamos estos vectores a la hora de calcular el producto escalar, los resultados serán en función a la dirección y no en función de la posición. El vector de posición no nos indica hacia donde está apuntando, sino su posición con respecto al centro del mundo. Una posición por ejemplo de (3,4,0) no nos es útil para calcular el producto escalar, sin embargo el vector.up (0,1,0) sí, ya que es una dirección en este caso hacia arriba. También hemos normalizado los dos vectores antes del dot para que sea más fácil trabajar con el resultado. Activamos esta función en Update, comentando lo demás (puedes dejar el MoveToTarget si quieres). Si damos Play podemos ir moviendo el target y ver como va cambiando el producto escalar. Pero ¿de qué sirve conocer este valor?. Pues anteriormente vimos que este valor nos da información muy relacionada con los ángulos. De hecho podemos calcular el ángulo entre dos vectores conociendo los productos escalares. Ángulo Para calcular el ángulo tenemos la siguiente fórmula,siendo “a” y “b” vectores: θ = arcocoseno (dot(a, b)) Vamos a añadir esto a nuestro BasicMath. Este resultado estará en radianes por lo que crearemos dos funciones, una en radianes y otra que convierta el resultado a grados. Hemos normalizado ambos vectores antes de hacer el Dot. De esta forma lo hará desde dentro y podremos pasarle el vector sin normalizar. El valor Rad2Deg es el factor de conversión de radianes a grados que es 180 . Esto es un valor constante: No es necesario que añadas tanta precisión, puedes coger los decimales que quieras para este fin. Creamos ahora nuestra función Angle en el Player (puedes sustituir la función Dot ya que no la volveremos a usar). Volvemos a usar el Vector.up y añadimos la función al Update para verla. Para visualizar mejor el ángulo, voy a añadir en el OnDrawGizmos el siguiente código. Esto crea dos líneas que simular el comportamiento de los vectores. Si damos al play podremos ver dos líneas que forman un triangulo, el angulo entre las dos es el que nos está mostrando por consola: Con este valor de ángulos podrías, por ejemplo, rotar al personaje para que siempre mire al target con la función transform.Rotate. Con esto llegamos al final de esta entrada sobre vectores. Ha sido algo básico pero que sirve como punto de partida si quieres profundizar por ti mismo. Como he comentado estos cálculos son teniendo en cuenta solo 2 dimensiones. Te animo a que realices los cálculos añadiendo a las fórmulas una dimensión más. Podéis encontrar el código del proyecto aquí Recuerdo que no soy matemático y que los cálculos que aquí he realizado pueden contener errores o no ser del todo precisos. Cualquier duda o anotación siéntete libre de contactar conmigo. Nos vemos en la siguiente entrada.
  2. 5 points
    Cuando decidí dedicarme a crear videojuegos una de mis preocupaciones principales era mi escaso conocimiento matemático. Internet estaba lleno de mensajes asegurando que no es necesario saber matemáticas para crear videojuegos y aunque, pueda ser cierto en determinados casos, creo que aprender las nociones básicas te van a ayudar a saber lo que estás haciendo y sobre todo a construir mejores juegos. Como veréis no es necesario un conocimiento matemático avanzado para entender gran parte de los cálculos habituales. En esta serie de publicaciones voy a hablaros de algunos conceptos matemáticos básicos que se usan constantemente en videojuegos: Trigonometría Vectores Matrices Funciones Trigonometría La trigonometría, como su nombre indica (tri-tres; gono-ángulo; metría: medida), es la ciencia destinada al estudio de las medidas de los ángulos. Si por ejemplo quieres girar un personaje en tu juego necesitarás un ángulo de giro. Para poder medir un ángulo (o cualquier cosa en general) necesitamos una unidad de medida, vamos a ver las dos principales en el caso de los ángulos: Grado Cuando vas a comerte una pizza lo primero que haces (después de cocinarla claro) es partirla en diferentes trozos. Imagina que la cortamos en 8 trozos, siempre en 8 trozos porque nos encanta el tamaño de cada trozo. Si quisieras medir el ángulo de cada trozo podrías crear tu propia unidad de medida basada en tu especial devoción por los 8 trozos. Llamémosle pizzo a esta medida. Entonces si tu cortas tu pizza en 8 trozos, cada trozo tendría un ángulo de 1 pizzo. Podríamos pedir que se estableciera como medida oficial el pizzo pero me temo que ya tenemos una medida general que puedes usar en su lugar: el grado. Si en lugar de 8 trozos partimos la pizza en 4 trozos iguales y establecemos que cada trozo vale 90 grados, tendríamos la definición de grado. La definición es la siguiente: cada una de las partes que resultan en dividir en noventa partes un ángulo recto. Aquí podemos recordar los tipos de ángulos rápidamente. Radián Una vez hemos recordado la unidad familiar que es el grado, vamos a ver el radián que es el que usaremos de forma habitual. Pero antes de entrar en el radián, debemos conocer el número Pi. ¿Qué es Pi? El número Pi es uno de los más importante en las matemáticas. Su definición es la siguiente: Pi es la relación entre la longitud de una circunferencia y su diámetro. Pero ¿qué significa esto? Pues básicamente quiere decir que sí dibujamos una circunferencia de diámetro 1 y medimos su longitud, obtenemos Pi. Con esta imagen lo entenderás mucho mejor. Si pintamos el borde de una rueda de diámetro 1 y giramos mientras pintamos el suelo midiendo la longitud de la mancha de pintura, tenemos Pi, que es un valor constante (e infinito): 3.14159… De forma habitual se trabaja con radio = 1 en lugar de diámetro = 1. Por lo que la longitud de la circunferencia es este caso sería el doble de Pi (2 π). Como apunte este número es conocido como Tau y su valor es 6.28318… Pero, ¿qué relación tiene esto con un radián? Si seguimos con el ejemplo de la pizza anterior, imagina que te ha venido la inspiración y has cortado la pizza de tal forma que la longitud del arco de cada trozo que has partido mide exactamente 1. Vamos a verlo gráficamente: La pizza tiene radio = 1 y cortamos (no tendrías que cortarla realmente porque es minúscula pero bueno) un trozo cuya longitud de arco es exactamente 1 (arco azul en la imagen). Pues bien, el ángulo que se forma, nombrado “a” en la imagen, mediría exactamente 1 radián. ¿Que pasa si seguimos cortando trozos con longitud de arco 1? Pues tenemos que el ángulo que se forma con media circunferencia (“a” en la imagen) es π radianes. Y el de la la circunferencia completa sería 2π (Tau) radianes. Nota: los dibujos son solo explicativos, las distancias dibujadas no usan medidas reales. Seno, Coseno y Tangente Una vez conocemos el concepto de radián vamos a experimentar un poco con las circunferencias. ¿Qué pasaría si formamos un cuadrado cortando el eje x e y de la siguiente forma? ¿Como calculamos el valor de “x” y de “y”? ¿Que son x e y? Pues aunque resulte sorprendente esos valores son el seno y el coseno del ángulo “a”: La definición nos dice que el coseno de "a" es la abscisa de su punto asociado y el seno de a es la ordenada de dicho punto. Creo que es mucho más entendible con la imagen anterior. A medida que el ángulo cambia, sus valores en x e y modifican su valor. Aquí podemos verlo mejor: La tangente como ves es la recta que toca en un solo punto la circunferencia en función del ángulo. Teorema de Pitágoras En este punto vamos a hablar de otro término muy importante en matemáticas y que usaremos en los siguientes publicaciones, el Teorema de Pitágoras. Este teorema dice que dado un triángulo rectángulo, podemos relacionar su hipotenusa(h) con sus lados (x e y) de la siguiente forma: Despejando tendríamos: ¿Pero qué uso tiene esto? Pues en el siguiente episodio hablaremos de su uso con Vectores. Imagina que tienes un personaje en un escenario y quieres saber a cuánta distancia está un determinado enemigo. Deberás plantearlo con el teorema de pitágoras, donde la “h” es la distancia entre tu personaje y el enemigo. Tendrías que calcular la “x” e “y” para posteriormente poder despejar “h”. Pero vamos a verlo con un ejercicio simplificado: Imagina que tenemos el siguiente triángulo. Para calcular h haríamos lo siguiente: ¿Y si quiero conocer el ángulo? Para conocer el ángulo necesitamos profundizar nuestro conocimiento en las razones trigonométricas. Vamos a verlo siguiendo el mismo ejemplo: Para calcular θ vamos a necesitar calcular primero el seno del ángulo. Pero ¿cómo hacemos esto sin conocer el propio ángulo? Anteriormente vimos que: Esto es así siempre y cuando el radio (la hipotenusa) fuera 1. Pero ¿qué pasa si como en este caso la hipotenusa es 7.81? Solo tendremos que dividir la variable entre la hipotenusa de la siguiente forma: Vale ya sabemos calcular el seno sin tener el ángulo: Una vez tenemos el seno necesitamos conocer el concepto de función trigonométrica inversa. No os asustéis porque el concepto es muy simple. Necesitamos algo que multiplicado por el seno (que ya lo conocemos) nos de el ángulo. Veremos más a fondo este término cuando veamos las matrices. En este caso las función trigonométricas inversas las conocemos y son las siguientes: Nota: en español también se les llama cosecante (arco seno), secante (arco coseno) y cotangente (arcotangente) Ya conocemos cómo obtener el ángulo: Ya tenemos el valor en radianes del ángulo. Si necesitamos pasar de radianes a grados, podemos usar las siguientes fórmulas: Aquí podemos ver gráficamente las razones trigonométricas que hemos visto aquí: Espero que os sea de ayuda y perdonad si he cometido algún error o he explicado algo de forma muy torpe. No soy ni mucho menos un experto matemático, mi intención es que todos podáis acercaros y verlas un poco más fácil. Cualquier duda estaré encantado de ayudar. En la próxima parte veremos Vectores y pondremos en práctica todo lo aprendido aquí pero dentro de Unity. Hasta la próxima.
  3. 5 points
    Finalmente, liberamos la herramienta! pueden acceder a ella totalmente gratis! http://www.modelatorsystem.com
  4. 5 points
    Hola chicos, comparto con vosotros una implementación de ruido perlin noise con fBm para todos aquellos que esteis interesados. Si necesitais generación procedural de contenido, con esto solamente necesitais llamar a una función. Además las plantillas de ruido se guardan como Scriptable Object. Os dejo imagenes de las demos que incluye con ejemplos de uso, dependiendo del caso: link: https://github.com/davilopez10/PerlinNoise_Unity3D Perlin Noise 1D Perlin Noise 2D Perlin Noise 3D
  5. 5 points
    Hola, He creado unos pocos vídeos de programación básica de NPC's, o programación de NPC's básicos. La intención es ir creando mas de esta tématica, sin obligación, y de tanto en tanto, pero irlos agrupando en la misma lista de visualización de youtube: Aquí os la dejo: Por ahora hay tres vídeos, o 2.5 por que el último es un poco ampliación del primero. -Como crear NPC's en Unity que te siguen. -Creamos un centinela con Waypoints en Unity, -Como hacer un NC persiga y huya en modo pánico. Ya ire informando de nuevas incorporaciones a la lista 🙂
  6. 4 points
    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]
  7. 4 points
    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.
  8. 4 points
    He escrito una pequeña guía/hoja de ruta para alguien que quiere empezar en el desarrollo de videojuegos, o seguir mejorando en los primeros niveles. La idea es que sirva de referencia para orientarnos un poco ya que cuando empezamos puede ser difícil saber por dónde empezar y cómo seguir avanzando. Aquí os dejo la versión en texto con más detalles: https://thepowerups-learning.com/como-empezar-en-el-desarrollo-de-videojuegos/ Y aquí abajo la versión en vídeo: ¡Espero que os sirva! ¡Un abrazo! Dani.
  9. 4 points
    Buenas! soy Augusto de Chime Ayer comencé un canal dedicado a Unity y C# y largue con una serie de introducción a la programación en Unity. En el primer episodio simplemente vemos como instalar UnityHub y Visual Studio para dejar todo listo para el siguiente episodio: En el segundo creamos nuestro primer Hola Mundo en Unity, y vemos el concepto de variables con varios ejemplos. Ademas hice otro video suplementario que cubre varios temas básicos como para tener una buena base en Unity antes de empezar la serie Espero que les guste el contenido, voy a estar subiendo los siguientes capitulos a lo largo del mes!
  10. 4 points
    Hola, he creado un pequeño curso de introducción a los MLAgents. En total son nueve vídeos, donde se crean dos proyectos y un minijuego. El primer proyecto es muy sencillo, para no perder tiempo en nada que no sea el funcionamiento / configuración de MLAgents. Como seguir estas cosas por las listas de reproducción de youtube se me hacen complicadas me he liado la manta a la cabeza y he creado una pequeña WEB donde se puede seguir el curso, como si de una academia online se tratara, y acceder a los scripts y ficheros necesarios. La URL del curso es: https://cursos.uadla.com/curso/introduccion-al-machine-learning-con-ml-agents-para-unity/ Si alguien lo sigue por aquí, por favor, que me comente si el sistema funciona correctamente y es como de de usar. Os dejo también el vídeo de presentación: Espero que os guste, la verdad es que es un tema que me ha gustado de siempre, espero tener tiempo para ir haciendo cursos para tratarlo en más detalle y con entornos más complejos. También hay que tener en cuenta que ahora los MLAgents empiezan a estar mas o menos maduros, y sí que veo que empiezan a ser una forma de entrenar NPC's que podemos usar en nuestros juegos.
  11. 4 points
    hola he visto este video en un post de Vandal y no he podido resistirme a compartirlo era de una jam que se ha celebrado entre el 10 y el 12 de julio... ...o de unos locos que se han escapado de un psiquiatrico... no me ha quedado muy claro...
  12. 4 points
    Muchos lo sabréis y otros no, pero hay una lista de recursos bastante tocha hecha en zeef.com de recursos para el desarrollador de videojuegos. Espero que os sea de utilidad! https://game-development.zeef.com/daniel.cuadrado.gonzalez
  13. 4 points
    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.
  14. 4 points
    Mmm no lo se Rick, parece falso ... Tampoco lo entenderías (sin ser peyorativo), primero porque esto no se explica así. Además de que la pregunta suena a "atajo", que ya es algo incómodo para la persona que pretende ayudarte. No estaría tan seguro de eso, me explico... En mi tiempo en la facultad tuve la suerte de cruzarme con profesores bien hijos de puta, que si les preguntabas algo que estaba en el libro (cosas muy obvias claro) te humillaban (un poco en joda) en frente del grupo. En realidad estaban incentivando a tres cosas muy importantes: Que el alumno siente el culo en la silla, que sepa usar el material disponible (es decir, leerlo al menos). Que el alumno no suelte la lengua por cualquier cosa en clase. Es decir, hay que estar algo preparado (o al menos entender el tema previo) antes de hablar por hablar (sí, había algunos que paraban la clase como 15 veces por día). Que en una consulta, el tiempo empleado realmente valga la pena (para ambos, alumno y profesor). Todo esto desemboca en el respeto al otro (falta de respeto no es necesariamente insultar al otro, aunque podría pasar). Así que, imaginate lo que un "master" siente cuando lee "Si tubierais la amabilidad de hacer un pequeño script... algo fácil de entender" de un tema super básico (que es la base de), y super bien explicado y ejemplificado en casi cualquier medio (blogs, tutoriales, documentación, libros, videos, Unity, etc) como lo son las 👉 clases 👈. Esto a mi me dice que de tu lado estás haciendo cero esfuerzo, y que yo tengo que laburar por vos. Es una relación unidireccional. Si esto pasa seguido, lo más seguro es que empiecen los comentarios un poco desagradables, se empieza a notar ese roce poco a poco. Lo más loco es que seguramente que no surja de malas intenciones tuyas, pero sin darte cuenta estás provocando exactamente esto (y más acá que nos conocemos todos). Mi consejo (en general): Limitar las preguntas (vos mismo dijiste que hacías una tras otra --> "... por aquí mas de un año y sigo haciendo las mismas preguntas idiotas. ") Apuntarlas a algo en concreto, que no sean "Haganme un script que explique el origen del cosmos" ... Por ej: "¿En qué contexto debería utilizar una clase en Unity? Por qué no utilizar una struct para esto?" Preguntar por recursos de ser necesario, si no sabes donde buscar está perfecto. El hecho de preguntar por recursos le dice a quien te ayuda que por lo menos te esforzas en investigar antes. Que no se mal interprete, es no es una evaluación ni nada por el estilo (aunque pueda sonar a una cuando digo "desmuestra a quienes te ayudan tal o tal cosa"). Por ej, yo no sé nada de VR o XR (ni siquiera sé la diferencia entre estos 😆), pero sé que @iRobb la tiene clara (podría decir lo mismo de Networking y @francoe1 ). Sería super irrespetuoso de mi parte inundarlos de preguntas a la primera (ya sea directamente o creando un hilo), por lo menos me dedicaría una semana a investigar por mi cuenta (de ser posible). En caso de no llegar a nada, o verme realmente perdido, bueno ahí sí acudiría a ellos, mencionando mis logros en lo que respecta al tema, mis avances, dónde investigué, qué documentación visité, etc. En fin, mi opinión.
  15. 4 points
    Hola @nomoregames, primero que nada decirte que esto no es con ánimo de ofender ni de crear controversia. Este tipo de dudas son básicos de la programación, no es algo de unity sino de el lenguaje. Yo te aconsejo leerte un libro de c# o hacerte un curso donde aprendas al menos lo básico y no andes dando palos de ciego hasta encontrar la respuesta. No me molesta para nada que hagas estas preguntas, pero me parece que se crea contenido innecesario, soy consciente de que nadie nace sabiendo pero si no nos intentamos educar seguiremos en ese bucle de por vida. Digo esto por tu bien y por el entusiasmo que veo que tienes con la creación de videojuegos, puedes explotar ese potencial. Hay muchos cursos de programación en Youtube, también puedes utilizar webs como codeAcademy o KhanAcademy que son gratuitas y super buenas. Es un mundo muy bonito y que si le echas ganas puede sorprenderte más de lo que imaginas.
  16. 4 points
    Me alegro de que os guste!! Si tenéis cualquier duda, estoy por aquí (pero en el Telegram suelo contestar antes 😉).
  17. 3 points
    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.
  18. 3 points
    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.
  19. 3 points
    tienes que buscar un poco antes de preguntar, probar si puedes hacerlo mínimo 2 días y sino preguntas, tu pregunta esta en el manual lee un poco. URL: https://docs.unity3d.com/ScriptReference/Rigidbody-isKinematic.html Controla si la física afecta al cuerpo rígido. Si isKinematic está activado, las fuerzas, colisiones o articulaciones ya no afectarán al cuerpo rígido. El cuerpo rígido estará bajo control total de animación o control de script cambiando transform.position. Los cuerpos cinemáticos también afectan el movimiento de otros cuerpos rígidos a través de colisiones o articulaciones. Eg. puede conectar un cuerpo rígido cinemático a un cuerpo rígido normal con una articulación y el cuerpo rígido se restringirá con el movimiento del cuerpo cinemático. Los rigidbodies cinemáticos también son particularmente útiles para hacer personajes que normalmente son impulsados por una animación, pero en ciertos eventos se pueden convertir rápidamente en un ragdoll estableciendo isKinematic a false. using UnityEngine; using System.Collections; public class ExampleClass : MonoBehaviour { public Rigidbody rb; void Start() { rb = GetComponent<Rigidbody>(); } // Let the rigidbody take control and detect collisions. void EnableRagdoll() { rb.isKinematic = false; rb.detectCollisions = true; } // Let animation control the rigidbody and ignore collisions. void DisableRagdoll() { rb.isKinematic = true; rb.detectCollisions = false; } } este es un ejemplo básico solo para la colisión y estado muerto del enemigo, si quieres chocar al enemigo y que las físicas interactúe con el enemigo muerto tienes que hacer un Ragdoll del enemigo para desactivar la animación del enemigo y que cuando tenga 0 de vida se caiga y lo puedas mover cuando colisionas con el. public void Ejemplo(float amount) { if (health < 5) //este valor depende de cuanto daño le haces al enemigo., lo que dice es si vida es menor a 5 pasa a estado de muerte. { muerte(); } } void muerte() { Destroy(GetComponent<NavMeshAgent>()); // aca se desactiva la inteligencia Artificial. anim.enabled = false; //aca desactiva la animacion quedando solo el Ragdoll. } sino sabes que es un Ragdoll acá te dejo un link :"" https://www.youtube.com/watch?v=DInV-jHm9rk&t=1s¨
  20. 3 points
    necesito ayuda! no se si esto funcionara foreach (User _user in UnitySpainUserList) { _user.addMessage("felices fiestas"); }
  21. 3 points
    Hola! @Megadok para hacer ese uso es muy simple. Lo enums son tratados no solo con los nombre que les des(espada, arco,etc) sino que por defecto tiene un index asociado comenzando desde 0. Por lo que si queres que tu variable _arma sea igual a lanza por ejmplo solo tendrías que castear el tipo armas delante del index correspondiente a lanza(que sería 2). Te dejo un ejemplo. public enum armas { espada, //0 arco, //1 lanza, //2 hacha //3 } public armas _armas; private void Start() { //el casteo se hace poniendo entre parentesis el tipo que te interesa obtener _armas = (armas)1; //esto hara que _armas sea "arco" } //Con tu codigo seria asi string[] r = System.Enum.GetNames(typeof(armas)); for(int i=0;i<r.Lenght;i++){ _armas = (armas)i; }
  22. 3 points
    Este código lo hicimos en otro post. Pásale una List de elementos y te los posicionará de manera aleatoria: public void shuffle<T>(IList<T> list) { System.Random random = new System.Random(); int n = list.Count; for (int i = list.Count - 1; i > 1; i--) { int rnd = random.Next(i + 1); T value = list[rnd]; list[rnd] = list[i]; list[i] = value; } }
  23. 3 points
    hola a todos. acabo de subir un nuevo trailer a Youtube
  24. 3 points
    Acabo de subir el siguiente capitulo: Lógica y ciclos. En este video vemos la sentencia if, junto con else. Ademas vemos el ciclo for y el ciclo while. Y por ultimo vemos las sentencias continue y break para ciclos Edit: No quería spamear mucho el post así que agrego el siguiente episodio aqui. En este cuarto capitulo vemos varias cosas: Función Update, Físicas de Unity, Input del jugador, la función GetComponent, framerate-independence y como detectar colisiones entre objetos.
  25. 3 points
    si es el angulo z el que quieres comprobar en vez de "transform.forward.z" pon "transform.right.y"
  26. 3 points
    La Persistencia Cuántica de Bits o PCB. Es algo muy típico. 😂
  27. 3 points
    Hola Cerpion, Lo primero: No es terrible hacer referencia a otros scripts, pero en un mundo ideal, generalmente es preferible hacer referencias a abstracciones de tus scripts. Esto nos permite que sea más fácil reutilizar y cambiar nuestro código en un futuro. Ahorita me explico más: Supón que tienes un script llamado Player, y un script llamado Joystick, que a su vez tiene un método llamado GetMovement. Algo así: public class Player:MonoBehaviour { //Esta es una manera de obtener la referencia, aquí aparecería un campo para asignar el Joystick en el inspector: public Joystick playerJoystick; //La otra manera sería: private void Start() { playerJoystick = GetComponent<Joystick>(); } } public class Joystick:MonoBehaviour() { public Vector2 GetMovement() { //Supón que aquí regresaramos un movimiento de verdad en lugar de ceros. return new Vector2(0,0); } } Y eso funciona en general. Pero en un futuro tal vez vayas a querer tener players controlados por la computadora, o diferentes scripts para diferentes tipos de control, o qué sé yo que te depare el futuro. Para estar preparado para el futuro, y que te sea más fácil agregar y cambiar cosas, es mejor que nuestras referencias sean más abstractas, que Player en lugar de referirse a un Joystick haga referencia a, por ponerle un nombre, un MovementProvider. Hay dos formas de hacerlo. Una es con clases abstractas: public class Player:MonoBehaviour { //En lugar del Joystick, hacemos referencia a un MovementProvider, que puede ser un Joystick, pero también otra cosa que se te ocurra. public MovementProvider playerMovement; private void Update() { //Aquí usarías el vector que regresa GetMovement de para mover tu jugador alguna manera playerMovement.GetMovement(); } } //La palabra abstract aquí significa que el script no puede ser usado por sí solo, necesita que otro clase herede de ésta para usarlo. public abstract class MovementProvider:MonoBehaviour { //La palabra abstract aquí significa la funcionalidad de este método debe ser definida en las clases que hereden de ésta. public abstract Vector2 GetMovement(); } //Nota como no heredamos de MonoBehaviour esta vez, sino de la clase abstracta MovementProvider. //Cualquier otro script puede hacer lo mismo y definir su propia función para GetMovement public class Joystick:MovementProvider { //Override significa que estamos sobrescribiendo la funcionalidad definida en el padre, en este caso en MovementProvider. //Es cierto que, de hecho, MovementProvider no definió ninguna funcionalidad, lo dejó abstracto, pero igual hay que ponerlo. public override Vector2 GetMovement() { return new Vector2(0,0); } } Y dos es con algo llamado interfaces: public class Player:MonoBehaviour { public IMovementProvider playerMovement; private void Start() { //Como no podemos obtener la referencia a IMovementProvider desde el inspector, hay que obtenerla de otra manera. Puede ser así: playerMovement = GetComponent<IMovementProvider>(); //Si el componente está en otro GameObject, podríamos poner un campo de tipo GameObject en el inspector y luego: playerMovement = otherGameObject.GetComponent<IMovementProvider>(); } private void Update() { //Aquí usarías el vector que regresa GetMovement de para mover tu jugador alguna manera playerMovement.GetMovement(); } } //Las interfaces definen un conjunto de métodos y propiedades que debe implementar una clase. //La ventaja de las interfaces es que puede aplicarse más de una a la misma clase, la desventaja es que no salen en el inspector. //Es común poner una I en el nombre para identificar que es una interfaz. public interface IMovementProvider { Vector2 GetMovement(); } //Nota como avisamos que implementamos la interfaz. Si hay más interfaces, se pueden seguir agregando separadas por comas. public class Joystick:MonoBehaviour, IMovementProvider { //Con las interfaces no tenemos que usar override, basta que el método sea público. public Vector2 GetMovement() { return new Vector2(0,0); } } Respecto a tu segundo punto, generalmente, entre más puedas dividir tus scripts, mejor. La idea es que, entre menos cosas distintas haga un script, más probable es que los puedas reutilizar en varias partes diferentes. Y es menos probable que los tengas que modificar cuando otra cosa cambie en tu código. Cualquier cosa que quede sin explicarse bien, o cualquier duda, tú dime con confianza. Ahm, espero no haber sido demasiado teórico o demasiado confuso; esto de lo que hablé viene de unos principios de programación llamados SOLID, que son muy útiles como guía para facilitarte la vida, pero que luego uno no sabe explicarlos bien porque ya se acostumbró tanto que ya ni piensa en ellos. Por último, estas recomendaciones que te di, no dejes que te atoren mucho; se aprende haciendo y además, en esto de hacer juegos, todo mundo acaba haciendo montón de excepciones a este tipo de reglas. PD Eso del game manager y las referencias estáticas yo realmente te recomendaría evitarlo siempre que puedas. Hay razones para hacerlo, como si nomás es un prototipo rápido, o un juego móvil simple, o ciertas cosas que es mucho más complejo hacer de otra forma. Pero, generalmente, ese patrón de organizar tu código que algunos llaman singleton, acaba dándote muchos más problemas de los que arregla. En el momento en el que decides, por ejemplo, que tu juego es multijugador, tienes que ponerte a rescribir código en todos los lados que usan esa referencia estática, en código que escribiste hace mucho tiempo y que vas a tener que releer completito para entender cómo cambiarlo.
  28. 3 points
    la verdad que estan chulas las fisicas del cable. creo que esto no cuenta como spoiler del juego... o si? si es asi lo siento, cierrenme el tema. pero me gustaria devatir como creen qye funcionan esas fisicas. creen que la manguera esta formada por pequeñas secciones? o es mas bien varios raycast que dividen la manguera en secciones mas grandes cuando colisiona? y el tramo que tiene enrollado en la mano?? forma parte de la misma manguera? o es un objeto adicional para que de la sensacion de que se enrolla.... y miestras tanto la manguera original crece o disminulle su longitud en relacion con la parte que ha enrollado en la mano? ...claro que la parte que tiene enrollada en la mano tiene fisicas tipo "cloth".... pero no reacciona al escenario... eso es lo que me ha hecho pensar que son dos cosas distintas la manguera y lo enrollado... aunque tamvien cuando la lanza cambia un poco el comportamiento... creo que puede ser todo un unico objeto al que le cambian las "layers" de colisiones depemdiendo el momento ...y depemdiendo de que secciones de la manguera sean les ponen unas layers u otras... puede que todo sea una especie de "cloth" gigante... que cuando ha alcanzado su maxima tension (estirado) manda un mensage al personaje para que haga la animacion de "huy, ya no alcanza mas" ustedes que opinan?
  29. 3 points
    Hola gente les dejo un link a mi curso de youtube, totalmente gratuito y disponible para la comunidad. Esta totalmente actualizado al 2020 y hecho por mi, soy programador con titulo universitario y 10 años de experiencia en unity! El curso esta dividido en niveles de dificultad, Comenzando para gente que nunca toco unity y terminando con contenido muy avanzado como creacion de framework propios para multiplayer, entre otras cosas. Para que los usuarios mas avanzados puedan saltearse las partes que no les sirve y explorar mas fácilmente el contendio. Son mas de 200 videos, con muchisimas horas de grabacion que complete con la intención de subir a udemy. Al terminarlo cambie de parecer y ahora lo estoy subiendo de forma gratuita a youtube. Se sube 1 video cada dia de forma atomatica, y ya estan todos los videos seteados para subirse a youtube de forma automatica a este ritmo. Link: https://www.youtube.com/channel/UCl3p_fKnx2-GIUWVbiDAcMg Sin mas, espero verlos por mi canal y que les sirva el curso. Un saludo!!
  30. 3 points
  31. 3 points
    Y aquí estamos con más novedades. El "esperado" ciclo día/noche y cambio atmosférico dinámico:
  32. 3 points
    ¿Has probado a juguetear con los distintos parámetros que tiene el NavMeshAgent? https://docs.unity3d.com/ScriptReference/AI.NavMeshAgent.html En el siguiente vídeo de Brackeys muestra un poco alguno de estos parametros
  33. 3 points
    Hola! El curso tiene ya 3 niveles con un total de mas de 130 videos actualemte y aun quedan 3 niveles mas. los invito a que se unan, estoy empezando el nivel 4 del curso. saludos
  34. 3 points
    Espero que no se considere como spam, pero estoy grabando mis progresos aprendiendo Unity a través de un juego de cartas. Está claro que si lo veis las vacas sagradas, me atizais en el lomo, pero igual viene bien para los que son tan inutiles como yo. Pues eso. Aquí lo dejo, por si van apareciendo novatillos en esto. A darle duro.
  35. 3 points
    ¡Buenas! En este post @seimus comentaba sobre una herramienta para exportar un tilemap como PNG, y @pioj también estaba de acuerdo con la idea así que hice una pequeña herramienta y la subí al github. La verdad es que la he testeado muy poco pero en principio debería adaptarse a cualquier tamaño, yo la he estado testeando con sprites de 32x32. Os dejo un vídeo y el enlace a github! https://github.com/leocub58/Tilemap-to-PNG-Unity Espero les sirva de ayuda, yo la verdad es que lo he hecho por simple aburrimiento jajajaja. ¡un saludo!
  36. 3 points
    Buenas tardes a tod@s, Quería plantearos una nueva forma de organizar y mostrar contenidos de la web proporcionándole mayores interacciones y facilidad de visualización de contenidos. Actualmente el sistema foro, desde mi punto de vista, ha quedado limitado y no se adapta a las "nuevas exigencias" y hábitos de los nuevos usuarios que están llegando y que llegarán en el futuro. Los foros tienen una forma de distribución de contenidos basado en subcontenidos en el que el usuario debe ir navegando a través de diferentes topics/contenidos hasta llegar al apartado que le interese y donde se le indica que existe nuevo contenido a través del simple cambio de icono. Como todos sabréis estos últimos años han ido cayendo en desuso y es una realidad de que la mayoría de sistemas de foro integrados en páginas web se parecen más a lo que vemos en redes sociales que al estilo clásico que de hecho todavía se sigue utilizando en UnitySpain (aunque bastantes novedades como sistema de notificaciones). No nos engañemos, antes de que los foros se pusieran de moda como una forma de comunicación existían las listas de correos, las cuales hoy en día son una ventana al pasado y de lo que creo que los foros, tal y como los conocemos, les espera el mismo destino. Los nuevos usuarios, y los que vendrán los próximos años, están habituados a utilizar otros sistemas de comunicación muchos más versátiles, cargados y destacando contenidos multimedia por delante del simple texto y mostrando de forma ordenada "el contenido más nuevo" en detrimento de lo más antiguo para facilitar de un vistazo lo último publicado, comentado, etc. Es mejor mostrar un vídeo o una imagen de lo que acaban de publicar que el simple texto "este es mi proyecto rts", porque atrae mayor interés, o no, según el caso de lo mostrado. No es solamente una nueva forma de mostrar contenidos, sino que abre un nuevo abanico de posibilidades de interacciones entre los usuarios. Ciertamente el foro actualmente tiene algunas funcionalidades que podríamos calificar de sociales, pero la forma de distribución de contenidos no se asemeja a lo que está demostrado que funciona, que incentiva a la comunicación entre usuarios y que mantienen una conexión constante a la web. Podría detallar cada una de las nuevas funcionalidades o estilos de contenidos a los que hago referencia, pero creo que todos conocemos y reconocemos la utilidad de redes sociales como Twitter o Facebook. Cada usuario tendría su propio espacio (estilo muro o blog), podría subir archivos e imágenes y disponer de su propio portafolios y unirse y crear grupos, los cuales podrían sustituir a lo que actualmente conocemos como cada foro. La página principal mostraría directamente los últimos contenidos publicados, comentarios y actividades, no teniendo el usuario que navegar entre subcontenidos para encontrar lo último publicado (siendo algo más llamativo que el recent topics). No digo que este sistema de comunicación y muestra de contenidos sea mejor, sino que es diferente y se adapta a lo que hoy es el resto de la WWW. Por todo ello, creo que podríamos plantearnos cambiar el foro por un sistema como el que os comento utilizando software como Buddypess, elgg u otro que cumpla la misma función. A continuación os dejo algunas imágenes y enlaces para que podáis ver algunos ejemplos de lo que os he relatado. Espero vuestros comentarios sobre esta idea y el debate que aquí se abra. Esto no quiere decir que sea un debate para cambiar lo existente sí o no, sino de abrir esta posibilidad y comentar los pros y los contras del posible cambio. https://olympus.crumina.net/members/dan_cortese/friends/ https://buddy.ghostpool.com/ http://themekitten.com/demo/atlass2/activity/ https://seventhqueen.com/themes/kleo/members/kleoadmin/groups/
  37. 3 points
    Lo primero es aclarar que con este post no pretendo ni faltar, ni empezar ningún tema de discusión, ni causar ningún tipo de enfrentamientos, pero este tipo de cosas me gusta poder expresarme claro, sin ningún tipo de tapujos.Como digo en algunos de mis post...vayamos por parte como dijo el tito jacky. Como bien comenta francoe1 esta conclusión no quiere decir que no compartimos opiniones. peor referente a este post hay algunas cosas desde mi punto de vista que no comparto. 1-Desuso Referente a este punto te puedo asegurar que estas totalmente equivocado, ya que las mayores comunidades y las mas seguras que existen tanto publicas como privadas en el world son el 70% foros, que suelen estar modificados y actualizados por los propios usuarios, incluso yo diría muchos mas antiguos que este sistema de foros, otra cosa es que le buscador de del señor GOOGLE te cape el mas del 75% de todo el internet, para que solo te centres en la moda que suele usar la gente. Vamos... hablando claro y sin faltar al respeto de nadie....es para hacer borregos. Un poquito de humor nunca viene mal. XD -El motivo principal de usar cosas simplificadas es muy fácil.(Menos módulos menos problemas y mas fluidez) simplemente hay que saber usar la herramienta y saber que función tiene, y no pase como esta pasando ahora que tengo amigos con carreras terminadas de informática y no saben que es un disco de 5 y 1/4.(y eso desde mi punto de vista es muy triste) -Por lo que en general contra menos módulos y menos chorradicas tenga mucho mejor, siempre y cuando cumpla la función para la que se usa. 2-Forma de comunicación. -En este tema también te equivocas, pero no lo voy a ampliar porque la verdad no viene al caso para el hilo del post. 3-Lista de correo -Referente a la comunicación de listas de correo no es que estén en desuso para mandar o recibir información, si no todo lo contrario, la única diferencia es que para chorradicas y tonterías ya tenemos el wasap, dejando los correos en una posición mucho mas seria y personal a la hora de comunicarse con alguien. 3-"Simple texto" Aquí reafirmo lo comentado anteriormente con la frase de Joseph Goebbles ministro de propaganda de la Alemania nazi " Una Mentira repetida mil veces...se transformara en verdad" 1 Imagen = 1000 palabras. 1 vídeo = 1000 imágenes. Por lo que la deducción es........... -Con esto no implica que se usen imágenes o vídeos para mostrar o explicar las cosas, pero eso no quita que sea mejor que el texto, simplemente es una herramienta mas que bien usada puede ayudar mucho a la hora de realizar ayudas o comunicaciones, pero solo eso....ayudas en conjunto al texto. 4-Mejor mostrar un vídeo??? Creo que es este caso esta claro, por norma general cuando alguien pide ayuda en algún tema, que es lo que mas se suele usar este tipo de foros desde mi punto de vista, necesitas ayuda a ser posible para ayer, por lo que ponerse a montar un vídeo para una ayuda, sinceramente es una estupidez y una perdida de tiempo ya que casi todo esta en joutube (No se pierde nada por mirar en jotube antes de preguntar por aquí algún problema). Dejando el foro para ayudas o información mas técnicas, le da una profesionalidad que dejaría de tener si nos ponemos a poner corazoncitos y chorradas cada 3 por 4. 4-Demostrando que funciona? Referente a que las redes sociales que comentas como facebook y twitter recordar que las redes sociales "No son foros" las redes sociales son para una cosa y los foros son para otra totalmente distintas. 5-Portafolios propios. -Aquí mas que aclarar una cosa, ya que yo también creía que esa opción podría ser buena en las comunidades hace tiempo, destacar que los portafolios personales en este tipo de comunidades no suelen ser prácticos y dan mareos de cabeza. Para eso ya hay paginas que se dedican a ese tipo de cosas como puede ser arstation, pinterest etc... No es por el echo de subir las cosas en un foro, es simplemente que esa pagina se dedica a eso, por lo que pagara su cuota a los motores de búsqueda para salir en la sección de imágenes de Google, Firefox, etc.. y si lo que te interesa es tener algun tipo de difusión publica, tendrás muchas mas opciones si usas las plataformas que ya hay. Opinión personal referente al foro. -Bueno y ya por ultimo, yo la verdad es que el foro lo veo bien tal y como esta,ya que para mi la función principal la cumple, que se vayan añadiendo alguna que otra cosa que vean los administradores que pueden ser útiles, lo veo bien mientras no pierda la esencia del foro, pero un cambio radical lo veo una cagada, como dicen... si algo funciona, mejor no lo toques, y si no que se lo digan a la de Cazafantasmas 3 xDDD. Bueno pues con esto me despido, espero no haber sido muy pesado y reitero que este post no esta montado para faltar el respeto a nadie y si alguien lo ve así, mis disculpas no era mi intención, pero quería dejar mi opinión clara, se ve que tanto tiempo en casa encerrao me da que pensar . Un saludo a todos 😄
  38. 3 points
    Utilizad el sharedmaterial, no el material.
  39. 2 points
    Buenísimo el vídeo!! gracias por el aporte
  40. 2 points
    Primero: no uses // para cada linea, si quieres comentar un un metodo u otro texto largo, usa /* .... */. Segundo: En respuesta a tu pregunta. Deberías manejar el inventario y pickup objects desde el jugador, porque si vas a implementarlos en cada objeto 'Item', que pasará cuando quieras instanciar 1K items en la escena?, Tendrás 1K scripts ejecutando funciones de eventos en cada frame innecesariamente?. Usa un único sistema que manejé los eventos de colisión, entonces, cuando tu jugador este cerca a un objeto, se active un método que verifique si hay o no, espacio en el inventario. Y cuándo digo "UN" es solo uno, en tu primer script hay un método (RecogerObjeto ()) que se activa cuando se cumple un if, Fatal! Que pasa si ese if nunca cambia de estado? Seguirías llamando el método una, otra y otra vez, usando innecesariamente la CPU. En su caso, usa los eventos de colisión para preguntar una vez si hay espacio en el inventario. Si la respuesta es falso, evita hacer una nueva llamada a la función, entonces cuando el usuario elimine un item de su inventario, lanza otra función que diga algo como "Inventario actualizado, realiza una llamada a los triggers a ver si hay items para recoger", esto sería un optimización drástica al la manera en que está planteada tu actual idea.
  41. 2 points
    Yo después de leer este hilo:
  42. 2 points
    Desarrollo en Unity 2019.3. Una primera aproximación a un FPS sin prácticamente optimización más allá de los lightmaps del entorno. Es posible utilizar diferentes FX dependiendo del material de contacto. He utilizado algunos assets de pago y otros gratuitos en los apartados de diseño solamente. El código y la integración es mío desde cero. El canal de youtube para seguir las actualizaciones es: https://www.youtube.com/user/LosSopranoNet/videos
  43. 2 points
    Hola, He incoporado un vídeo nuevo a la serie. En este entreno dos agentes a la misma vez, el segundo agente tienen unas pequeñas modificaciones que hacen que se dedique a empujar y molestar al player. Es decir, no tan solo intenta llegar al premio, sino que tambien intenta impedirle al player llegar. Me ha sido mucho mas facil entrenar a un segundo agente que crear la logica de programación de un NPC que se dedicase a lo mismo. Empiezo a verle cosilla a esto de los MLAgents.
  44. 2 points
    Por supuesto. Tengo estas dos simples funciones en el Scene Manager: private void memoryInfo(string process) { Debug.Log("memoryGC" + process); Debug.Log("memoryGC:RAMTotal " + cSystemIOMemory.RAMTotal); Debug.Log("memoryGC:RAMAlloc " + cSystemIOMemory.RAMAlloc); } public IEnumerator memoryGC(string process) { this.memoryInfo(process); yield return StartCoroutine(cSystemIOMemory.memoryGC()); this.memoryInfo(process); } Una vez se han inicializado todos los componentes desde el main, lo llamo así: this.StartCoroutine(this.sceneManager.memoryGC("_main:end")); Y me dará lo que actualmente llevo ocupado y lo que se ha liberado. cSystemIOMemory es una extensión y contiene ésto: public static class cSystemIOMemory { public static string RAMTotal { get { return (SystemInfo.systemMemorySize.ToString() + " MB"); } } public static string RAMAlloc { get { return ((Profiler.GetTotalAllocatedMemoryLong() / 1000000).ToString("0") + " MB"); } } public static IEnumerator memoryGC() { yield return Resources.UnloadUnusedAssets(); GC.Collect(); }
  45. 2 points
    @TheShopKeeper Si lo que buscas es hacer las conversaciones mediante nodos, te recomiendo que utilices fungus https://assetstore.unity.com/packages/templates/systems/fungus-34184 es totalmente personaliza-ble, puedes todo tipo de conversaciones (desde tipo fallout hasta a algo más final fantasy) y tiene un foro de dudas que siempre esta activo No se cuanto tendrás avanzado, pero te valdrá le pena hacer el cambio. jeje, solo me falta decir algo como; llame ahora y le damos una batidora de regalo. Suerte.
  46. 2 points
    Qué barbaridad. No sería más fácil compartir el proyecto entero vía wetransfer o parecidos?
  47. 2 points
    ¿Cuál es el "emulador"? Probaste haciendo una development build? Probaste usar otra versión de Unity? (qué versión estás usando?) Salen tantos bugs nuevos version a version que ya perdí la esperanza, a veces cambias de versión y algo que tendría que andar no anda, un desastre Unity.
  48. 2 points
    Felicitaciones! adoro los metroidvania. Hay demo? (más orientada a controlar el personaje que otra cosa, una pequeña escena con elementos básicos del gameplay y nada más) cosa de darte algun feedback. Desde mi punto de vista, estaría genial si pudieras compartir: Tus mecánicas de retroceso temporal (supongo que a lo Braid) La interacción entre personaje y soga (hinge joints quizas?). Coincido con @francoe1, cualquier experiencia relacionada con Steam es siempre bienvenida. Le encuentré dos cositas mirando el trailer, nada de otro mundo, pero sí me llamaron la atención: Muchos te van a comparar con Limbo (creo que el 90% de los comentarios de este hilo ya mencionan Limbo jaja). No es que sea algo "malo", pero te van a medir (visualmente hablando) de Limbo para aquí o para allá. Está perfecto si esto es lo buscado. Por ejemplo, del 0:00 al 0:03 nunca se me habría pasado Limbo por la cabeza ... después del segundo 0:03 se ve el clásico pastito a lo Limbo (quizás este sea el principal desencadenante?). Cosa mía, mirando el trailer habría jurado que el personaje tenía una venda en la cabeza. Una vez que vi la portada del juego me di cuenta que era el pelo rubia/blanco. No se si esto te sirve o no, quizás el pelo es demasiado blanco? quizás le falte un pequeñito sombreado para diferenciar el pelo de la piel? no se, no soy un artista. Una última pregunta, con respecto a los requerimientos, en la página de Steam dice: Gráficos: Nvidia GeForce GTX950 o mayor ----> Tanto requiere? Saludos.
  49. 2 points
    PoC sobre colliders por partes del cuerpo y FX de sangrado. Ahora ya tengo mucha más precisión en la zona de impacto de los NPC's:
  50. 2 points
    Haber si esto te funciona... Renderer renderer; Color lerpedColor = Color.red; void Start() { renderer = GetComponent<Renderer>(); } void Update() { if (Input.GetKey(KeyCode.C)) { lerpedColor = Color.Lerp(lerpedColor, new Color(0.2F, 0.3F, 0.4F), 0.01f); } renderer.material.color = lerpedColor; } y te recomiendo que leas https://docs.unity3d.com/ScriptReference/Color.Lerp.html https://docs.unity3d.com/ScriptReference/Material-color.html para entender ,mejor como funciona Suerte!😊
×
×
  • Create New...