Jump to content
UnitySpain

Antonio

Registrados
  • Content Count

    195
  • Joined

  • Last visited

  • Days Won

    6

Antonio last won the day on December 2 2019

Antonio had the most liked content!

Community Reputation

184 Excellent

2 Followers

About Antonio

  • Rank
    Asiduo

Profile Information

  • Especialidad
    Coder

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Valep, creo que ya... Básicamente lo que he aprendido es a mandar al traste con las opciones de posición, longitud, escalados, layouts y anchors-presets. En su lugar centrarme mayormente en colocar los anchors manualmente, (Extendiendo el atributo "anchors" y poniendo los valores ahí, luego arriba dejar sólo los márgenes o generalmente, 0 en los 4 costados). Así, parece que sí puedo juntar las piezas que sean paralelas (no hijas de) (haciendo por ejemplo que una tenga anchors de [0 - 0.7] y otra de [0.7 - 1] ) Así, aunque la ventana se escale diferente, parece que las proporciones se mantienen más o menos (obviamente cambian la longitud de los textos, pero al menos no se separan ni solapan las piezas más). Por otra parte, he leído que es aconsejable separar los elementos en distintos Canvas según la frecuencia con la que se modifica. Yo ahora mismo lo tengo así. |--- Menu Pausa |---SubCanvas Principal |---SubCanvas Settings |---SubCanvas Gameplay |---SubCanvas Control |---SubCanvas Vídeo |---SubCanvas Audio |--- Menu Personaje |---SubCanvas General |---SubCanvas Estado |---SubCanvas Coleccionables |---SubCanvas Diario Están activos al inicio (por lo que en teoría, se pre-carga todo antes de empezar el nivel, cuando lo hacen, se desactivan sólo los componentes Canvas renderer, y los reactivo según las opciones. Ahora, si debería dividir piezas que se actualizan mucho, (como relojes o la descripción del diario que cambia con el click de cada entrada). Supongo que eso sería ¿un nuevo SubCanvas más?. Para que cuando estos se recreen, no fuercen la recreación de los demás componentes. O_ò (¿en teoría?). También veo que tengo que hacer 2 códigos más, uno para que las entradas del diario se creen automáticamente (es un poco lata meter cada botón e ir cambiado dimensiones aquí y allá @_@ ) y por otro lado, algún script que actualice los textos para el cambio de idioma. aains... paciencia...
  2. Ayer estuve dando vueltas otra vez intentando hacer menús, pero se me siguen mareando los elementos UI.(Las ventanas son Image UI) Este es mi ejemplo más reciente, pero llevo lidiando con este problema mucho tiempo. En este ejemplo, intento que aparezca esa ventana a la derecha: - Que aparezca pegada a la ventana de Settings (ni más lejos ni que se pisen), - Que no se corte al final de la ventana. - Que se mantengan ciertos márgenes. - Que la ventana de Settings aparezca relativamente a la izquierda de la pantalla (podía ponerla en el centro y que se estrechara, pero prefiero que aparezca fija a la izquierda y usar el centro y la mitad derecha para mostrar la información, distintos paneles y tal). Esto esta hecho con un canvas usando Screen-Space camera y Scale with Screen Size. Como hijo tiene otros 2 canvas (uno para el menu pause, y otro para el menu Settings. El menu pause no tiene ventana a la derecha y sus botones tienen otros nombres y funciones, pero visualmente son muy similares). Cada subCanvas (pause y settings) tiene un Elemento imagen que es el cuadrado azul, y este elemento, tienen varios hijos múltiples que son los botones). La ventana a la derecha, no sé si hacerla como sub-canvas de Settings o si ponerla simplemente como otro hijo o qué hacer con ella... @_@ He probado distintas configuraciones con los anclajes y el escalado, pero no consigo mantenerlo, también he probado el Layout horizontal, pero aunque me mantiene los márgenes, hace que las dos ventanas se pisen o se separen. Buscando, veo que muchos hacen un diseño de un menó con objetos flotantes separados, pero si quisiera objetos unidos, ¿como podría hacerlo? Otras veces he intentado completar más un menú para gestiones (un lado columna de objetos, al otro lado un mapa y debajo unas estadísticas) pero me siguen dando la tabarra problemas similares. ¿Conocéis algún procedimiento para tratar con este embrollo? @_@
  3. Hola nomoregames. Ahora mismo no recuerdo con garantías en como se evitaba el choque ese del 360 al 0. Pero ¿has probado usando las rotaciones quaternarias? (en vez de las Eulerianas) El tipo Quaternion (que es el que unity usa por defecto para las rotaciones) tiene su X, Y, Z y W, ese valor extra, el motor lo usa para averiguar la dirección de la rotación y evitar errores como ese. Por eso, yo probaría, en vez de usar el smoothdamp del Vector3, usaría el Slerp que hay en la clase de Rotation (que trabaja con números quaternarios). public GameObject Cabeza; public GameObject Cuerpo; float MouseX; float MouseY; public float MaxY; public float MinY; Vector3 current; private float RotationSpeed = 5.0f; //Added private float timeCount = 0.0f; //Added // Update is called once per frame void FixedUpdate() { MouseX += Input.GetAxis("Mouse X"); MouseY += Input.GetAxis("Mouse Y"); MouseX = Mathf.Clamp(MouseY, 0, 360);//Added MouseY = Mathf.Clamp(MouseY, MinY, MaxY); Cabeza.transform.eulerAngles = new Vector3(-MouseY, MouseX,0 ); Cuerpo.transform.rotation = Quaternion.Slerp(Cuerpo.transform.rotation, Cabeza.transform.rotation, timeCount); //Added timeCount = timeCount + Time.deltaTime * RotationSpeed; //Added } } No lo he probado y no estoy seguro de si funcionará, pero bueno, algo así es lo que probaría yo.
  4. Lo hice :D Al final tuve que dar un poco más de vuelta pero ya me funciona. Recapitulando, para arreglar el bloqueo de la caída que se me producía cuando chocaba con algún collider: He creado dos vectores nuevos: Pushdir este guardará la dirección a la que empujar un personaje para evitar la última colisión detectada. ExtraMoveDir que guardaría una dirección para empujar al personaje cuando sea necesario. (el personaje se mueve por el input del jugador pero ahora cuando las físicas lo requieran, cambio ese nuevo Vector3 para añadir un nuevo movimiento además del que tenía). Ese Pushdir lo actualizo en varios casos, uno de ellos es la función OnControllerCollisionHit, el problema es que no sé como encaja esa función en el tinglado general, es como si fuera una co-rutina, una función en un nuevo thread, a veces puedo ejecutar mi algoritmo pero no llamar esa función, (puede que se active antes o después, depende de la colisión de las físicas), por eso, como no tengo control sobre ella, lo que hago es que cuando se active (cuando sea), guarde la información que me interesa en Pushdir, y ahí si puedo reclamarla cuando mi algoritmo principal la necesite. Así, en la función CheckGravity, cojo esos dato y los paso al ExtraMoveDir, esta variable se resetea en cada frame así que si el jugador "aterriza" ExtraMoveDir es cero en el siguiente frame, dejaría de afectar el movimiento del GameObject y no tengo que preocuparme por anular Pushdir dentro de la función OnControllerCollisionHit. Ya con ese valor de Extra MoveDir, lo paso al valor de la función .Move (en mi caso lo tengo en OnAnimationMove). Como extra, he actualizado la gravedad, en vez de modificar el moveDirection (que se modifica con el input del jugador), he puesto la gravedad en la Y de este ExtraMoveDir, reduciendo algunas líneas así en las funciones OnAnimationMove y Update. Y bueno, ese error ya no se me da, una cosa menos y problema resuelto :D (Ahora a esperar al siguiente @_@) Dejo el código con las modificaciones.
  5. La vagueritis XD tengo que acostumbrarme a los pastebins y a los githubs (que a veces aún me pierdo buscando el botón para descargar las cosas de ahí @_@) Pero bueno, probé con el spoiler, tuve un problema con él, parece que el spoiler se comía todo lo que había en el mensaje desde el tag [ spoiler] que lo abría hasta el final. Como si ignorase el tag [ / spoiler]. O_ò Pero bueno, aún así me ha servido bien en este caso :) Y sobre el problema del tema en sí, hoy estoy dándole otro intento, leyendo otros códigos, he visto uno que utiliza la función "OnControllerColliderHit" que efectivamente es de Unity: https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnControllerColliderHit.html No la había visto, ( Ahora no paro de verla en todas partes por la documentación x_x ) pero si esta función/evento efectivamente registra el punto de impacto hit que se produce cuando el character controller está en movimiento, quizás debería poder usar esa información como... Mientras esté en el estado de caída, si hay alguna colisión (que no sea la que detecta el centro de personaje, porque esa es la del suelo) entonces si hay una colisión más como la del bordillo, entonces empezar a mover al personaje en dirección opuesta (la dirección desde el punto de impacto y el origen del personaje). La idea ¿podría funcionar? En fin, voy a ver si logro realizarla.
  6. Tengo un problema recurrente, varias veces he hecho algún código para mover el jugador utilizando el Character Controller pero a la hora de aplicar gravedad, doy con un problema. A diferencia del controlador de rigid body, el character controller no tiene physic materials, así que cuando este colisiona no hay deslizamiento, eso hace que mi personaje, al pasar por algún bordillo se quede atascado en el aire (a menos que vaya corriendo, entonces la velocidad de desplazamiento es tan alta que al caer está más alejado del borde y no colisiona). Pero aunque parezca un caso raro, resulta que ocurre mucho cuando lo pruebo, jugando a escalar y bajar, muchas veces se me queda el personaje congelado ahí por esto mismo. (Como no puede bajar hasta el suelo, se queda congelado con la animación de caida en el estado de caida). En el Update, para el movimiento había intentado esto: //Move if ((AllowControls) && (GravState == GravityState.Land)) { moveDirection = vertical * (Vector3.Scale(cam.forward, new Vector3(1, 0, 1)).normalized) + horizontal * cam.right; IsMoving = (moveDirection.magnitude > 0.1f)? true : false; moveDirection.Normalize(); moveDirection = transform.InverseTransformDirection(moveDirection); } if ((GravState == GravityState.Falling) || (GravState == GravityState.FreeFalling)) { //moveDirection = transform.forward * 0.02f * Time.deltaTime; } moveDirection.y = moveDirection.y - verticalDirection; Esa línea que esta comentada, pretendía mover al jugador hacia delante (y después un poco hacia abajo) en caso de que estuviera cayendo, pero la cosa tampoco me funciona, al activarla, el personaje va haciendo glitches hasta llegar al suelo, (como si se saliese del estado de caída y volviese a entrar continuamente). También probé reducir el tamaño de la cápsula (está a 0.4 y la puse a 0.2) efectivamente reduce las veces en las que este problema se da, pero me causa otros problemas de clipping en la animación de esacalada (el personaje entra más de lo que está previsto y escala con las piernas hundidas en el bloque), así que lo he vuelto a poner a 0.4 para que haya más espacio entre la colisión y el origen del jugador. ¿Alguien se le ocurre alguna manera de como enfocar esto? No creo que sea algo que sólo me pase a mi, ¿como se suele solventar este problema con los bordillos? O_ò Pongo aquí el código del jugador que estoy escribiendo en spoiler porque es un poco largo.
  7. Hola Lucky-chan. El problema está en la función que estás usando para comprobar la pulsación de la tecla F. En Unity hay 3 funciones en lo que se refiere a colisiones, (3 para triggers y otras 3 para colisiones, pero centrándonos en los triggers). OnTriggerEnter OnTriggerStay OnTriggerExit Has puesto un código para comprobar la tecla F en el OnTriggerEnter, esta función sólo se activa en 1 frame, el frame en el que el objeto entra dentro del trigger, (Luego debe ser muy complicado pulsar la tecla F justo en ese pequeño momento). Utiliza OnTriggerEnter cuando tengas que inicializar cosas, (activar 1 enemigo, dar la orden de abrir una puerta, etc...) Pero tu necesitas colocar ese párrafo de la tecla F en el OnTriggerStay, esta función se activa en todos los frames mientras el objeto de turno está dentro del trigger, entonces sí se ejecutará el if que comprueba la pulsación de la tecla durante un tiempo más asequible para el usuario. (GetKeyDown se comporta igual que OnTriggerEnter, su contenido sólo se activará en el frame dónde la tecla pasa de no estar pulsada, a ser pulsada, así que no habrá problema en este caso, pero recuerda que las cosas de OnTriggerStay, funcionan como un "update" lo que esté ahí se ejecutará en varios frames, no podrías poner cosas como la activación de 1 enemigo ya que fácilmente se podrían activar 60 en 1 segundo). Por eso están las 3 variantes. :)
  8. Eso suena incluso mejor Jardem. me alegro que te haya salido el efecto.
  9. Como ha dicho Pioj, los colliders de unity no se pueden llevar a Blender. Lo que puedes hacer, es abrir el tractor en Blender (imagino que el tractor, tendrás un prefab, pero en algún lugar tiene que estar el modelo también, puede que un .obj o un .fbx, ambos archivos se pueden importar directamente en blender), y una vez tengas el tractor ahí crear polígonos para que hagan colliders, y luego exportar ese modelo de vuelta a Unity y usarlo como colliders poniéndole el componente Mesh Collider. Aunque ¡ojo!, los colliders y las físicas son partes que más rendimiento consume en los motores de videojuegos, mientras los colliders sean más complejos (más vértices, es decir, más caras y más polígonos) pues más tiempo necesita para comprobarlos. A B En el caso A, requiere menos pasos para verificar si el cuadrado azul está tocando el cuadrado rojo. Mientras que en el caso B, se requieren muchos más pasos para ver si el cuadro azul está tocando la figura roja. Esto quiere decir, que si vas a hacer algún polígono de colisiones para el tractor, este polígono debe ser tan low poly como se pueda. Si puedes usar cubos de Unity para ello, perfecto, si necesitas algo más preciso (un shooter, o si es importante la forma para las físicas, etc...) entonces crea un mesh para el tractor en blender, lo importas a unity y lo usas con el mesh collider (que para eso está). No hace falta que te preocupes de la textura, puedes literalmente borrar el componente del "Mesh Renderer" puesto que no necesitas que el objeto se dibuje durante el juego. Pero eso, para colliders "low poly".
  10. La cámara esa sencilla del CamaraPlayer public class CamaraPlayer : MonoBehaviour { public float mouseSensitivity = 10f; public float dstFromTarget = 2f; public Vector2 pitchMininMax = new Vector2(-40, 85); public float rotationSmoothTime = .12f; Vector3 rotationSmoothVelocity; Vector3 currentRotation; float yaw; float pitch; public GameObject PLAYER; public Transform target; private void Awake() { PLAYER = GameObject.FindGameObjectWithTag("Player"); target = PLAYER.transform; } void LateUpdate() { yaw += Input.GetAxis("GiroHorizontalCamara") * mouseSensitivity; yaw += Input.GetAxis("Mouse X") * mouseSensitivity; pitch -= Input.GetAxis("MovVerticalCamara") * mouseSensitivity; pitch -= Input.GetAxis("Mouse Y") * mouseSensitivity; pitch = Mathf.Clamp(pitch, pitchMininMax.x, pitchMininMax.y); currentRotation = Vector3.SmoothDamp(currentRotation, new Vector3(pitch, yaw), ref rotationSmoothVelocity, rotationSmoothTime); transform.eulerAngles = currentRotation; transform.position = target.position - transform.forward * dstFromTarget; } } Está usando el valor yaw (que irá desde -infinito hacia +infinito aunque en la práctica, es de -360 a +360), es un ángulo que usas después para ponérselo a la Y en el transform.eulerAngles. En este código, ese ángulo se modifica moviendo el ratón, pero si tuvieras un enemigo, o un objetivo específico al que apuntar la cámara, lo que necesitas es hallar el ángulo para que apunte a ese punto. De modo que si tienes la X y Z de la posición del enemigo... En ese código que tienes después de hacer la rotación, simplemente mueve la cámara a la posición del jugador y da unos pasos hacia atrás, luego según veo yo no haría falta hacer más modificaciones para el asunto de la rotación. Para el pitch, la idea es igual, pero usando la distancia y la altura (Y) en lugar del X y Z. (Si haces algún enemigo volador pues puede que lo necesites, pero ten cuidado de aplicar también la línea del clamp o puede que la cámara empiece a dar vueltas raras y a ponerse bocabajo). Otra cosa sería cuando hallar el yaw mediante trigonometría y cuando mover el yaw mediante el ratón, se puede hacer dos cámaras, o también podrías poner alguna variable Transform para el "objetivo" de la cámara, si es igual a null, moverla con el ratón, si es distinto de null, hallar el yaw con la fórmula.
  11. Hola Jardem. No tengo ningún script así a mano, pero sin duda veo seguro la necesidad de programar un poco para que ese efecto ocurra. La idea que me viene a la cabeza es la siguiente: - Creas un trigger, un cubo o un cilindro y lo pones donde esté el tornado. Este objeto le creas un script, para que cuando la bola entre ahí, pues empiece el efecto. - En el script, al ser un trigger, puedes usar las funciones de trigger en vez de la Start y Update de siempre. Las funciones de trigger que me refiero son las siguientes: OnTriggerEnter: https://docs.unity3d.com/ScriptReference/Collider.OnTriggerEnter.html (Se dispara cuando el collider de la bola entra en el trigger) OnTriggerExit: https://docs.unity3d.com/ScriptReference/Collider.OnTriggerExit.html (Se dispara cuando el collider de la bola sale del trigger) OnTriggerStay: https://docs.unity3d.com/ScriptReference/Collider.OnTriggerStay.html (Se dispara en cada frame mientras el collider de la bola esté dentro del trigger) Depende de como sea el script de control de la bola, puede que tengas que hacer contrarrestar más cosas o menos, pero con esas funciones deberías poder tener algo más de control. - Si por ejemplo, el controlador de la bola es el rigidbody estándar de Unity, pues podrías hacer que en el OnTriggerStay, la bola recibiera una fuerza que la mueva. (El vector de dirección de la fuerza, podría variar con el tiempo, quizás la Y sea siempre hacia arriba, pero la X,Z podría estar cambiando dependiendo del ángulo para que la bola vaya recorriendo un círculos mientras está dentro del tornado , las fórmulas trigonométricas creo que serían las siguientes: Dado el ángulo "A" y el radio "r" X = cos (A) * r Z = seno(A) * r La función para mover la bola debería ser AddForce en el OnTriggerStay, aunque no recuerdo qué modalidad habría que ponerle en el "ForceMode" (A penas uso el Rigidbody :( ) https://docs.unity3d.com/ScriptReference/Rigidbody.AddForce.html https://docs.unity3d.com/ScriptReference/ForceMode.html (Yo creo que "Force" debería valer, pero prueba con los 4 por si acaso).
  12. Puedes usa distintos layers para los triggers y para los colliders de los muros.
  13. Hola Megadok Si usas las físicas de Unity rigidbody, pues sí, el valor mass y el drag que menciona iRobb podrían ayudar en ese aspecto. Hace un par de semanas hice una pequeña escena jugando con esos componentes, puse una pelota que botaba constantemente entre dos rampas, y una cápsula que movías con el teclado. - Si la masa de la pelota, era superior a la de la cápsula, la pelota empujaba la cápsula al chocarle. - Si la cápsula tenía más masa que la pelota, esta no empujaba si no que rebotaba también como si chocara con otro objeto sólido. Aunque tuve dos problemas, 1º Estos valores tenían se veían afectados también por la fuerza con la que se mueve el objeto. Se podía dar el caso de que cuando la cápsula tuviese más masa que la pelota, a lo mejor la pelota si tenía poca fuerza, no podía mover la cápsula, pero si esta venía con mucha fuerza, sí podía mover la cápsula un poco, esto se podía evitar aumentando mucho la masa de la cápsula, aunque siempre pasará lo mismo, mayor fuerza -> más masa es necesaria para que no le afecte... Entiendo que en un juego, se supone que las fuerzas están más o menos controladas, no es que ninguna fuerza vaya a descontrolarse... pero en fin, más baja o más alta, siempre habrá una "frontera". 2º El otro problema es que quizás la pelota no podía empujar a la cápsula, pero la cápsula sí podía empujar la pelota. Por lo que no sé si eso es lo que realmente quieres en tu juego (que los enemigos no empujen al jugador, pero el jugador sí empuje a los enemigos. Ó viceversa). Tal vez incrementando el drag podría ayudar a esto. (aunque tendrás que modificarlo cuando quieras mover al personaje o puede que el drag también impida que el personaje se traslade...) /-----------------------------/ A mi se me ocurren 2 opciones. 1º en vez de usar el sistema de físicas de Unity, hacer los personajes con character controller, este componente también tiene una función Move y reacciona ante los colliders, pero no aplica tantas fuerzas físicas como el rigidbody (aunque eso significa que hay que programar más). 2º usando el sistema de físicas, pero poniendo un trigger alrededor de los enemigos de modo que cuando el jugador entre en ellos, la velocidad de las físicas en el rigidbody pase a ser [0,0,0]. Necesitará pulirlo, especialmente para que no se quede atascado dentro (por ejemplo, que el "bloqueo" solo se ponga si el movimiento se está realizando en la dirección dónde está el enemigo). Me gusta más la 1º, pero supongo que depende de la clase de juego que estés haciendo. O_ò
  14. A mi se me ocurre crear un par de capas (layers) para el jugador, una que efectivamente detecte las colisiones con el entorno, y otra que traspase dicho entorno. y activar dichas capas mediante código cuando entre o esté dentro de ciertos triggers. (Supongo que no querrás que "siempre" que pulse la tecla abajo, atraviese el suelo, esto sólo lo hará en ciertas plataformas ¿no? O_ò, puedes marcarlas con un trigger). Lo importante es que las capas una no interactué con la física (para que pueda atravesarlas), esto puedes gestionarlo en el panel de físicas (Edit -> Project Settings -> Physics) En esta por ejemplo, Layer 3 no detecta las colisiones con Layer 1 y 2, mientras que Layer 2, no detecta las colisiones con Layer 1 (ni Layer 3).
  15. Sí, algunos roles de programador dependen más de empresas grandes que realicen su propio engine (como Electronic Arts y su sistema de iluminación por voxels para su motor Frostbite) o empresas especializadas que realicen su propia tecnología (como los programadores de NVidia y el empuje que están dando con lo del ray-tracing). Hay roles más generales en el sector de los videojuegos que sí podría facilitar la entrada al mundillo. Entre los que cité, creo que lo que más ilusión me hace es el de inteligencia artificial, también tengo esa asignatura este mismo año así que a lo mejor me ayuda a aclararme.
×
×
  • Create New...