Итак, 4 типа игроков по стилю игры.

1. Киллеры (Killers)
- Цель: доминировать над другими игроками.
- Фокус: PvP, сражения, конкуренция.
- Пример: игроки, охотящиеся на других ради высоких мест в таблице лидеров.

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

2. Достиженцы (Achievers)
- Цель: добиться успехов и достижений.
- Фокус: сбор трофеев, выполнение заданий.
- Пример: те, кто пытается заработать все ачивки или достичь максимального уровня.

Это наши крафтеры + сюда же я отношу и PvEшников. Честно говоря не до конца понимаю мотивацию таких игроков в многопользовательской игре, ведь полно оффлайн игр, но факт остается фактом - таких ребят очень много, они задерживаются надолго и ими нельзя пренебрегать. Кроме того они не зависят от кол-ва игроков в онлайне, что будет очень полезно на старте.

3. Исследователи (Explorers)
- Цель: изучать мир игры.
- Фокус: секреты, лор, механики.
- Пример: игроки, находящие скрытые области или узнающие историю мира.

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

4. Социальщики (Socializers)
- Цель: общение с другими игроками.
- Фокус: взаимодействие, кооперация.
- Пример: те, кто проводит больше времени в чате или помогает другим.

Таких в Genesyx точно было полно, ведь треть игрового окна занимает именно чат. Эти ребята тоже очень полезны, потому что именно из-за них часто разгорались конфликты, приводящие в т.ч. и к клановым войнам. Да и много кто неоднократно говорил, что прикипел к проекту именно потому, что там уже до боли знакомые "лица" в чате, с которыми было перетерто много тем. В том, что таких игроков надо привлекать сомнений нет, но вот насколько часто вы пользуетесь чатом в игре именно на мобильных платформах?

Итого, план следующий:

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

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

3. Третьим этапом запущу PvP. PvE за пределами первого боя станет не обязательным для прохождения и PvP будет доступным прямо с 0 уровня игрока, как в веб-версии. Врядли кто-то в реальности будет прямо с 0 уровня идти в PvP бои, но считаю необходимым дать эту опцию ярым поклонникам такого стиля игры, чтобы не было необходимости качаться на ботах. При высоком онлайне и постоянном потоке новых игроков это будет оправданным, а при просадках у игрока всегда остается вариант качаться в режиме PvE, чтобы быстрее достичь уровня, на котором уже идут интересные PvP-бои.

Таким образом в игре будет две параллельных ветки развития. Хочешь - бей ботов, не хочешь - бей игроков. Разумеется опыта за игроков нужно будет насыпать больше, потому что этот путь заведомо сложнее. Участие в PvP на первом этапе сделаю сугубо добровольным, т.е. никаких нападений и принуждений, PvP бой состоится только если два или более PvPшника найдут друг друга. В этом будет помогать чат, добавлю автоматическую отправку уведомлений о PvP боях. Что делать когда приток игроков будет в моменте небольшим и заявки не будут собираться - пока не знаю, если у вас есть опыт/идеи - дайте знать.

Еще один момент, который мне не дает покоя - это два орудия в руках.

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

Между тем на этом моменте уже построена механика боя и экономика, отказаться от него - значит переделывать все.

Для обхода проблемы подумываю заменить левую и правую руки, а также одноручное и двуручное оружие очками действия, т.е. вместо атаки правой рукой и атаки левой рукой будет следующее:
- На ход игроку дано 4 очка действия.
- Атака каждым оружием будет тратить либо 2 очка (то, что сейчас одноручное), либо 4 (двуручное).
- Блокировка одной части тела будет расходовать 1 очко действия.
- У персонажа будет два слота под оружие: основное и дополнительное. Если двуручное, т.е. тратит все 4 очка действия - второй слот закрыт.
- При атаке автоматически сначала используется основное, потом дополнительное. Поскольку порядок атак в механике не важен - не буду забивать этим голову игроку. В простом режиме это и не важно, а в продвинутом дам выбор отдельной части тела под основное и дополнительное оружие.

Таким образом оставляем всю текущую механику и экономику, но делаем визуал более логичным. С т.з. анимаций это все еще будет выглядеть условно, но уже не так странно:
- Худший (и, наверное, самый частый) случай - у игрока разношерстное оружие, например топор и автомат, и топор выбран основным. В этом случае стойка на поле боя у него для топора и держать он его будет обеими руками. При атаке срабатывает анимация атаки топором, игрок возвращается в стойку, после этого у него меняется стойка под автомат, в руках появляется автомат, идет выстрел из автомата и снова переходим в стойку с топором.
- Средний вариант - два орудия одного класса, но разные. Например два разных автомата. В таком случае стойка и анимация не меняются, меняется только оружие в руках. Оружие, в принципе, тоже можно не менять и всегда показывать основное, но действие применять ко второму орудию.
- Лучший вариант - два одинаковых оружия. В этом случае никаких переходов между стойками. Отыгрываем либо два раза одинаковую атаку, либо даже показываем комбо. С некоторыми комбинациями, например два пистолета, можно реально их показывать в разных руках и сделать особенно прикольные анимации.

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

У кого какие идеи на этот счет? Может видели интересное решение в других играх с пошаговой системой боя?

Чтобы что-то сломалось в проекте с игрой на 3д-движке, достаточно его не открывать в течение 3х недель...

Обновил UE до 5.1.1 - проблема с пропавшими текстурами ушла. К сожалению рендеринг на мобилках не исправлен, по прежнему мигают... Добавил пропуск интро к моменту начала драки, уже не могу смотреть одно и то же по кругу после любого изменения...

