Первое видео непосредственно геймплея

Добавлен , опубликован
Наконец-то я могу продемонстрировать не какие-то наработки, а непосредственно игровой процесс. Вместо тысячи слов - видосик.
А теперь можно и тысячу слов.

В общем, с последнего обновления произошли следующие нововведения и изменения:
  • Генератор теперь можно строить только на кристаллах (такие желтенькие круглые штуки).
  • Сделана система спавна, настроить которую можно прямо в редакторе UDK (количество волн, виды врагов в волнах, количество каждого типа врагов, и т.д.; если есть несколько точек спавна, некоторые из них могут быть неактивными во время той или иной волны).
  • Пробные враги, которые по красивой траектории двигаются к цели. В этой демке они довольно слабые, потому что основной их целью было тестирование моего псевдо-пасфайндинга.
  • Введено здание, которое нужно защищать. В данном видео имеет 5 жизней. После разрушения останавливает игру. В будущем это будет сопровождаться окошком "Вы проиграли" с предложением вернуться к выбору уровней или переиграть.
  • Дорожка. Тут она почему-то получилась в виде вопросительного знака. Довольно легко делается в редакторе. Также на ней нельзя строить башни, но это реализовано другой фишкой.

Теперь немножко о сложностях. Тут их было две.
Первая - пасфайндинг, сиречь поиск пути. Изначально было решено оградить дорогу для врагов с помощью блокираторов пути, а на самом пути поставить несколько точек для стандартного в UE3 поиска пути. Однако тут все зафейлилось еще на старте. Для поиска пути я использовал наработку из предыдущего концепта (стрелялки), которая состояла в следующем: проверяем, есть ли преграды на пути к цели, если нет - идем прямо, если есть - ищем путь путевыми точками. Однако, как оказалось, проверка на преграды игнорирует блокираторы пути. В итоге, мобы думают, что могут пройтись напрямик, и, ясное дело, натыкаются на блокираторы пути, при чем начинают забавно прыгать.
В общем, решилось с помощью такой чудесной вещи, как сплайн актор. Между этими акторами идет красивая кривая линия, которую можно настраивать. Используя всего несколько функций, я прописал местному ИИ приказ двигаться по этой линии. В итоге, враги без всякого геморроя с блокираторами пути идут по проложенному маршруту, не отвлекаясь ни на что.
Вторая - блокирование постройки зданий на дорожке. Изначально я думал решить эту проблему методом, очень напоминающим предыдущий - сплайн лофт акторами. Сплайн лофт акторы являются измененной версией сплайн акторов, их основная цель - не красивая траектория, а изменение модели. Сделав правильную модельку, можно с помощью этих акторов превратить ее в подобие ленты любой формы. Очень полезно при создании американских горок. В общем, я понадеялся, что с изменением модели, эти акторы соответственным образом поменяют геометрию коллизии этой модели. Но надеялся я зря - у модели, полученной в результате, коллизии нет вообще. Тем не менее, дорожку я оставил - красиво смотрится.
Проблему я решил с помощью создания собственного "вольюма" (объема, если по-русски). Это такая геометрия уровня, которая не видна в игре, и определенным образом влияет на то, что находится в ней (или с ней соприкасается; те же блокираторы пути кстати). В общем, довольно простой класс. Но довольно много времени заняло создание непосредственно самой геометрии на уровне. Этот объем пришлось довольно сильно отредактировать, чтобы он более-менее соответствовал форме дорожки. Ну и главный недостаток - как и вся геометрия уровня, этот объем при более-менее сложной форме довольно сильно жрет ресурсы системы. ФПС после создания полной версии объема для дорожки просел едва ли не вдвое.

