Noticias

¡RECUERDA QUE SI ERES UN NUEVO USUARIO, DEBES PRESENTARTE PARA PODER PUBLICAR MENSAJES! | TENEMOS CANAL OFICIAL DE TELEGRAM: t.me/unity3dspain

Problema con position despues de rotar el Gameobject

Iniciado por biztor, Enero 08, 2017, 10:08:43 PM

Tema anterior - Siguiente tema
Estoy haciendo un tetris, las piezas son un prefab de 4 cubos agrupados en un GameObject. Antes de bajar o moverse, verifico que la posición a la que se quiere mover no hay nada, haciendo un for por cada hijo del GameObject. Todo funciona perfectamente, las cosas raras ocurren al rotar.
 
Cuando se hace la rotación, giro 90 grados el GameObject, es entonces cuando no funcionan bien las detecciones, 
 
por ejemplo una pieza sin rotar, que no puede desplazarse a la izquierda,al rotar, desde el punto de origen del GameObject, no tiene ningun bloque a la izquierda, con lo que podría moverse, pues no. Es como si ese bloque, que su transform es -1,0,0. Al buscar su posición sabe que esta a -1x del padre, y en vez de darme la posición real del hijo en el espacio, saca que esta a -1x y por eso detecta que no se puede mover hacia la izquierda, cuando en verdad el bloque si tiene espacio.
 
No se si me he explicado bien, pero no se como arreglar esto.
 
 

A ver a ver... Estas programando un tetris por matrices o por físicas? Porque sería un buen comienzo jajajaja como rotas el objeto? Como están hechos los emparentados? Y que es lo que realmente pasa porque no lo he entendido muy bien jajajaja

por matrices.
 
Por ejemplo el movimiento automático hacia abajo, mira todos los bloques que forman el Gameobject, y compara su posicion, con el indice del array, para ver si hay algo.
 
 
 

private bool Colision(int modX,int modY)
    {
        for(int n=0;n<piezaActiva.childCount;n++)
        {
            if(grid[(int)piezaActiva.GetChild(n).transform.position.x+modX, (int)piezaActiva.GetChild(n).transform.position.y+modY]!=null)
            {
                
                return false;
            }
        }
        return true;
    }

 
Si no hay nada, sigue bajando. El problema viene, que roto el GameObject padre, que contiene 4 GO hijos, que son los bloques de la ficha. Entonces el objeto se para por encima de donde debería, Por ejemplo para bajar llamo a la función con colision(0,-1), asi mira que debajo de cada bloque no haya nada, pues con 90º de rotacion, y aunque debajo no haya nada, la ficha se para.

Mmm lo haces por matrices? Entonces las posiciones las mueves con otro método? No veo fallo en este... Entre las horas y que estoy con el movil... Igual se me escapa algo jajajaja de todas formas... Me gustaría saber como mueves el go de la ficha o como las rotas, porque como te he dicho no parece que esté mal este método ya que simplemente pues mira un offset determinado... 

para mover simplemente,
 
piezaActiva.position += new Vector3(0f, -1f, 0f);
 
actualizo la matriz cuando la pieza ya no se puede mover y sale la otra.
 
para rotar, sin mas
 
piezaActiva.transform.Rotate(0f, 0f, 90f);
 
he probado ha rotar en self y a rotar en world, y nada lo mismo. La ficha hace cosas rarisimas siempre que esta rotada. la misma ficha rotada, se puede quedar a 1 o varios espacios de donde tendria que estar, y la misma ficha rotada 360º o sin rotar, va normal. Lo que roto es el GameObject padre. Tan simple joder y no se que mierdas pasa.
 
 

A ver... Si utilizas un rotate... La rotación es automática... Osea que... Porque no mueves las piezas de la ficha en vez de rotar la ficha entera? Yo siempre que puedo intento evitar las rotaciones... Si no... Mira cuando compruebas la posición de abajo, antes de moverlo? Yo imagino que mientras no dé true la colisión seguirás bajando, pero tengo una idea... Puede que al girar la pieza... La diagonal mas larga de la pieza haga que ese ultimo punto -1 en y de true en colisión y deje de bajar... Puede ser? Espero ser de ayuda jajaja

