Juego de diseño de manera OO

Question

Estoy diseñando un juego simple, que usa la física 2D y Newtoniana de Java. Actualmente mi principal "bucle del juego" se ve algo como:

do { 
    for (GameEntity entity : entities) { 
    entity.update(gameContext); 
    } 

    for (Drawable drawable : drawables) { 
    drawable.draw(graphics2d); 
    } 
} while (gameRunning); 

Cuando una entidad se le instruye para actualizarse a sí mismo que ajustará su velocidad y posición sobre la base de las fuerzas de corriente aplicada a la misma. Sin embargo, necesito entidades para exhibir otro comportamiento; p.ej. si un "jugador malo" es disparado por un jugador, la entidad debería ser destruida y eliminada del mundo del juego.

Mi pregunta: ¿Cuál es la mejor manera de lograr esto de una manera orientada a objetos? Todos los ejemplos que he visto hasta ahora incorporan el bucle del juego en una clase de Dios llamada algo así como Game, que realiza los pasos: detectar colisiones, verificar si el chico malo mató, verificar si el jugador murió, volver a pintar , etc. y encapsula todo el estado del juego (vidas restantes, etc.). En otras palabras, es muy procedural y toda la lógica está en la clase de juego. ¿Alguien puede recomendar un mejor enfoque?

Estas son las opciones que he pensado hasta ahora:

• pasar una GameContext a cada entidad de la que la entidad puede sustraerse si se requiere o actualizar el estado del juego (por ejemplo, a "no funcionando" si el jugador es asesinado).
• Registre cada GameEntity como escucha de la clase central Game y adopte un enfoque orientado a eventos; p.ej. una colisión resultaría en el disparo de un CollisionEvent a los dos participantes en la colisión.

Answer 1

He trabajado en estrecha colaboración con dos motores de juego comerciales y siguen un patrón similar:

• objetos representan componentes o aspectos de una entidad de juego (como, sea cual sea física, renderable), en lugar de toda entidad . Para cada tipo de componente, hay una lista gigante de componentes, uno para cada instancia de entidad que tiene el componente.

• El tipo de 'entidad de juego' en sí es solo un ID único. Cada lista gigante de componentes tiene un mapa para buscar el componente (si existe) que corresponde a una ID de entidad.

• Si un componente requiere una actualización, lo llama un servicio u objeto del sistema. Cada servicio se actualiza directamente desde el bucle del juego. Alternativamente, puede llamar a servicios desde un objeto del planificador que determina el orden de actualización desde un gráfico de dependencia.

Estas son las ventajas de este enfoque:

• Es posible combinar libremente funcionalidad sin escribir nuevas clases para cada combinación o el uso de herencia compleja árboles.

• No hay casi ninguna funcionalidad que se puede asumir sobre todo el partido entidades que se puede poner en una clase base entidad juego (lo que hace un ligero tienen en común con un coche de carreras o un cielo caja ?)

• el Id-al componente look-ups pueden parecer caro, pero los servicios están haciendo mayor parte del trabajo intensivo por parte iteración a través de todos los componentes de un tipo particular. En estos casos, funciona mejor para almacenar todos los datos que necesita en una sola lista de orden.

Answer 2

En un motor particular en el que trabajé, desacoplamos la lógica de la representación gráfica y luego teníamos objetos que enviarían mensajes para lo que querían hacer. Hicimos esto para que pudiéramos tener juegos en una máquina local o en una red y no se distinguían entre sí desde el punto de vista del código. (Patrón de comando)

También hicimos el modelado de física real en un objeto separado que podría cambiarse sobre la marcha. Esto nos permite complicarnos fácilmente con la gravedad, etc.

Hicimos un uso intensivo del código de evento (patrón de escucha) y de muchos temporizadores.

Por ejemplo, teníamos una clase base para un objeto que era intersectable y que podía escuchar el evento de colisión. Lo subclasificamos en un cuadro de salud. En caso de colisión, si era golpeado por una entidad de jugador, enviaba un Comando al colisionador que indicaba que debería mejorar, enviaba un mensaje para transmitir un sonido a todos los que podían oírlo, colisiones desactivadas, activaba la animación para eliminar los gráficos el gráfico de escena, y establecer un temporizador para reinstalarse más tarde. Parece complicado, pero realmente no lo fue.

Si no recuerdo (y han pasado 12 años), teníamos la noción abstracta de escenas, por lo que un juego era una secuencia de escenas. Cuando se terminó una escena, se desencadenó un evento que típicamente enviaría un comando para desmontar la escena actual y comenzar otra.

Answer 3

No estoy de acuerdo porque debido a que tienes una clase principal de Juego, toda la lógica tiene que ocurrir en esa clase.

La simplificación excesiva aquí imitando el ejemplo que se acaba de hacer mi punto:

mainloop: 
    moveEntities() 
    resolveCollisions() [objects may "disappear"/explode here] 
    drawEntities()  [drawing before or after cleanEntitites() ain't an issue, a dead entity won't draw itself] 
    cleanDeadEntities() 

Ahora usted tiene una clase de la burbuja:

Bubble implements Drawable { 

handle(Needle needle) { 
    if (needle collide with us) { 
     exploded = true; 
    } 
} 

draw (...) { 
    if (!exploded) { 
     draw(); 
    } 
    } 
} 

Así que, claro, hay un bucle principal que se encarga de pasando los mensajes entre las entidades, pero la lógica relacionada con la colisión entre una burbuja y una aguja definitivamente no está en la clase principal del juego.

Estoy bastante seguro de que, incluso en su caso, toda la lógica relacionada con el movimiento no está sucediendo en la clase principal.

No estoy de acuerdo con su declaración, que escribió en negrita, que "toda la lógica ocurre en la clase principal".

Esto simplemente no es correcto.

En cuanto al buen diseño: si puede proporcionar fácilmente otra "vista" de su juego (como, por ejemplo, un mini-mapa) y si puede codificar fácilmente un "reproductor perfecto fotograma por fotograma", entonces su el diseño probablemente no sea tan malo (es decir: al registrar solo las entradas y el tiempo en el que ocurrieron, debería poder recrear el juego exactamente como se jugó. Así es como Age of Empires, Warcraft 3, etc. repetición: solo las entradas del usuario y la hora en que sucedieron se graban [también es por eso que los archivos de reproducción son típicamente tan pequeños]).

Answer 4

Este game fue un experimento para mantener el modelo y la vista por separado. Utiliza el patrón del observador para notificar la (s) vista (es) de los cambios en el estado del juego, pero los eventos quizás ofrezcan un contexto más rico. Originalmente, el modelo se basaba en la entrada de teclado, pero la separación facilitaba la incorporación de animaciones controladas por temporizador.

Adición: Debe mantener el modelo del juego por separado, pero puede volver a factorizar ese modelo en tantas clases como sea necesario.

Answer 5

Escribo mis propios motores (raw & sucio), pero un motor preconstruido que tiene un modelo de OO decente, es Ogre. Recomiendo echarle un vistazo (es un modelo de objeto/API). La asignación de nodo es un poco funky, pero tiene mucho sentido cuanto más lo miras. También está muy bien documentado con un montón de ejemplos de juegos de trabajo.

He aprendido un par de trucos de él mismo.

Answer 6

Solo estoy publicando esto como respuesta porque aún no puedo comentar otras publicaciones.

Como una adición a Evan Rogers excelente respuesta que podría estar interesado en estos artículos:

http://www.gamasutra.com/blogs/MeganFox/20101208/6590/Game_Engines_101_The_EntityComponent_Model.php

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/