LINUX.ORG.RU

Создание бесшовных локаций. Как это лучше делать?

 , , , ,


0

2

Для космической RTS (которую я разрабатываю) надо реализовать бесшовную локацию. То есть поверхность целого планетоида в реальном масштабе с минимальной единицей позиционирования 1 дециметр (10 сантиметров). По карте будут ходить генералы и область вокруг должна обрабатываться в реальном времени, а область без них в макро-режиме, для экономии системных ресурсов.

Подскажите, как лучше всего реализовать такую задумку. Пока мне в голову пришли только 2 идеи:

1) Отряды по карте перемещаются в макро-режиме. В месте сближения отрядов прогружается карта и открывается ограниченная локация 60*60 километров.

2) Переход в RTS режим происходит только в «городах» и «провинциях».

Но это явно не бесшовный переход.

Ещё есть идея, сделать все расчёты координат абсолютными относительно некого центра карты. Но тогда не понятно как обрабатывать координаты на сферическом планетоиде, надо для всех местных расчётов конвертировать абсолютные значения в местные. Да и матрицу поверхности для ускорения координатных расчётов тоже будет сделать труднее.

Может есть какой то более простой или изящный способ сделать бесшовный «мир» для RTS?

☆☆☆

Последнее исправление: CYB3R (всего исправлений: 1)

с минимальной единицей позиционирования 1 дециметр (10 сантиметров). По карте будут ходить генералы и область вокруг должна обрабатываться в реальном времени

генералы - размером с тараканов?

Ещё есть идея, сделать все расчёты координат абсолютными относительно некого центра карты.

декартовы или сферические? Со вторыми так-то проблем не должно быть, но расчеты имхо станут медленнее (тригонометрии больше).

Может есть какой то более простой или изящный способ сделать бесшовный «мир» для RTS?

а чем не устраивает вариант «тонкого просчета» только окрестностей «генералов»?

arkhnchul ★★
()
  • Разбей карту на достаточно большие области.
  • Каждую область детализируй: стенки, канавки, камни, (если надо то и: вода, кусты).
  • Посчитав количество и объём препятствий по типам, занеси значения в свойства области.
  • Введи понятие активной/неактивной области в зависимости от наличия в ней (или по соседству) генерала.
  • Для неактивных областей расчет движения и военных действий делай в соответствии с параметрами области в «макро-режиме».
  • Если область активируется, расставляй армию как считаешь наиболее вероятным. И движение единиц определяй уже через ИИ.
  • В случае де активации области, смотри уже сам. Либо сразу переводи всё в макро режим, либо ещё некоторое время пусть работает ИИ.
AlexVR ★★★★★
()
Ответ на: комментарий от arkhnchul

с минимальной единицей позиционирования 1 дециметр (10 сантиметров)

генералы - размером с тараканов?

Такой квант расстояния нужен будет для некоторых фич.

а чем не устраивает вариант «тонкого просчета» только окрестностей «генералов»?

Это как?

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от AlexVR

Но тогда возникает проблема, если воюющие стороны окажутся на границе двух локаций. Тогда придётся вести многие взаимодействия через метод warp и соответственно усложнить расчёты. Для дальнобойной артиллерии это ещё нормально, она всё равно бьёт по навесной траектории. Но если 2 пехотинца будут из разных локаций стрелять в друг друга, даже не знаю как это реализовать.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от arkhnchul

генералы - размером с тараканов?

Боевые тараканы-киборги-шахиды там тоже будут.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от rezedent12

Если две армии встретились на неактивных областях (одной или соседних), то результат определяется статистически (т.е. с такой-то вероятностью получили ранения столько-то, погибло столько-то). Если на активных, то ИИ всё решит.

Ты вначале начни реализовывать, а там поймёшь что и где нужно подправить

AlexVR ★★★★★
()
Ответ на: комментарий от rezedent12

Большой проблемой будет массовое побоище стразу на нескольких прилегающих областях. Тогда уже, разве что замедление времени поможет.

AlexVR ★★★★★
()
Ответ на: комментарий от rezedent12

Это как?

это как AlexVR описал в общем.

Но тогда возникает проблема, если воюющие стороны окажутся на границе двух локаций

так нету же «локаций». Есть по координатам воюющие объекты - те местности считаем по мелкой сетке.

arkhnchul ★★
()
Ответ на: комментарий от AlexVR

Ты вначале начни реализовывать, а там поймёшь что и где нужно подправить

Боюсь начать костыли городить. А потом заново переписывать.

rezedent12 ☆☆☆
() автор топика

Ух ты .. 2 джва года ждал такую игру!!11

anonymous
()
Ответ на: комментарий от rezedent12

Боюсь начать костыли городить. А потом заново переписывать.

Ты их уже начал городить и будешь городить в любом случае. Расслабься и получай удовольствие.

anonymous
()
Ответ на: комментарий от rezedent12

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

anonymous
()
Ответ на: комментарий от anonymous

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

Я делаю серверный движок, ему графику не надо считать.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от rezedent12

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

anonymous
()
Ответ на: комментарий от anonymous

Вообще подход с механикой на сервере верный

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

Я думаю это должно будет выглядеть так. Окно игрового клиента, а центре и сверху в нём окно графического движка.

rezedent12 ☆☆☆
() автор топика
Последнее исправление: rezedent12 (всего исправлений: 1)
Ответ на: комментарий от rezedent12

(: На самом деле, почти все стратегии клиент-серверные, только сервером выступает один из игроков, чтоб облегчить ему жизнь, используют уточняющую модель с предсказанием. Сразу виден минус, «пацаны я новый хак нашел, ай да нубасов нагнем» ЫЫЫ. Сервер должен быть выделенным и недоступным для игроков, все расчеты касающиеся механики вынесены на сервер. Что-то уточняющее ориентацию анимации может быть оставлено клиентам.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.