Après avoir passé du temps aujourd'hui à prendre quelques notes concernant la mise en œuvre des murs dans mon jeu basé sur les tuiles, j'ai soudain réalisé que ça ne sera pas aussi simple que je l'imaginais auparavant. Bien que l'étape actuelle de mon travail ne soit même pas proche de la création du code lié au mur, j'ai trouvé trois façons différentes de le faire. En ce moment, je ne sais pas laquelle de mes idées fonctionnera le mieux et si j'ai raté quelque chose ou non.
Important: un personnage PEUT se tenir sur une tuile qui a des murs, quelle que soit leur forme.
La chose commune pour les trois variantes: le tilemap sera "conservé" dans un conteneur std :: vector (ou similaire) à dimension unique. Les raisons de cela sont (énormément) expliquées dans les réponses à une autre question.
Classes de conteneurs dans les jeux à base de tuiles.
Retour aux murs.
A) L'approche simple.
Rien d'extraordinaire ici. Chaque conteneur de tuiles peut contenir non seulement des personnages, mais un ou plusieurs objets Mur, qui sont attachés au bord à l' intérieur de la tuile.
Avantages: facile à mettre en œuvre, rien à changer dans le moteur. Inconvénients: deux choses. Un - cela pourrait être juste dans ma tête, mais certaines combinaisons ont l'air moche. Deuxièmement - cette approche permet de réaliser une double paroi à partir de deux tuiles adjacentes. La construction sera une partie importante du jeu, et les doubles murs permettent aux constructeurs de renoncer éventuellement à la mise à niveau du matériau des murs par des moyens de jeu, et d'atteindre simplement une durabilité accrue en doublant le mur existant. Ce n'est pas souhaitable. Bien sûr, je pourrais inclure une procédure qui interdit la double paroi, mais elle aura une mauvaise impression.
B) L'approche intelligente (?).
Au lieu de laisser les joueurs doubler la carte entière, je vais les battre. Chaque mur a deux moitiés qui sont attachées au bord de la tuile de l'intérieur. Donc, pour faire une seule "unité murale", je devrai créer deux objets demi-mur dans deux tuiles adjacentes.
Avantages: C'est symétrique !!! De plus, aucun changement significatif des spécifications actuelles du moteur n'est nécessaire. Inconvénients: Plus de tracas, plus d'objets et, bien sûr, les "casquettes". Comme vous pouvez le voir sur l'image, un coin pleurera essentiellement pour un objet "cap". Je suis vraiment cool avec ça, ce n'est pas si difficile à ajouter. Hé, j'ai déjà un plan pour des colonnes minces faites de quatre bouchons connectés. Doux. Néanmoins, j'ai quelques inquiétudes concernant d'éventuels problèmes de champ de vision et de ligne de vue.
C) La variante de révision totale.
Ou, je pourrais simplement créer des bordures et des coins en tant que conteneurs séparés pour les objets de jeu. Juste comme ça.
Avantages: Pas même sûr. Eh bien, c'est simple. Absolument. Inconvénients: Cela nécessitera une refonte. Pas de code, heureusement, mais de la mentalité de mécanique de jeu actuelle - c'est sûr. Les avantages ne sont pas si évidents. De plus, cette approche nécessite beaucoup plus de conteneurs que les deux précédents. Les mathématiques d'indexation seront également un peu pénibles.
Nous l'avons donc ici - trois façons distinctes de faire des murs entre les carreaux. S'il existe des alternatives - je serai heureux de les vérifier. S'il y a des avantages / chutes à l'une des approches que je n'ai pas vues - veuillez les signaler.