«Куда посадить игрока» на бесконечной карте— минизарисовка из продакшна геймдева⁠⁠

Пока все обсуждают, как глушат мобильную связь и GPS, моя голова занята навигацией, но совсем другой... Хотя при том не менее интересной. Сегодня хотел бы поделиться, как игра адаптирует свою карту с увеличением числа игроков. Конечно, можно было бы предусмотреть разбивку на "сервера", "комнаты". Но изначально хотелось общую единую карту.

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

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

1. Стартовый «квадрат»

• Координаты карты бесконечны (можно уйти в –12 000, 10 348 — не вопрос).

• Первый игрок рождается в центре (0;0).

• Далее берём квадрат N × N вокруг нуля, куда и бросаем новичков случайно.

• N растёт: каждые 500 новых аккаунтов мы увеличиваем половину стороны ещё на 100 тайлов.

  • 1–500 игроков → диапазон ±50

  • 501–1000 → ±150

  • дальше по формуле: spawn_radius = 50 + ⌈players/500⌉ * 100

Так мы поддерживаем плотность: пока людей мало — все рядом, позже прямиком в пустыню не улетают, но столпотворения тоже нет.

Да, скажете вы - при таком алгоритме у нас всегда попадает что-то центральное в эту зону чаще, и максимальная плотность будет около центральных координат. С одной стороны, вы будете правы - с другой, после спавна игроки расползаются :)) как тараканы.

Вот как выглядела эволюция карты при увеличении числа игроков:

2. Баланс ресурсов
Карта пустая без кристаллов скучна, но «засыпать» её нельзя. Поэтому:

кристаллы_за_час = base_rate * online_players

• base_rate ≈ 0,04 (подбирали эмпирически).

• Респавн равномерный, но со случайным смещением, чтобы рядом не появлялись две одинаковые жилы подряд.

• Если онлайн падает — генерация тоже замедляется: сервер не забит «мертвыми» ресурсами.

3. Диагональное движение
Поначалу был только крест: N/S/E/W. Пара тестеров застряли в симпатичном, но безысходном каньоне (координаты ‑23; ‑17). Добавили шаги NE, NW, SE, SW.
Результат:

• плотность «тупиковых жалоб» упала < 0,1%

• средняя длина пути до первой жилы сократилась примерно на треть (игроки теперь режут угол).

Вывод: растущий квадрат + пропорциональный респавн + диагонали держат карту живой и игрока — в движении, а сервер — без лишних процедур расчистки.

Тестовый чат-ботик в Telegram: https://t.me/terry_game_bot?start=4

С большим вниманием изучу комментарии, идеи и предложения. Конструктивная критика тоже приветствуется. После обкатки в боте всех механик будем переносить в приложение все наработки. Заранее спасибо всем, кто предложит ценные дополнения, идеи и алгоритмы!