¿Cómo debo diseñar un OO Pong "Adecuado"?OO Pong Propia
La idea de que cualquier elemento puede cambiarse: la forma de la pelota, la cancha y las paletas, añadiendo obstáculos e incluso "mejoras", como "puede pegar la pelota a la paleta".
Las dos preguntas más apremiantes, en este momento, son:
Imagino que podría hacer un objeto de motor de física que actualice continuamente en intervalos de tiempo determinados. Verificaría colisiones, movería la bola, calcularía los ángulos de rebote, etc.
EDIT # 1: Para agregar un poco más de detalle, el objeto "física del juego" almacenaría, entre otras cosas, referencias a otros objetos del juego como la pelota y las paletas. El objeto de física del juego tendría un método de "actualización" que se llamaría continuamente a medida que el juego se ejecuta. Algunos de los pasos que este método realizaría son:
Solo algunas ideas.
editar # 2: Elaborar con un poco más de un enfoque orientado a objetos ...
Los diversos objetos físicos, como la bola y las paletas, almacenaría estados físicos innatos y los parámetros por sí mismos (posición, velocidad, masa, etc.) como propiedades. El objeto de física del juego representaría esencialmente todas las ecuaciones del movimiento físico como métodos.
Como ejemplo ... Supongamos que desea modelar los efectos de la fricción del aire sobre la bola. El objeto pelota almacenaría propiedades como "velocidad" y "coeficiente de arrastre". El objeto de física del juego tendría un método para calcular la fuerza de la resistencia del aire en un objeto obteniendo las propiedades necesarias de ese objeto y conectándolo a una ecuación dada de fluid drag.
Al encapsular las cosas de esta manera, las actualizaciones del código pueden ser más fáciles. Por ejemplo, si quiere usar una ecuación diferente para el arrastre fluido, la única modificación que necesita hacer es el método apropiado del objeto de física del juego. Ninguno de los otros objetos necesita ser modificado.
Me parece que la corte sería el objeto apropiado para hacer la comprobación, o dependiendo de cuán compleja sea la lógica, una clase separada para lidiar con colisiones (es decir, algún tipo de motor de física como gnovice).
Las bolas y las paletas no deberían tener que conocerse entre sí, ya que no están directamente relacionadas en un sentido orientado a objetos.Uno no contiene el otro ni uno deriva del otro.
En una configuración típica como esta. Cada objeto tiene la oportunidad de responder al evento de colisión con cualquier otro objeto con el que interactúa. En una especie de pseudo (pitón) Código:
class Moveable:
def Update(self):
self.move()
class Ball(Moveable):
def Collide(self, target):
self.restore() # move out of the bounding box
# of whatever we collided into from
self.reflect() # change direction after bouncing
if target is a Paddle:
self.speedup() # Make it a little harder after hitting a paddle
class Paddle(Moveable):
def Collide(self, target):
if target is a Ball:
self.AwardSomePoints()
def main_loop():
...
while True:
for thing_one in Moveables:
thing_one.Update()
for thing_two in Moveables:
if thing_one is not thing_two
and thing_one is touching thing_two:
thing_one.collide(thing_two)
me gusta usar la metodología Modelo-Vista-Controlador así que en ese caso, tendría un dispositivo de juego que se ocuparía de control de la colisión pero en la perforación hasta que sólo lo haría controlar un controlador ... es demasiado complicado de explicar aquí y no soy tan inteligente así que compruébalo: