Pregunta

Digamos que usted está construyendo un juego de Tetris. Como cualquier programador adecuado, que tenga su lógica de vista, por un lado, y la lógica de negocio en el otro lado; Probablemente un completo en MVC pasando.

Cuando el modelo envía su update(), la vista vuelve a dibujar en sí, como se esperaba.

Pero entonces ... si usted quiere añadir, por ejemplo, una animación a desaparecer una línea, ¿cómo poner en práctica que en la vista?

hacer ninguna suposición que desea --- excepto que "todo está encapsulado correctamente".

¿Fue útil?

Solución

En lo personal, yo separaría dibujar la pantalla tan a menudo como sea posible, aunque no había ninguna actualización de la posición del bloque. Por lo que tendría un bucle en algún lugar con un "actualización" y "render" parte. Actualización controla la pelota a la lógica que hace o no hace ninguna actualización de posiciones y / o eliminación de bloque. Render controla la pelota a la parte gráfica, que atrae a los bloques donde deben estar.

Ahora bien, si hay líneas de borrar, la lógica sabe y puede marcar las líneas que deben eliminarse. Asumo aquí, que cada pieza consta de 4 bloques individuales y cualquiera de estos bloques es un objeto único. Ahora, cuando este bloque tiene la "morir" conjunto -flag, puede tomar algunas render-partes para desaparecer el bloque (digamos, 500 ms a explotar). Después de este tiempo, el objeto puede ser dispuesto y el bloque de una línea por encima cae. ¿Por qué 500 ms? Bueno, debería utilizar movimiento basado en el tiempo ya que mantiene la velocidad del juego de la misma en diferentes equipos.

Por cierto, existen los llamados motores de juego ya que proporcionan una actualización-render-bucle de este tipo. Por ejemplo XNA, si usted va la línea de .NET. También puede codificar su propio motor, pero ten cuidado, no es una tarea fácil y es muy consumidora de tiempo. Lo hice una vez y no espero que sea un motor como el motor Source; -)

Otros consejos

La mayoría de los juegos ejecutar un bucle que redibuja constantemente la vista del juego lo más rápido posible, en lugar de esperar a que un cambio en el modelo de estado y luego actualizar la vista.

Si te gusta el patrón de vista del modelo, entonces podría funcionar bien para el fin de que siga señalando algunos tipos de objetos después de que se retiran del modelo, la decoloración de ellos a lo largo de unos pocos milisegundos.

Otro enfoque sería combinar clases MVC con algo así como la ejecución diferencial - la 'vista' es un modelo de lo que se presenta, pero el código de dibujo compara la corriente de los acontecimientos de la 'vista' crea con la corriente de la prestación anterior . Así que si en una corriente que hay una línea, y el siguiente no existe, el código de dibujo puede animar la diferencia. Esto permite que el dibujo a extraerse fuera de la vista. Con frecuencia, la 'vista' en MVC es una colección de widgets, en lugar de ser algo que atrae a la pantalla directamente, por lo que terminan con anidados jerarquías MVC de todos modos: la aplicación es MVC (modelo de datos, objetos de vista, controlador de la aplicación), donde el vista del objeto tiene una colección de widgets de cada uno de los cuales es MVC (estado del widget (por ejemplo botón pulsado), look and feel / kit de herramientas de unión, la cartografía de los acontecimientos del juego de herramientas -> estado del widget).

A menudo me he preguntado esto mismo.

Mis propios pensamientos han sido a lo largo de esta línea:

1) La vista se le da el estado de los bloques (forma, yada-yada), pero con datos extra "de transición":

2) El hecho de que una línea debe ser removido está codificada en el estado, NO computado en la vista.

3) La vista sabe cómo dibujar transiciones ahora:

  • Sin cambio: estado es el mismo para este bloque particular
  • Cambiar de "caída" a "bloqueado": estado está "bloqueado en" (por un bloque de goteo)
  • Cambiar de "bloqueado" a "eliminar": estado es "eliminado" (por una terminación de línea)
  • Cambio de "caída" para "eliminar": estado es "eliminado", pero viejo Estado se "cae"

Es interesante pensar en un juego como un MVC. Esa es una perspectiva nunca he tomado (por alguna extraña razón), pero sin duda intrigante que hace mucho sentido. Asumiendo que implementa su juego de Tetris con un MVC, creo que hay dos cosas que usted puede tener en cuenta en lo que respecta a la comunicación entre el controlador y su punto de vista: Hay estado, y hay eventos.

Su controlador es, obviamente, el punto central de la interacción para el usuario. Cuando se emiten los comandos del teclado, el controlador interpretará ellos, y hacer los ajustes apropiados del estado. Sin embargo, a veces el juego entrará en un estado que coincide con un evento en particular ... como llenar una línea con bloques que ahora deben ser eliminados.

Scoregraphic le ha dado una gran base. Su punto de vista se debe operar en un ciclo fijo para mantener la velocidad constante en todos los equipos. Pero además de la actualización de la pantalla para hacer nuevo estado, sino que también debe tener una cola de eventos que se puede realizar animaciones en respuesta a. En el caso de las líneas de llenado en Tetris, el controlador podría emitir objetos de eventos inflexible de tipos que se derivan de una especie de base de tipo de evento en la cola de vista de eventos, que podría entonces ser utilizada por el punto de vista para realizar las respuestas animadas apropiados.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top