В копилку низкоуровневости UE...

Начал работать над полем боя и столкнулся с проблемой, которой быть не должно (и в Unity не было), но на ее решение ушло два дня. Поле состоит из гексов, для этого у меня есть простейший меш в виде гекса, несколько текстур для отображения различных состояний (неактивная клетка, подсвеченная и т.п.) и скрипт, который генерит нужную сетку в зависимости от размера поля боя. Казалось бы куда проще...

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

Дальше начались танцы с бубнами. Применяю текстуру - рендерит вот такой треш. Открыл в Blender'е - все ок, переэкспортил - проблема сохраняется.

Десятки запросов к ChatGPT не дают ответа... он постоянно говорит, что проблема в UV-координатах, но здесь все слишком просто, чтобы дело было в этом, плюс и в Blender, и в Unity все просто работает сразу без всяких танцев с бубном.

Чтобы исключить вопросы с UV, кинул материал на обычный куб - тоже фигня. Пишу ИИ, что проблема явно с импортом текстур, но он продолжает стоять на своем.

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

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

Unity, и Blender этот вопрос решают автоматически, но не UE.
Надеюсь кому-то этот пост сэкономит пару дней.

Ребят, если вы присоединились недавно и вам не понятны какие-то технические термины в моих постах - просто читайте блог сначала, там все разобрано и история пока не настолько большая, чтобы сложно было осилить.

Ракурс для боя думаю сделать примерно таким.

Кажется я знаю как игроделы придумывают монстров. Достаточно что-то неправильно сделать со скелетом модели...

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

Излишнюю горбатость еще, может быть, можно было бы стерпеть, но плавающие ноги...

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

Ретаргетинг в Mixamo из стандартного в UE скелета Manny работает лучше. Но есть нюанс...

Наткнулся на первое ограничение блюпринтов по сравнению с кодом - не поддерживаются двумерные массивы.

Мне нужно сгенеренную боевую сетку выставить наружу для того, чтобы дальше на ней позиционировать бойцов в блюпринтах сцен. Самый очевидный метод - создать двумерный массив, чтобы по координатам типа hex[0,2] можно было получить нужную клетку и дальше с ней работать. Но сделать это в блюпринтах оказалось невозможным.

Традиционно ChatGPT об этом не сказал, настойчиво придумывал сказки о том, как это можно нарулить через интерфейс. Причем он постоянно дает инструкции к UE4, в котором интерфейс IDE сильно отличался, и часто проблема решается уточнением типа "а теперь дай инструкцию к UE5". В этот раз такая директива только усугубила ситуацию - "Конечно, ты прав!" сказал ChatGPT и придумал еще какую-то инструкцию, которая тоже крайне далека от реальности, и на проверку которой я снова потратил время.

В общем пришлось гуглить и там ответ нашелся сразу - это невозможно. На C++ переключаться ради такой ерунды не хотелось, поэтому в голову сразу пришли 3 альтернативы:

1. Использовать одномерный массив, а индекс вычислять из двух координат. Например X*100+Y. Таким образом всегда получаем уникальное число и его можно использовать как индекс в одномерном массиве. Очевидная проблема такого подхода - фрагментация массива и лишнее отжирание памяти, ведь если для карты 8x4 в двумерном массиве нужно будет создать 32 элемента, то при таком подходе - 8*100+4=804, а заняты будут только 32. Лишний расход памяти.

2. Не использовать массив вообще, вместо этого проименовать добавляемые гексы как 0x0, 0x1,... 7x3, потом искать элементы по имени. Очевидный минус такого подхода - сам поиск. Ведь получение элемента массива - это O(1), а поиск по имени - O(n). Получаем лишнюю нагрузку на CPU.

3. Создать кастомную структуру, единственный элемент которой - одномерный массив, потом создать массив этих кастомных структур и его заполнять. С т.з. производительности это наилучший вариант. С т.з. использования - не очень, потому что если в коде это выглядело бы просто как hexagons[0].arrayItem[2], то в блюпринте получаем целую портянку. Ну да ладно, просто запихну это в отдельный удобный метод.

В комментариях к посту коллега справедливо заметил, что опция #1 вполне рабочая если для множителя вместо константы (в моем примере 100) использовать максимальную длину массива (в моем случае размер поля по горизонтали). Более того в C двумерные массивы - всего лишь синтаксический сахар, а под капотом лежит одномерный массив, индексы которого так и рассчитываются. Т.е. опция #1 - это фактически и есть реализация двумерного массива в языках, и если об этом подумать - максимально логичная реализация. Век живи - век учись...

И еще один момент по кастомным структурам - это реально структуры, а не классы. Т.е. хранятся в куче и передаются по значению, а не по ссылке. Да, наверное они не просто так называются структурами, но мы уже сталкивались с кейсом Material и Material Instance где терминология не отражает фактического поведения, поэтому этот момент важно уточнить. Причем при использовании кастомных структур возникают странности (от моего незнания движка конечно же) - если создать инстанс структуры, сохранить в переменную, добавить ее (переменную) в массив, а потом что-то изменить в этой переменной - изменение происходит не в том инстансе, который был добавлен в массив, даже не смотря на то, что все манипуляции происходят внутри одного блюпринта. Видимо он где-то под капотом неявно передает переменную как параметр, в результате чего она копируется. Записали, запомнили.

Убираем трупы с поля боя через динамический material instance, смешивающий основную текстуру персонажа со стандартной текстурой шума и применение маски непрозрачности (opacity mask).