Cita de: edgar_94_ date=1483968407Con 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
   

Si tenes razon, no lo habia pensado asi. Ahora, volviendo a las matrices es facil rotar una pieza de cualquier dimension, esta clase de juegos se resuelve mas via codigo que trabajando directamente con gameObjects (rotandolos y detectando colisiones), como los tipicos ejemplos de juegos de terminal en C.

Bueno, sin usar Corutinas, me sigue haciendo las mismas cosas raras, esto es desesperante.

Cita de: biztor date=1483971824Bueno, sin usar Corutinas, me sigue haciendo las mismas cosas raras, esto es desesperante.
   

Es que no se que lógica vas a utilizar, ahora estoy en el pc y te puedo ayudar mejor...
 
La lógica que yo tendría sería la siguiente:
 
El movimiento lo haría por un lado y las posiciones las iría guardando en la matriz... ¿Cómo? Pues antes de moverse hacia la posición x/y vamos a ver si hay alguna ficha ocupando ese espacio en nuestra matriz, ¿la hay? entonces la ficha no puede bajar o no puede moverse, ¿No la hay? Entonces la ficha puede bajar o moverse y actualizamos movimiento... se que esto en Unity suena un poco prehistórico, pero es como se ha programado toda la vida xD
 
Y todavía estamos hablando de movimiento simple... verás cuando quieras meter un cuadrado de la ficha en un agujero... xD
 
 

podría hacer todo el movimiento y detectar colisiones en la matriz, rellenando la matriz con los espacios de la ficha, y después de comprobar todo, que se mueva la ficha física en unity. Pero es que joder, no se porque da tantos problemas si es que es lo mismo, la ficha esta en posiciones absolutas, y solo se mueve 1 unidad de cada vez... Lo haré de noche y os digo, pero algo raro pasa cuando se rota. Por webos tiene que funcionar haciendo toda la lógica en matriz, porque es matematica pura.

Cita de: biztor date=1483973041podría hacer todo el movimiento y detectar colisiones en la matriz, rellenando la matriz con los espacios de la ficha, y después de comprobar todo, que se mueva la ficha física en unity. Pero es que joder, no se porque da tantos problemas si es que es lo mismo, la ficha esta en posiciones absolutas, y solo se mueve 1 unidad de cada vez... Lo haré de noche y os digo, pero algo raro pasa cuando se rota. Por webos tiene que funcionar haciendo toda la lógica en matriz, porque es matematica pura.
   

exacto, si lo haces así tiene que funcionar si o si. Estoy expectante a tus respuestas xD

Cita de: biztor date=1483973041podría hacer todo el movimiento y detectar colisiones en la matriz, rellenando la matriz con los espacios de la ficha, y después de comprobar todo, que se mueva la ficha física en unity. Pero es que joder, no se porque da tantos problemas si es que es lo mismo, la ficha esta en posiciones absolutas, y solo se mueve 1 unidad de cada vez... Lo haré de noche y os digo, pero algo raro pasa cuando se rota. Por webos tiene que funcionar haciendo toda la lógica en matriz, porque es matematica pura.
   

claro, esa es la idea de usar matrices en primer lugar, por eso decia que se resuelve todo en el mismo codigo.

Si lo haces con matrices (creo que es la mejor opción) lo importante es que tengas claro qué bloque utilizas como centro del objeto. O sea, al rotar a la derecha creo que tiene que haber un bloque que no se mueva mientras que el resto tienen que 'girar' 90 grados a la derecha. 
 
Cada tipo de pieza estaría formado por un conjunto de varios Vector2, el origen en (0,0) más unos cuantos offsets. Viendo como se comportan las coordenadas al ir girando a la derecha creo que no sería muy complicado automatizar el cálculo para que, partiendo de cualquier tipo de pieza base y sabiendo en qué punto de la matriz está el origen, obtener dónde estarán el resto de bloques al girar la pieza.
 

Cita de: musaranya date=1483981805Si lo haces con matrices (creo que es la mejor opción) lo importante es que tengas claro qué bloque utilizas como centro del objeto. O sea, al rotar a la derecha creo que tiene que haber un bloque que no se mueva mientras que el resto tienen que 'girar' 90 grados a la derecha. 
   
   
      Cada tipo de pieza estaría formado por un conjunto de varios Vector2, el origen en (0,0) más unos cuantos offsets. Viendo como se comportan las coordenadas al ir girando a la derecha creo que no sería muy complicado automatizar el cálculo para que, partiendo de cualquier tipo de pieza base y sabiendo en qué punto de la matriz está el origen, obtener dónde estarán el resto de bloques al girar la pieza.
   
   
      
   

