Jump to content
Sign in to follow this  
biztor

Problema con position despues de rotar el Gameobject

Recommended Posts

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.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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... 

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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...

 

 

Edited by biztor

Share this post


Link to post
Share on other sites

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)

Edited by edgar_94_

Share this post


Link to post
Share on other sites
1 hour ago, edgar_94_ said:

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)

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.

Share this post


Link to post
Share on other sites

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":

tetris.png

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:

tetris2.png

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Ahora, lightbug said:

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

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

Share this post


Link to post
Share on other sites
1 minute ago, edgar_94_ said:

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

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.

Share this post


Link to post
Share on other sites
Ahora, lightbug said:

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.

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

Share this post


Link to post
Share on other sites
Sign in to follow this  

UnitySpain © Todos los derechos reservados 2020
×
×
  • Create New...