Programación de juegos sin un ciclo principal

Question

Mi profesor asignó hoy a mi clase una tarea basada en la programación orientada a objetos en Pygame. Básicamente, él ha dicho que el juego que vamos a crear estará vacío de un ciclo principal de juego. Si bien creo que es posible hacer esto (y this question ha declarado que es posible), no creo que esto sea necesario para la adhesión al paradigma orientado a objetos.

En un diagrama que dio el profesor, mostró la inicialización del juego y, a medida que se creaban las instancias, el flujo de control del programa se distribuiría entre los objetos.

Básicamente, creo que sería posible implementar un juego de esta manera, pero no sería una forma ideal ni es necesaria para la adherencia orientada a objetos. ¿Alguna idea?

EDIT: Estamos creando un clon de asteroides, que creo que complica aún más las cosas debido a que es un juego de acción en tiempo real.

Answer 1

Los juegos basados ​​en turnos o cualquier otro evento impulsado sería el camino a seguir. En otras palabras, tome aplicaciones de GUI de escritorio. Simplemente marcarán (esperarán) hasta que se dispare un evento. Lo mismo podría hacerse para un juego simple. Tome Checkers por ejemplo. Looping cada ciclo de juego sería excesivo. El 90% del tiempo el juego será estático. Usar algún tipo de evento (el patrón observer design sería bueno aquí) proporcionaría una solución mucho mejor. Estás usando Pygame, por lo que puede haber soporte para esto, debido a mi uso limitado, no puedo comentarlo completamente. De cualquier manera, los principios generales son los mismos.

En general, es una asignación bastante basura si me preguntas. Si es para enseñarle la programación impulsada por eventos, una aplicación GUI simple sería mejor. Incluso los juegos más simples son un bucle de juego básico, que puede cumplir con los principios de OO.

Answer 2

Creo que podría calificar como programación impulsada por eventos? Que aún puede estar orientado a objetos. Ves esto en Flash mucho.

Hay una diferencia entre un bucle principal en una clase principal. Aún puede tener una clase de juego para inicializar todos sus objetos y luego confiar en las entradas para avanzar el juego.

Algo difícil de decir exactamente sin conocer los parámetros exactos de su tarea, el diablo está en los detalles.

Answer 3

Puede ver cómo python utiliza las señales. Un buen ejemplo que encontré es en: http://docs.python.org/library/signal.html

Answer 4

Hmm. En el caso general, creo que esta idea es probablemente Hokum. SDL (sobre el cual se implementa PyGame), proporciona información al programa a través de una cola de eventos, y consumir esa cola requiere algún tipo de comprobación de la cola en busca de eventos, procesarlos y esperar hasta que llegue el próximo evento.

Sin embargo, existen algunas excepciones particulares a esto. Puede sondear el mouse y el teclado para conocer su estado sin acceder a la cola de eventos. El problema con eso es que todavía requiere algo así como un bucle, para que ocurra una y otra vez hasta que el juego termine.

Puede esperar pygame.time para esperar un temporizador en lugar de esperar en la cola de eventos, y luego pasar el control a los objetos del juego que sondean el mouse y el teclado como se indicó anteriormente, pero todavía está 'en bucle', pero limitado por un temporizador en lugar de la cola de eventos.

En lugar de centrarse en la eliminación de un bucle principal, ¿qué le parece pensar en usarlo de una manera orientada a objetos.

Por ejemplo, podría necesitar un objeto 'raíz', que en realidad tiene su propio bucle de eventos, pero en lugar de realizar cualquier acción basada en los eventos entrantes, llama a un controlador en varios objetos secundarios. Por ejemplo, cuando el objeto raíz recieves un evento pygame.event.MOUSEBUTTONDOWN, podría buscar a través de él de los niños para un atributo 'rect' y determinar si el atributo es event.pos dentro de esa rect. si lo es, puede invocar un método hipotético onClick en ese objeto secundario.