Muchas gracias, ya llegue a casa, a ello me pongo.

Cita de: musaranya date=1483981805Si lo haces con matrices (creo que es la mejor opción) lo importante es que tengas claro qué bloque utilizas como centro del objeto. O sea, al rotar a la derecha creo que tiene que haber un bloque que no se mueva mientras que el resto tienen que 'girar' 90 grados a la derecha. 
   
   
      Cada tipo de pieza estaría formado por un conjunto de varios Vector2, el origen en (0,0) más unos cuantos offsets. Viendo como se comportan las coordenadas al ir girando a la derecha creo que no sería muy complicado automatizar el cálculo para que, partiendo de cualquier tipo de pieza base y sabiendo en qué punto de la matriz está el origen, obtener dónde estarán el resto de bloques al girar la pieza.
   
   
      
   

Explicacion perfecta para rotar el asunto está en que le salen errores a la hora de comprobar si puede mover la ficha... Y creo que el problema que tendría ahora con las colisiones... es que si el cuadrado de la ficha que se encuentra arriba lo comprueba igual que el resto, no le dejará bajar porque abajo tiene un cuadrado ocupado (de la misma ficha) y ahora mismo no se me ocurren formas de evitarlo... quizás utilizar la Y más baja para filtrar y que no compruebe los cuadrados mas altos... algo asi se me ocurre, pero a estas horas ya no soy persona xD

no, voy hacer como antes, ficha activa no se registra en grid hasta que se inmoviliza, así se soluciona las comprobaciones. lo que voy hacer es hacer el movimiento y la rotacion asignando las posiciones directamente a las transforms de las partes de la ficha.
 
Para rotar, creía que tendría que ver que ficha era para programar la rotación, pero como ha puesto el compañero se puede hacer una formula para todas, que ya tengo sacado, se redistribuyen los bloques a sus posiciones esperadas y listo. Espero que funcione.
 
Esto me pasa por llevar tantos meses sin hacer nada. La poca costumbre ...

Tambien hay otra solucion, los bloques que se mueven, son 1s en la matriz, los bloques vacios son 0s y los bloques posicionados -1s... valen cualquier otros numeros xD pero bueno, sería comprobar si en los bloques de abajos se encuentra algun -1 o así ;P

No es tanto problema el comprobar las colisiones, vos tenes un grid de n x m que es el escenario completo, 0's vacios 1's llenos (o true y false como quieras) y de la figura actual podes tener tu 1 local (por asi decirlo, distinto a los 1's estaticos del nivel) asi cuando rotas y/o desplazas la pieza chequeas si se sobrepone a un 1 de la matriz de n x m si lo hace no lo bajas, corres o rotas cualquiera sea el caso.

lo que tengo es una matriz de transforms, para luego al hacer linea, solo tengo que mirar las lineas que se tienen que borrar y destruir el transform asignado.

Bueno parece que ya funciona!!!! , bufff. Algún bug o algo debe pasar usando rotate al Gameobject padre. Calculando donde tienen que estar los bloques, y asignándolos a esa posición, hace que funcione correctamente. El padre solo sirve de contenedor, y se queda en un sitio fijo, cuando la ficha ya no se mueve, lo destruyo, y las fichas pasan a estar en otro grupo, donde guardo todas las fichas colocadas.
 
Todavía queda, a ver si lo acabo mañana o pasado. Muchas gracias a todos, seguramente tendré que preguntar algo mas. Me ha servido de mucho, lo que habéis planteado aquí.

El problema que veo con el método que propuse es el tipo de pieza 'cuadrado'. Si no recuerdo mal en tetris el cuadrado no tiene que rotar, pero si lo hacemos como yo decía (tomando un bloque como origen y girando los demás) entonces el cuadrado rotará. No sé si es el comportamiento deseado o es que en tipos de pieza totalmente simétricos hay que desactivar la rotación
 
 
 
EDIT: disculpar no había leído los comentarios de la página 2