oop - programar - detectar colisiones android studio

Good Object Oriented Class Design para la detección de colisiones en el desarrollo de juegos.

Question

Quiero aprender cómo crear una buena práctica de diseño orientada a objetos (OO) para colisión entre la situación de dos objetos en el desarrollo del juego.

Digamos que tengo una clase de SpaceShip y una clase de Meteor. Cuando Meteor choca con el SpaceShip, el SpaceShip será destruido.

La pregunta: ¿en qué clase debo poner el método para verificar si hay colisión entre el meteoro y la nave espacial, así como el método de resolución de colisión (destruir la nave espacial)? ¿Está en la clase SpaceShip o en la clase Meteor? O tal vez debería poner en otra clase, es decir. ¿Clase de GameArea o GameController?

Nota: por motivos de simplicidad, suponga que Meteor y SpaceShip están en forma de recurso de imagen. Estoy acostumbrado a usar el lenguaje Java, pero otro idioma también está bien.

Answer 1

Bueno, normalmente creo una clase o interfaz GameObject (a veces genérica) que tiene un método de colisión. Por ejemplo:

template< typename T = int > class GameObject
{
public:
    bool collides(const GameObject& obj);
};

// usage
GameObject<int> my_obj, your_obj;
if(my_obj.collides(your_obj)) { ... };

Otra cosa que a veces (pero rara vez) hago es crear una clase separada de GamePhysics :

template< typename T > class GamePhysics
{
public:
    /* you may make this static or the class a singleton */
    void detect_collision(const T& obj, const T& obj2);
};

Answer 2

En Java (o en cualquier otro lenguaje OO) pondría un evento / devolución de llamada CollisionDetected en la clase ancestral común de todos los objetos en movimiento en su juego.

Esta es una descripción simplificada de un juego:

• En un juego, generalmente hay un bucle de juego . Un bucle de juego es como un bucle while (verdadero) que se ejecuta de forma continua (como el hilo principal de la interfaz de usuario de una aplicación) y en cada paso comprueba qué ha cambiado con los objetos, qué debe actualizarse y qué eventos deben llamarse ( y más...).

• Para la capacidad de respuesta, este bucle debe realizar un ciclo muchas veces por segundo.

• Dentro de este bucle, un objeto del motor de física debe actualizar continuamente su estado. Este sería un objeto de instancia de una clase independiente. Es este motor el que debe detectar colisiones entre objetos y llamar al evento CollisionDetected en todos los objetos que han colisionado.

Es una idea, no la solución definitiva ...

Answer 3

Es más natural pensar que la detección de colisiones es una responsabilidad que no pertenece a las clases de Spaceship o Meteor. Especialmente cuando esto se complica con múltiples posibilidades de colisión en diferentes direcciones. Si coloca esta lógica en estas dos clases, deberán tener referencias a muchos otros objetos que están a su alrededor, lo que no sería apropiado.

Podría tener esto en una clase separada, como CollisionDetector, que realiza un seguimiento de las coordenadas de todos los objetos en el espacio del juego y detecta colisiones. La prevención de colisiones también parece ser una responsabilidad separada que, en mi opinión, debería estar en una clase diferente. Usted podría tener una clase separada CollisionResolver para esto. Dependiendo de los requisitos, CollisionDetector podría hablar con CollisionResolver .

Es posible que CollisionResolver tenga que poder hablar con las Naves Espaciales, con el propósito de recomendarles que cambien de dirección o de mandar misiles de tiro hacia el Meteor.

CollisionDetector y CollisionResolver podrían ubicarse dentro del GameSpace / * GameController *. etc.

Esto promovería el principio de responsabilidad única, por lo que cada componente estaría haciendo solo una tarea enfocada.

Answer 4

La detección de colisiones, en mi opinión, no es parte de un objeto ... debería definirse como otra cosa: un administrador de física, etc. De esa manera, sus objetos serán independientes de los algoritmos de colisión.

Otra cosa es que en los juegos, por lo general, el objeto consta de varias capas (componentes): Capa de gráficos, Capa de física, Capa lógica. De esa manera, el administrador de física solo administra el componente de física de los objetos dados.

class GameObject 
{
    RenderComponent  m_renderComponent;
    LogicComponent   m_aiComponent;
    PhysicsComponent m_physicsComponent;
};