Después de pasar tiempo hoy para anotar algunas notas sobre la implementación de paredes en mi juego basado en fichas, de repente me di cuenta de que no será tan simple como imaginé antes. Si bien la etapa actual de mi trabajo ni siquiera está cerca de hacer el código relacionado con el muro, he encontrado tres formas diferentes de hacerlo. En este momento no estoy seguro de cuál de mis ideas funcionará mejor y si me perdí algo o no.
Importante: un personaje PUEDE pararse en una ficha que tiene paredes, independientemente de su forma.
Lo común para las tres variantes: el mosaico se "mantendrá" en un contenedor basado en std :: vector (o similar) de una sola dimensión. Las razones para eso se explican (asombrosamente) en las respuestas a una pregunta diferente.
Clases de contenedores en juegos basados en fichas.
De vuelta a las paredes.
A) El enfoque simple.
Nada lujoso aquí. Cada contenedor de mosaico puede contener no solo caracteres, sino uno o varios objetos de Muro, que están unidos al borde dentro del mosaico.
Pros: fácil de implementar, nada que cambiar en el motor. Contras: dos cosas. Uno: puede ser solo en mi cabeza, pero algunas combinaciones se ven feas. Segundo: este enfoque permite hacer una doble pared a partir de dos fichas adyacentes. La construcción será una parte importante del juego, y las paredes dobles permiten a los constructores renunciar posiblemente a mejorar el material de las paredes a través de los medios del juego, y solo lograr una mayor durabilidad duplicando la pared existente. Eso no es deseable. Claro, podría incluir un procedimiento que prohíba las paredes dobles, pero tendrá un mal presentimiento.
B) El enfoque inteligente (?).
En lugar de dejar que los jugadores doblen todo el mapa, voy a vencerlos. Cada pared tiene dos mitades que están unidas al borde de la baldosa desde adentro. Entonces, para hacer una sola "Unidad de pared", tendré que crear dos objetos de Media pared en dos fichas adyacentes.
Pros: ¡Es simétrico! Además, no se necesita un cambio significativo de las especificaciones actuales del motor. Contras: Más problemas, más objetos y, por supuesto, los "topes". Como puede ver en la imagen, una esquina básicamente llorará por un objeto "cap". En realidad estoy bien con eso, no es tan difícil de agregar. Oye, ya tengo un plan para columnas delgadas hechas de cuatro tapas conectadas. Dulce. Aún así, tengo algunas preocupaciones sobre posibles problemas de campo de visión y línea de visión.
C) La variante de revisión total.
O bien, podría crear bordes y esquinas como contenedores separados para los objetos del juego. Así.
Pros: ni siquiera estoy seguro. Bueno, es sencillo. Seguro. Contras: requerirá una revisión. Afortunadamente, no de código, sino de la mentalidad mecánica actual del juego, eso es seguro. Los beneficios no son tan obvios. Además, este enfoque requiere muchos más contenedores que los dos anteriores. La matemática de indexación también será un poco dolorosa.
Así que aquí lo tenemos: tres formas distintas de hacer muros entre azulejos. Si hay alguna alternativa, estaré encantado de revisarla. Si hay algunos beneficios / caídas en cualquiera de los enfoques que no vi, por favor indíquelos.
fuente
Respuestas:
Usaría tu método 'B'.
Para evitar la necesidad de 'tapas', simplemente extienda cada pared "1/2 espesor de pared" en ambas direcciones. Esto creará paredes superpuestas donde se encuentran, pero sus diagramas ya sugieren que esto no es un problema.
Entonces, en el Método 'B', Imagen # 3, la pared horizontal se extendería un poco hacia la izquierda, y la pared vertical se extendería un poco.
[Soy nuevo aquí, recién registrado. Me falta algo, ya que no puedo ver el botón "Agregar comentario" a tu publicación original. ¿Es un privilegio de las personas con mayor reputación? ¿O estoy pasando por alto lo obvio? Perdón por agregar esto como una "respuesta".]
fuente
Notaste que un personaje puede pararse en un mosaico que contiene una pared, pero ¿has considerado tratar cada mosaico como el muro mismo? ¿Incluso la mitad de un azulejo como pared en forma horizontal o vertical?
Pros: Los cálculos y las ubicaciones son triviales, la colisión es trivial donde todos los cálculos y colisiones se basan solo en las coordenadas de la colocación de las paredes.
Contras: Podría afectar toda su implementación, código y gráficos. Tampoco desea abandonar totalmente su método, aún desea casos especiales en los que solo una parte de un mosaico sea muro (Enlace al pasado con acantilados).
Así es como habría basado mi implementación, avanzando, sabiendo que siempre puedo hacer referencia a un mosaico y realizar un cálculo en función de la ubicación de mis personajes y de qué tipo de mosaico es.
Una pared del castillo que podría realizar un cálculo desde el centro dibujando una caja que no podría atravesar o si es una roca redonda podría hacer el mismo cálculo desde el centro pero como un círculo para que mi personaje pueda moverse como si fuera redondeado.
fuente
Lamento decirlo, pero la tercera forma es realmente la forma de pensar, bueno, ¡ya tienes la capacidad de hacerlo, así que sigamos y pensemos en las otras dos!
La cosa es que una pared es un cuadrado de ancho cero, dos dimensiones (altura * longitud, en un mundo 3D) que divide dos cajas. Debes considerarlos como tales, pero podrías usar una solución más simple como cuándo construir tu mazmorra (especialmente si otras personas pueden construir partes).
Parece que es un juego 2D de arriba hacia abajo donde las paredes tienen "un ancho", por lo que necesitan esa esquina (su objeto 'cap'). Sin embargo, esto es exclusivamente 'gráficos', así que iría con algún tipo de:
Un mapa 2D con los mosaicos (es decir, tipo de mosaico y tal).
Un mapa 2D con 2 paredes, ej. abajo y derecha (la pared izquierda será la 'pared derecha' en el mosaico a la izquierda de esta).
+ una lógica que dibuja todas las paredes y 'tapas', etc.
Separando así la lógica y los gráficos. Puede hacer una "interfaz" ocupándose de cosas como SetWall (ThisTile, LEFT, NOWALL) -> configurando la pared derecha del mosaico a la izquierda de ThisTile en "NOWALL" ...
Tal vez esto parezca borroso, pero la cuestión es que siempre debe tratar de tener a un lado la lógica (los datos reales, sin redundancia) y, por el otro lado, el 'dibujo de los datos' que calcula si es necesario un 'límite' 'etc.
++
fuente