Enero 08, 2017, 11:59:23 PM #6 Ultima modificación: Enero 09, 2017, 12:07:10 AM por biztor
si, una solución seria mover todas las fichas, pero seria mas largo y tedioso. porque tiene que mirar que ficha es para reordenar los bloques, y dependiendo en que rotación este. Tambien me jode no saber porque pasa esto.
 
El misterio se vuelve mas raro, sigo haciendo pruebas, y rotando y demas, como digo hay problemas con el tema paredes y el suelo, pero no con las fichas, las fichas al posarse, guardo sus transforms en el array, y la siguiente pieza aunque la rote, si que detecta PERFECTAMENTE todas las fichas de alrededor, da igual que las pongas en las posiciones mas raras, funciona perfectamente, osea que no se porque, sin rotacion, no existe un Transform en el array, en la cordenada 1 del eje Y, pero si roto el gameObject, encuentra un Transform en la cordenada 1 del eje Y, aunque no haya pasado nada entre los 2 procesos. Es magia...
 
Por cierto, muchas gracias por tus respuestas.
 
EDITO: despues de rotar, hago un for, por todo el array y saco las posiciones donde hay algo, para testear y esta todo correcto, hay transforms en los bordes, asi que no se porque cojones detecta uno donde no lo hay...
 
 
 
 

Enero 09, 2017, 12:06:29 AM #7 Ultima modificación: Enero 09, 2017, 12:09:02 AM por edgar_94_
No me has respondido a lo de cuando compruebas los offsets jajajaja primero rotas y luego compruebas? Prueba a hacer debug.log cada vez que compruebe la posición de abajo y a ver que pasa... Compruebas si la pieza va chocar antes de rotarla? Hay tantas preguntas.. Jajaja
 
EDIT: recalco que puede que al rotar compruebe si puede bajar y entonces va a dar colisión, afirmame esto por favor que me tienes en ascuas jajja
 
Mmm entonces es muy raro... Y por que las colisiones no las miras por el array? Si sabes que eso no te va a dar problemas... Sabiendo donde hay fichas... No veo complicado ir checkeando en el array (no tanto como rotar la ficha moviendo los cubos jajajaja)

Cita de: edgar_94_ date=1483916789No me has respondido a lo de cuando compruebas los offsets jajajaja primero rotas y luego compruebas? Prueba a hacer debug.log cada vez que compruebe la posición de abajo y a ver que pasa... Compruebas si la pieza va chocar antes de rotarla? Hay tantas preguntas.. Jajaja
   
   
      EDIT: recalco que puede que al rotar compruebe si puede bajar y entonces va a dar colisión, afirmame esto por favor que me tienes en ascuas jajja
   
   
      Mmm entonces es muy raro... Y por que las colisiones no las miras por el array? Si sabes que eso no te va a dar problemas... Sabiendo donde hay fichas... No veo complicado ir checkeando en el array (no tanto como rotar la ficha moviendo los cubos jajajaja)
   


Sigo mañana investigando, las colisiones las miro por el array, como puse más arriba, comprueba que tiene alrededor tomando la posición de las piezas, si hay algo, la posición es el índice del array.
 
Lo muevo todo con corutinas, una que cada X tiempo ha bajando la pieza, antes de bajarla comprueba si puede bajar. Otra corutina responde al input y dependiendo hacia que lado,mira si puede moverse hacia allí y luego se mueve.
Justo después de rotar no comprueba, pero ya te digo que comprueba antes del siguiente frame.

Hola, la verdad por matrices no lo he analizado bastante, lo que yo haria serian usar raycasting y de paso generar las piezas agrupando cuadrados.
 
haria uno o varios rays (dependiendo de la pieza) hacia abajo, independientemente de la rotacion, el distance del raycast me determina una distancia maxima de desplazamiento (simple deteccion de movimiento en viejos platformers 2D), antes de realizar el movimiento chequeo que haya lugar, si lo hay lo muevo. Por supuesto en este tipo de juegos las dimensiones son sagradas, es decir que me voy a mover por lo menos por multiplos de unidad (por ejemplo), es decir que si la distance del raycast no me da mas que la unidad el bloque se queda bloqueado.
 