Вот такие пироги.
Работы дальше довольно много - доработать систему спавна, дополнить интерфейс всеми недостающими элементами, внести запланированные коррективы в функционал существующих башен, и начать работать над новыми (если кому интересно, могу просто создать небольшой ресурс с планами на будущее).
На этом я вас покидаю. Поздно уже.
Для отчетности - в новости 540 слов, не считая этой строки. Набрать тысячу было сложновато((
`
ОЖИДАНИЕ РЕКЛАМЫ...
0
26
11 лет назад
0
Хеля, пофикси наконец-то этот глюк в ленте.
А еще верни автоматические подсказки при вводе тэгов.
И еще у меня глючит вставка картинок в краткое описание((
0
29
11 лет назад
0
Годно. Быстро ты реализовал. Но почему-то мне кажется, что балансить все это дело будет жутко сложно.
Проверка пересечения с дорожкой конечно не очень красиво сделана. Нельзя просто по сплайну генерировать коллизию? Я бы просто брал на определенных точках сплайна нормаль и отрицательную нормаль, умножал ее на ширину дорожки и так получал бы точки для создания формы коллизии.
Чтобы взять нормаль в точке сплайна, нужно взять от функции сплайна производную, значение производной в нужной точке - тангенс угла наклона нормали, насколько я помню.
0
26
11 лет назад
Отредактирован lentinant
0
Doc, нормаль точки сплайна можно просто получить из функции в классе сплайна. А вот насчет генерации коллизии... Оооочень сомневаюсь, что подобное возможно в UDK (именно сам факт динамического создания коллизии). Был бы доступ к исходникам - тогда еще может быть. Но средства UDK предполагают строго предварительное создание коллизии.
Насчет баланса - уже понемногу думаю над этим. Уровни же не пустыми будут, там будет куча декораций. В дорожках попытаюсь минимализировать наличие прямых участков. Еще будут широкие дорожки, где сжульничать не особо просто будет.

Кроме того, есть еще мысли насчет особенных монстров. Например, только что пришла в голову мысль, элитный тип монстров, которые, получив урон определенное количество раз, на довольно длительное время становятся неуязвимыми, поэтому их выгодней будет единоразово атаковать мощным лучом, чем подставить под кучу мелких лучей. Или похожая идея - монстр, который после определенного количества "ударов" становится крайне устойчивым к этому типу луча, но более уязвимым к другому типу лазера. Также дополнительные спавнеры, которые будут внезапно появляться по бокам дорожки (аки черви Нодус), если в промежутке поблизости умерло слишком много врагов. В общем, еще придумаю. Я пока апгрейдю интерфейс.
1
29
11 лет назад
1
А понятно, т.е. ограничения движка.
Было бы круто увидеть например отражающих монстров (с определенной стороны или определенные лучи).
Или лучи разного цвета из разных кристаллов и разная восприимчивость монстров к разным лучам.
0
26
11 лет назад
0
Было бы круто увидеть например отражающих монстров (с определенной стороны или определенные лучи).
Тоже отличная мысль, монстры с броней в виде колеса, и открытыми боками.
Doc:
Или лучи разного цвета из разных кристаллов и разная восприимчивость монстров к разным лучам.
Это было в начальных задумках (на главной это упоминается), только разноцветность лучей будет обеспечиваться специальными преобразовывающими башнями, и башни будут отличаться не только цветом, но и воздействием на цель: стандартный красный лазер - без эффектов, но с максимальным уроном, радиоактивный зеленый - заражает врага радиацией (сиречь ДоТ-эффект), синий теплопоглощающий - замедляет врага. Была еще мысль сделать фиолетовый лазер, с рентгеновским действием - единственный лазер, который будет проходить сквозь врагов; урон, наносимый им, будет делиться между врагами, то есть, чем меньше врагов он задевает, тем больше урона им наносит. Но, во первых, это потребует существенной переработки кода в связке "башня-луч", а во вторых, очень плохо состыкуется с идеей "смешивания" лучей - одного из двух вариантов реакции Сумматора на несколько разноцветных лучей на входе.
0
30
11 лет назад
0
Можно некоторые лазеры делать не постоянные, а мерцающие. А на счет рентгена можно сделать его мерцающим и в виде цепной молнии в варе
0
26
11 лет назад
Отредактирован lentinant
0
Tiodor, а что если не мерцающие, а импульсные? Заряжается, и потом на краткий момент времени выстреливает мощный луч. Можно добавить две настройки - какое время он должен заряжаться, и на какой мощности выходной луч должен выходить (мощность накапливается заданное время, после чего выходит в виде луча заданной мощности, и заряд заканчивается с соответственной скоростью, например, если сделать мощный луч, но на малое время зарядки, то импульсы будут очень короткими, зато если поставить очень большое время зарядки, то луч на выходе можно сделать нереально мощным). Ну и лимиты - максимум накопленной мощности, рассеивание неиспользованной мощности со временем и т.д.. А вот насчет цепной молнии - не знаю.

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

Бессонница - страшная штука
Немного наработок для интерфейса.
0
9
11 лет назад
0
А что будет, если луч, вышедший из объединителя, направит на сам объединитель? Его не зациклит?
0
26
11 лет назад
Отредактирован lentinant
0
Variecs, нет, он его проигнорит. Я вносил коррективы в код каждый раз, когда УДК зацикливался до краша.
0
14
11 лет назад
0
lentinant, по поводу импульсных лучей и подобных им штук, можно ввести специальные событийные лучи которые будут различным образом влиять на башни (отражатели могут вращаться если на них направлен этот луч, импульсные башни будут разряжаться при отсутствии луча)
0
26
11 лет назад
0
ZregerZ, не совсем понял, что ты имеешь ввиду, но, я так понял, это еще больше усложнит игру.
0
21
11 лет назад
0
После прочтения списка проблем и метода их решения, мне отчего-то показалось, что UDK не был приспособлен для создания подобных игр.
0
26
11 лет назад
0
ehnaton, любой нормальный движок приспособлен к созданию любых игр. Тут играют роль два фактора - то, что в UDK нет доступа к исходному коду, и то, что это, как никак, мой первый проект.
0
21
11 лет назад
0
lentinant, я просто подумал как бы я тоже самое делал бы на юнити.
0
26
11 лет назад
0
ehnaton, я, конечно, могу искать минимальное расстояние от позиции "заготовки" постройки до сплайна, и запрещать постройку, если расстояние слишком маленькое, но это ведь тоже расчет неслабый.
0
21
11 лет назад
Отредактирован ehnaton
0
lentinant,
с UDK не знаком но спрошу
Почему нельзя было составить зоны нестроительства из простых плоских фигур, и кидать под заготовку через основной ландшафт луч, проверяя зоны не для строительства?
0
29
11 лет назад
0
Вторая - блокирование постройки зданий на дорожке.
использовать 2д сетку постройки зданий как в варе? Не?
0
9
11 лет назад
0
Уже обсуждалось, почему сетку использовать нельзя
0
27
11 лет назад
0
А почему нельзя просто использовать мелкую сетку? К в старкрафте, к примеру. Этого вполне достаточно для манёвров с лазером.
0
26
11 лет назад
0
Почему нельзя было составить зоны нестроительства из простых плоских фигур, и кидать под заготовку через основной ландшафт луч, проверяя зоны не для строительства?
И проверять это каждый раз когда заготовка двигается? У меня просто две функции - запретить постройку, когда заготовка входит в объем, и разрешить, когда она выходит оттуда. А расстановка простых фигур (стандартного набора которых в UDK нет, надо свои моделить) займет не меньше времени, чем редактирование объема (при этом, объем не оставляет промежутков).
LongbowMan, и как это поможет мне с постройкой на дорожке? Клетки, на которых нельзя строить, все равно как-то задать нужно.
Сетки не будет, это окончательное решение. Не понимаю, как она мне поможет, а искусственно создавать себе ограничения я не хочу.
0
21
11 лет назад
0
lentinant, в юнити это куда проще тогда)
0
27
11 лет назад
0
lentinant, без понятия, я вообще не разбираюсь в той проге, которую ты юзаешь) Просто предложил, как вариант.
0
11
11 лет назад
0
Круто, на чём пишешь?
0
26
11 лет назад
0
Blizzru, Unreal Development Kit. Это, вообще, на главной проекта можно узнать.
0
26
11 лет назад
Отредактирован lentinant
0
Да, кстати, для баланса можно банально усилять врагов.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.