Каким образом сделать распределение ресурса в игровом мире?
Добрый день!
Для игровой механики (massive multi-player) мне нужно сделать распределение ресурса в мире игры (грубо говоря, в игровом "воздухе", без жёсткой привязки к конкретным "шахтам").
Условия распределения:
- более-менее равномерное
- возможны места повышенной или пониженной "плотности"
- возможен сбор "ресурса" с последующим постепенным восстановлением
Пока что моих знаний хватило только на реализацию самого распределения через гауссову функцию с коэффициентами и несколькими положительными пиками в местах "повышенной плотности" ресурса.
Но вопрос о "сборе" ресурсов решить не получается – добавлять отрицательный пик к функции на каждый чих кажется неразумным и медленным (учитывая, что сбор ресурса будет происходить просто при передвижении игроков по игровому миру).
Другой вариант: тупо генерировать дискретные элементы по всему миру, которые будут исчезать при "сборе". Тут среди минусов – разве что необходимость обработки огромного кол-ва этих элементов – на вскидку, будет очень ресурсоёмко с т.з. производительности.
Возможно, есть какие-то другие пути решения? (наверняка проблема не уникальная, как в игрострое, так и в математике в принципе)
Или, может быть, хотя бы подскажете, в какую сторону копать?
Для правильного вопроса надо знать половину ответа
Зоны (например квадраты или гексы), для каждой определить максимальную плотность ресурса, текущую плотность и скорость восстановления. При движении в пределах зоны перс собирает ресурс, при этом плотность ресурса в зоне (и, соответственно, скорость сбора) падает.
Хм, спасибо. Уже тоже думал о таком, но тут получается либо не очень равномерно (при больших зонах), либо, при уменьшении размера зон, всё равно очень большое кол-во.
К слову, если для квадратов есть quadtree, то есть ли что-то аналогичное для гексов?
Если не "шахматы", то "взвешенный граф". С его помощью очень легко сделать распределение ресурсов по типу "чем дальше переться, тем больше лежит". Т.е. в каждом узле графа хранятся координаты области, в которой лежит ресурс и количество ресурсов. Весь массив координат триангулируется, чтобы получить сетку, рёбра которой хранят расстояние между соединёнными узлами.
Во-первых, с её помощью легко сделать равномерное распределение ресурсов (чем узлы ближе, тем в каждом из них меньше ресурсов). Во-вторых, этот граф можно использовать для приблизительного поиска пути.
Хм, а как насчёт производительности? грубо говоря, при размерах игрового мира x (ширина) и y (длина) получится x*y узлов. И это только 2D. А если 3D? Уже, как минимум, миллиарды узлов получаются.
norlin: У вас же не "шахматное" представление мира. И ресурсы лежат не в каждой клетке. Допустим, у вас в игре будет миллион игроков. В среднем на игрока будет по 10 "мест" с ресурсами (понятно, что разные игроки могут припереться на одну и ту же территорию и друг у друга ресурсы приворовывать, поэтому и пишем, что в среднем). Получается всего лишь 10 миллионов узлов. Я специально сказал про триангуляцию узлов, чтобы не было связи каждый узел с каждым узлом, а была лишь узел - с несколькими ближайшими. Допустим, каждый узел будет связан с десятком соседних (тут всё зависит от алгоритма триангуляции, но соседей будет от двух до пары десятков максимум). Т.е. нужно хранить 10 миллионов узлов и 100 миллионов рёбер. Даже при корявой реализации вряд ли больше гигабайта займёт - считай даром.
norlin: Ааа, тогда не правильно понял. Тогда с гауссом вы неплохо придумали. Но, если ресурс восстанавливается медленно, то всё равно придётся хранить 100500 коэффициентов для каждого изменившегося участка. Т.е. какая разница, хранить значение в конкретной области или коэффициент для формулы?
Простой
Простой
