Я работал над настольной игрой с шестигранной сеткой, такой как эта доска:
Поскольку доска никогда не изменится, и пробелы на плате всегда будут связаны с одними и теми же пробелами вокруг нее, должен ли я просто жестко кодировать каждый пробел со значениями, которые мне нужны? Или я должен использовать различные алгоритмы для расчета ссылок и обходов?
Если быть более точным, моя настольная игра - это игра для 4 игроков, в которой каждый игрок имеет гекс-сетку 5x5x5x5x5x5 (опять же, изображение выше). Цель состоит в том, чтобы добраться от нижней части сетки к вершине, с различными препятствиями на пути, и каждый игрок может атаковать друг друга с края своей сетки на других игроков на основе множителя дальности.
Поскольку сетка игроков никогда не изменится, и расстояние любого произвольного пространства от края сетки всегда будет одинаковым, следует ли просто жестко кодировать это число в каждом из пространств, или я все равно должен использовать алгоритм поиска в ширину, когда игроки атакуют?
Единственный недостаток, который я могу придумать для жесткого кодирования всего, это то, что я собираюсь кодировать 9+ 2 (5 + 6 + 7 + 8) = 61 отдельная ячейка. Есть ли что-то еще, что мне не хватает, что я должен рассмотреть использование более сложных алгоритмов?
источник
int numberOfHexagonsInArea(int rows) { int area = 1; while(rows>0) { area += (rows-1)*6; rows--; } return area; }{X,Y}вас, очевидно, можно пойти{X-1, Y}и{X+1, Y}на один ряд. В строках ниже и выше вы можете перейти к{X, Y-1}и{X, Y+1}. Наконец, в зависимости от четно-ностиY, вы можете пойти{X-1, Y-1}и{X-1, Y+1}или {X + 1, Y-1} `и{X+1, Y+1}Ответы:
Я предполагаю, что я возьму контрапункт здесь и поспорю против использования статических значений. В этом случае все шестнадцатеричные области, о которых вы говорите, (а) просты для вычисления - вам не нужно использовать BFS или что-то настолько сложное; у вас должна быть возможность перебирать все гексы в любом из них с помощью простых двойных вложенных циклов; и (б) не то, что вам нужно будет вычислять «на лету» очень часто. В худшем случае вы должны только вычислить их один раз в свою очередь, и если несколько систем действительно хотят клетки прикасались эффект , то вы можете легко кэшировать значения прочь в массив «reachableCells» или нечто подобное; Тем не менее, вычисления настолько просты, что их можно эффективно использовать с точки зрения затрат на кадр.
Так что вы получаете за это? Гибкость. Сейчас легко сказать, что эти значения никогда не изменятся, но игры умеют удивлять вас; даже если более вероятно, что эти регионы не изменятся, вы, по сути, ничего не потеряете, создав такую гибкость, и есть большая вероятность того, что в будущем вы будете благодарны вам в будущем. Более того, даже если это последние области, которые вы используете, хорошо написанные циклы для итерации по регионам будут значительно легче понять и отладить, чем любой вид массива с фиксированными тайлами. Я просто не вижу сколько-нибудь значимого выигрыша от использования жестко закодированных данных по сравнению с преимуществами перехода в другую сторону.
источник
Если значения никогда не изменятся, они также могут быть статическими. Зачем тратить время ЦП на пересчет чего-то, что будет таким же, как в прошлый раз?
Тем не менее, они не обязательно должны быть жестко закодированы:
Первый способ имеет смысл, если вы думаете, что можете изменить форму или размер карты в будущем. Второй способ имеет смысл, если вычисление статических значений немного сложнее.
Я понятия не имею, как выглядит шестимерная шестнадцатеричная карта или почему задействовано 9 + 2 (5 + 6 + 7 + 8) ячеек, но лучший результат для вашей ситуации - и, действительно, большинства ситуаций в программировании игр - это кодировать во что бы то ни стало, вы получите правильный результат наиболее быстро. Вы можете обобщить его на алгоритм позже, если вам нужно. «Код на сегодня», как говорят некоторые.
источник
Q: это единственная гекс игра, которую ты когда-либо пишешь? Нет?
A: Тогда, очевидно, вы должны попытаться проявить гибкость, где бы это не стоило вам больших дополнительных усилий. Независимо от того, как вы определяете плату, представляйте ее во время выполнения с явными ссылками. Очень удобно кодировать логику движения и взаимосвязи с точки зрения обхода ссылок, которая не зависит от размера или топологии платы.
источник