El truco es que cada vez que rotas, dependiendo de la pieza los rays se "renuevan":
 

 
El pivot esta justo en el centro ya que al rotar genero nuevos rays, solo por motivos de control.
 
En esta pieza que es de 3x2 los rays empiezan siendo 3 al rotar son dos y la colision seria algo asi:
 

 
Si el maximo desplazamiento es 1, es la ultima bajadita, si es mayor puede seguir bajando.
 
La longitud de los rays puede ser mucho mas grande, ya que si apretas cierto boton o tecla deberia bajar de un movimiento la pieza
 
En fin me gustaria pensarlo un poco mas la verdad no lo he planificado demasiado
 
Saludos

Están  ya agrupadas, como he dicho mas arriba, el problema del raycasting es que es mas lento, por eso lo de la matriz.
 
Bueno he cambiado la forma en la que detecta paredes. Basicamente diciendole que no puede ir mas alla del 0, del 11 (en X) y no menos de 0 en Y. Ahora funciona perfectamente.
 
Testeando parecía que iba bien. Rotan las piezas y se mueve correcto, se detectan las colisiones y demás, Pero hay veces que entre piezas hay huevo libre y la pieza se queda por encima, detecta que tiene algo debajo, y se queda ahí. He probado a redondear las posiciones después de un movimiento, pero nada,sigue igual.
 
voy a probar a rehacer todo, sin usar las corutinas.

En un movil podes meter cientos de raycast que no tenes cambios de performance practicamente, es mas, en un tetris podes hacer el raycast cada medio segundo no es necesario hacerlo en todo cuadro

Cita de: lightbug date=1483967598En un movil podes meter cientos de raycast que no tenes cambios de performance practicamente, es mas, en un tetris podes hacer el raycast cada medio segundo no es necesario hacerlo en todo cuadro
   


En este caso estoy con biztor, en un tetris no es necesario usar raycasting ni físicas, por eso en el primer post le pregunté por ello. Lo bueno de las físicas es que ves en todo momento lo que pasa (por lo general) pero es un agujero de bugs del que si es posible hay que evitar jajaja y por otro lado lo bueno de las matrices es que es matemático y lo controlas tu, lo que pasa es que hay que tener en cuenta que no es lo mismo lo que pasa en la matriz y lo que se muestra en pantalla

Cita de: edgar_94_ date=1483967819En este caso estoy con biztor, en un tetris no es necesario usar raycasting ni físicas, por eso en el primer post le pregunté por ello. Lo bueno de las físicas es que ves en todo momento lo que pasa (por lo general) pero es un agujero de bugs del que si es posible hay que evitar jajaja y por otro lado lo bueno de las matrices es que es matemático y lo controlas tu, lo que pasa es que hay que tener en cuenta que no es lo mismo lo que pasa en la matriz y lo que se muestra en pantalla
   


Es cierto, aunque con los rays tampoco estas usando fisicas a full, osea, moves tus piezas directamente con transforms de ahi el control, lo unico haciendo raycast para saber cuanto, es decir como funciona un charactercontroller. Un ejemplo seria si queres un movimiento suavizado, con matrices no lo podes hacer, no seria el caso del tetris clasico clasico.

Cita de: lightbug date=1483968272Es cierto, aunque con los rays tampoco estas usando fisicas a full, osea, moves tus piezas directamente con transforms de ahi el control, lo unico haciendo raycast para saber cuanto, es decir como funciona un charactercontroller. Un ejemplo seria si queres un movimiento suavizado, con matrices no lo podes hacer, no seria el caso del tetris clasico clasico.
   


Con matrices también podrías hacer un movimiento suavizado y fluido, pero tienes que separar la lógica del movimiento y la lógica de la posición (matriz) pero bueno, todo es posible con todos los métodos y de toda forma, solo que en unas hay que tener mas cuidado que en otras kajajaja

Etiquetas: