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.