Лучше ли жестко закодировать данные или найти алгоритм?

8

Я работал над настольной игрой с шестигранной сеткой, такой как эта доска:

Поскольку доска никогда не изменится, и пробелы на плате всегда будут связаны с одними и теми же пробелами вокруг нее, должен ли я просто жестко кодировать каждый пробел со значениями, которые мне нужны? Или я должен использовать различные алгоритмы для расчета ссылок и обходов?

Если быть более точным, моя настольная игра - это игра для 4 игроков, в которой каждый игрок имеет гекс-сетку 5x5x5x5x5x5 (опять же, изображение выше). Цель состоит в том, чтобы добраться от нижней части сетки к вершине, с различными препятствиями на пути, и каждый игрок может атаковать друг друга с края своей сетки на других игроков на основе множителя дальности.

Поскольку сетка игроков никогда не изменится, и расстояние любого произвольного пространства от края сетки всегда будет одинаковым, следует ли просто жестко кодировать это число в каждом из пространств, или я все равно должен использовать алгоритм поиска в ширину, когда игроки атакуют?

Единственный недостаток, который я могу придумать для жесткого кодирования всего, это то, что я собираюсь кодировать 9+ 2 (5 + 6 + 7 + 8) = 61 отдельная ячейка. Есть ли что-то еще, что мне не хватает, что я должен рассмотреть использование более сложных алгоритмов?

algorithm procedural-generation hexagonal-grid

— OghmaOsiris
источник

Я могу сказать вам, что область для атаки радиусом равна 1 плюс сумма членов последовательности, заданных как f (n) = 6 (n-1) от n = 1 до n = x, где x - количество строк. EG 3 ряда (радиус 10 футов) = 1 + 6 + 12 = 19

— eazimmerman

Вот псевдокод того, что я описал

int numberOfHexagonsInArea(int rows)   {    	int area = 1;   	while(rows>0)   	{   		area += (rows-1)*6;   		rows--;   	}   	return area;   }

— eazimmerman

Это не кажется очень сложным? От {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}

— MSalters

12

Я предполагаю, что я возьму контрапункт здесь и поспорю против использования статических значений. В этом случае все шестнадцатеричные области, о которых вы говорите, (а) просты для вычисления - вам не нужно использовать BFS или что-то настолько сложное; у вас должна быть возможность перебирать все гексы в любом из них с помощью простых двойных вложенных циклов; и (б) не то, что вам нужно будет вычислять «на лету» очень часто. В худшем случае вы должны только вычислить их один раз в свою очередь, и если несколько систем действительно хотят клетки прикасались эффект , то вы можете легко кэшировать значения прочь в массив «reachableCells» или нечто подобное; Тем не менее, вычисления настолько просты, что их можно эффективно использовать с точки зрения затрат на кадр.

Так что вы получаете за это? Гибкость. Сейчас легко сказать, что эти значения никогда не изменятся, но игры умеют удивлять вас; даже если более вероятно, что эти регионы не изменятся, вы, по сути, ничего не потеряете, создав такую гибкость, и есть большая вероятность того, что в будущем вы будете благодарны вам в будущем. Более того, даже если это последние области, которые вы используете, хорошо написанные циклы для итерации по регионам будут значительно легче понять и отладить, чем любой вид массива с фиксированными тайлами. Я просто не вижу сколько-нибудь значимого выигрыша от использования жестко закодированных данных по сравнению с преимуществами перехода в другую сторону.

— Стивен Стадницки
источник

11

Если значения никогда не изменятся, они также могут быть статическими. Зачем тратить время ЦП на пересчет чего-то, что будет таким же, как в прошлый раз?

Тем не менее, они не обязательно должны быть жестко закодированы:

Вы можете поместить значения в файл данных и загрузить их в самом начале.
Вы можете выполнять поиск во время воспроизведения и кэшировать значения, как только найдете их.

Первый способ имеет смысл, если вы думаете, что можете изменить форму или размер карты в будущем. Второй способ имеет смысл, если вычисление статических значений немного сложнее.

Я понятия не имею, как выглядит шестимерная шестнадцатеричная карта или почему задействовано 9 + 2 (5 + 6 + 7 + 8) ячеек, но лучший результат для вашей ситуации - и, действительно, большинства ситуаций в программировании игр - это кодировать во что бы то ни стало, вы получите правильный результат наиболее быстро. Вы можете обобщить его на алгоритм позже, если вам нужно. «Код на сегодня», как говорят некоторые.

— Kylotan
источник

Все это. Сначала

— заставьте

2

Просто чтобы прояснить вашу путаницу, я думаю, что ОП, когда речь идет о шестнадцатеричной сетке 5x5x5x5x5x5, не имел в виду 6 физических (или виртуальных) измерений, а вместо этого шестиугольник шестиугольников, где каждая сторона шестиугольника содержит 5 меньших шестиугольников вдоль своей длины, похоже на это (игнорировать черные точки). В этом случае доска будет содержать 9 + 2 (5 + 6 + 7 + 8) клеток.

Да, я видел это из диаграммы, опубликованной в редактировании.

— Kylotan

0

Q: это единственная гекс игра, которую ты когда-либо пишешь? Нет?

A: Тогда, очевидно, вы должны попытаться проявить гибкость, где бы это не стоило вам больших дополнительных усилий. Независимо от того, как вы определяете плату, представляйте ее во время выполнения с явными ссылками. Очень удобно кодировать логику движения и взаимосвязи с точки зрения обхода ссылок, которая не зависит от размера или топологии платы.

— ddyer
источник