Almacenar y recuperar diferentes objects en un azulejo

(Espero que el título sea lo suficientemente claro, si no sientes libre de sugerir uno mejor)

Intento hacer un map simple basado en mosaicos para un proyecto universitario en Java. Pero estoy atascado en cómo colocar cosas literalmente en mi map. En lo que respecta a la progtwigción, todavía no me he metido en los charts sobre esto. A partir de ahora tengo:

Una class "Robot", que implementa una interfaz "atacable" y "Spawnable", el robot puede atacar y mover

Una class de "Obstáculo", el obstáculo también puede ser atacado, por lo que implementa Attackable, Spawnable, pero también puede ser empujado por un robot (methods de la class misma).

Una "Estación", que no es ni atacable ni puede ser empujada, por lo que solo implementa Spawnable y otros methods específicos.

Una class "GameWorld" que contiene el map (una matriz 2D de Tiles) y varios methods. Una class "Tile" (que está orderada para crear el map). Tiene un boolean "Ocupado" (que también funciona como colisión). Previamente almacenaba una sola variable atacable, porque tanto los obstáculos como el robot pueden ser atacados, así que simplemente pensé que sería fácil simplemente almacenarlos como tales en el map para cuando necesito atacar algo, y luego usar otra reference a Robot instancias cuando necesito mover los robots y tener una reference a la estación en GameWorld para usar eso. Pero luego recordé que los Obstáculos también deben moverse, por lo que no funcionaría realmente.

Ahora estoy pensando en tener dos maps, básicamente, un AttackableMap [] [] para el object atacable (que almacenaría tanto los robots como los obstáculos) y un ObstaclesMap [] [] solo para los obstáculos (con los tiles ocupados por los robots) como ocupado). Lo que obviamente significaría tener dos classs de fichas, una para contener cada tipo de object.

Pero parece barato, creo. Utiliza mucha memory y creo que podría ser difícil de reproducir en un momento posterior. Pero tener solo un map significaría tener que verificar qué tipo de object recibiré y tendría que hacer muchos moldes y quiero evitar eso.

Entonces, creo, debe haber una mejor manera de hacer esto. ¿Cómo lo hacen otras personas entonces? Así que, básicamente, mi pregunta es … ¿Cómo puedo almacenar diferentes "cosas" en un map de azulejos de una mejor manera? ¿Hay alguna técnica ampliamente utilizada?

Lo que he pensado se siente rígido, si quisiera agregar otro tipo de object que pueda colocarse en el map (como una mina), necesitaría crear otro map completamente, otro mosaico, escribir nuevos methods … Allí debe ser una forma flexible (y no demasiado compleja) de tener cierta libertad en este aspecto.

En este momento, tiene una matriz de Tile que tiene un valor boolean Occupied , y anteriormente tenía un valor Attackable . Estás sugiriendo que tienes varias matrices de teselas, una para almacenar las cosas Attackable y otra para almacenar los Obstacles . No creo que este sea el mejor enfoque para ti.

Debe tomar la decisión sobre si un Tile puede tener más de un object. Por ejemplo, ¿qué pasa si un Robot tiene la capacidad de moverse a través de las panetworkinges? ¿O si hubo un encendido que el jugador pudo recoger que les dio esa habilidad? Así que supongamos que teóricamente es posible que más de un object esté en un Tile .

En este caso, podría darle al Tile una matriz de objects, y cuando un Robot o un Obstacle mueva a ese mosaico, podría agregarse a ese set y eliminarse del set de mosaicos anterior. Para que esto funcione, todas las cosas movibles tendrían que henetworkingarse de la misma class, como una class Moveable o Character , y la matriz de la Tile sería una matriz de este tipo. De esta forma, cualquier subclass de ese tipo podrá ingresar a la matriz de Tile .

Cuando desee verificar si una tesela es atacable u ocupada, podría tener un método de la class Tile que busque a través de la matriz, buscando un Robot o un Obstacle o lo que sea que necesite.

Hay muchas forms diferentes de resolver este problema, pero como le preocupa la inflexibilidad de su enfoque actual, creo que esta es una forma válida de progtwigrlo.