Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 07/08/2020 in all areas

  1. 2 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.
  2. 1 point
    Muchas gracias por la ayuda, demoré en entender el código, aun me falta mucho por aprender. Este tipo de programación tiene un nombre en concreto?
  3. 1 point
    Tutorial Modelado 3D Hola amigos de unity, les comparto uno de mis tutoriales , para convertir una imagen a un modelo 3d, es un tutorial de eso modelado 3d, también aprovechar para invitarlos a mi canal para más tutoriales, gracias. Si desean les comparto el modelo final también en fbx para el unity, bueno sin más nos vemos pronto.
  4. 1 point
    puedes usar tags.... y en la collision mirar que tag tiene el colisionado.... si un "noContagiado" se colisiona con un "contagiado" le cambias el tag a "contagiado" (al primero) o puedes hacerlo con layers...
  5. 1 point
    ACTUALIZACIÓN - He añadido un par de animaciones más. - Ahora tanto el pelo como la armadura y la mandíbula se pueden quitar y dejar el esqueleto desnudo. Descarga desde el Asset Store de Unity (con escena de ejemplo, Prefabs listos y compatible con Mecanim) Descarga la versión suelta (sólo el modelo, animaciones y texturas)
UnitySpain © Todos los derechos reservados 2020
×
×
  • Create New...