proyecto de juego de bloques

Started by Danielo515, April 18, 2010, 01:05:42 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Danielo515

Bueno, la idea es plantear un juego de bloques, típico, pero con un planteamiento diferente que ya iré desvelando. De momento, me voy a ir a la mesa de ayuda, porque me estoy quebrando la cabeza con un error, que sinceramente, se me hace muuy raro.


Un abrazo.

Danielo515

Bueno, coleguis, a ver si me ayudais a definir un poco las normas del juego.

Actualmente, hay muchas cosas que ocurren y no se si cambiarlas o dejarlas así.

1.- Cuando un bloque se encuentra con una torre, por ejemplo, los otros dos bloques siguen callendo.
2.- Con el mismo caso, antes comentado, conservas el control de los 2 bloques restantes
3.- Solo reconoce fichas que estén alineadas con un mínimo de tres, es decir, si se hace una L esta debe ser de 3x3. ¿debería ser la combinación de 3 piezas el detonante y luego cepillarse cualquier pieza del mismo color quee sté en contacto con ellas? ejemplo


00000
11000
11110

¿debería cepillarme todos los 1 o solo los 4 de abajo? No se si me explico.

Ayudadme a decidir estas normas porfi, ya que si no, no se muy bien por donde seguir.

Windgate

Me perdonarás pero no entiendo bien el planteamiento del juego ni el problema... En su día programé el tetris y recuerdo el tema de los bloques que se "fijan" y los que continúan cayendo, creo que al final lo resolví añadiendo un campo que indica si el bloque está fijado, aunque hace mucho tiempo de eso y por aquél entonces no era tan fiera programando :P

Intenta explicar un poco mejor qué necesitas, igual es que hoy ando un poco espeso...
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

Drumpi

Tal como yo lo veo, mientras están cayendo, los tres grupos de bloques deben ser tres procesos independientes, y en el momento en que conectan con el "suelo" deben desaparecer y aparecer unos nuevos en su lugar, procesos bloques estáticos, o usar put y anotar que dicha posición está ocupada en el array bidimensional del "tablero".

¿Cómo manejar los tres grupos? depende ¿qué hace cada grupo? ¿se mueve lateralmente, rota o hace algo más? ¿Y cual es el objetivo del juego? ¿alinear bloques de colores, unirlos...? Creo que si no se te ha dicho nada es porque no has explicado lo suficiente la mecánica del juego, aunque creo que la respuesta a tu pregunta 3 es: depende de lo que quieras hacer, los dos métodos son válidos, pero uno hará el juego de una forma y el otro de otra, depende de cómo lo quieras complicar.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Danielo515

Vale, ok, veo que no me he explicado del todo bien.

El juego no es un tetris, es más tipo blocks, y en efecto, va de juntar piezas del mismo color, pero con algunos añadidos que espero que lo hagan más diver.

Mi duda, radica sobre todo, en lo que he dicho, que no se si el juntar 3 piezas del mismo color, solo debe eliminar esas piezas alineadas, o que ese sea el detonante para que  mueran todas las piezas que estén conectadas a esas 3 y que sean del mismo color.

Sobre lo de los procesos, que si deben ser esto o lo otro, me ha dado muchos quebraderos de cabeza, pero no os preocupeis que ya lo tengo casi solucionado, lo que quiero centrarme es en las normas.

Por cierto, el otro día pensando en a qué se parece mi proyecto, me acordé ¿alguien conoce el waku waku?

Drumpi

Si lo haces con piezas alineadas, te quedaría un columns como el de MD, y si lo haces por contacto sería como el de GG. Prueba a jugar a ambos y te quedas con el que más te guste, no te puedo aconsejar mejor, pues esa decisión es sobre el propio diseño del juego y eres tú el que debes decidir.
Te puedo decir que si usas piezas alineadas, el juego será algo más difícil que por contacto, pues hay menos posibilidades de eliminar piezas, pero a la hora de programar es más sencillo.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Danielo515

Mmm, creo que de momento tiraré hacia lo fácil de programar, ya que este es un proyecto con el que lo principal que busco es divertirme, y hacerlo divertido, por lo que necesito que tenga una jugabilidad agradable, y eso solo lo conseguiré con una programación eficiente, y aún tengo bugs que pulir con el control, como para meterme a complicarlo.

No he conseguido encontrar ningún columns jugable onnline, así que he jugado a uno con frutas, con solo dos piezas (igualito que cuando estaba a medio programar el mio) y pienso que al menos, mejor que ese, ya es, así que voy a seguir por este camino.

Si alguien me muestra algún columns.... le estaré agradecido.

El otro juego que dices, no se cual es.

Nadie quiere que cuando lleve una super puntuación se le caiga el juego... ¿no?

Danielo515

Bueno, he hecho algunas mejoras en el algoritmo que reconoce las filas, antes la forma mas compleja que reconocía era la L, ahora reconoce casi todas, como H o de tipo F.

Pero una vez más, me surgen dudas de como establecer ciertos comportamientos, amén de todo lo que tengo que publicar en mesa de ayuda...

Ahora, si juntas, por ejemplo, 6 piezas, aunque sean del mismo color, se las como de un golpe. Eso etá víen para las piezas del tipo
(v=verde r=rojo)
vr
vr
vr

Vale, chachi que se las ventile de golpe, pero no se si es apropiado cuando ocurre así
0vvv
r r r0

o incluso con distintas filas

RRR
000
vvv

Tambien se ventilaría las rojas y las verdes a la vez.
¿esto os parece aceptable?

Danielo515

Venga, que esto marcha, je je je.

Ya estoy bastante agusto con el reconocimiento de líneas (aunque a veces se deja combos para septiembre) y lá búsqueda de caminos ya me parece más o menos acertada (como? en un juego de bloques?) lo que me falla es fallos en la superposición de las piezas que llevo arrastrando desde el principio del desarrollo.

¿Alguien me da algún truquillo?

Danielo515

Llevo unos días dandole vueltas al control, y creo que voy a reescribir desde 0 el control de las piezas, centralizandolo para tener un mayor y mejor control, y sobre todo para ahorrarme los problemas derivados de la sincronización de procesos. Un único proceso que controle las tres piezas y que "vea" un poco el futuro de lo que va a pasar y actúe en consecuencia creo que es lo que hace falta.

De todos modos, mientras tanto he avanzado en otros campos un poco y he dado pasos atras en muchos otros.

Hojala esto llegue a buen puerto.

Windgate

Arg, no llego a entender del todo lo que pretendes, me parece muy interesante usar path_find, pero lo que dices sobre el control de que prevea lo que va a pasar... No me queda del todo claro, ¿Tienes alguna versión para descargarla y probarla?
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es