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

Для более быстрого ознакомления с проектом можно просто посмотреть данное видео (снято на чуть более ранней версии, чем есть сейчас):

А в статье ниже приведён более подробный разбор различных нюансов разработки.

От клеточек к радиусам

Так как мне с 90-х нравится боёвка в стиле Final Fantasy Tactics - во многих выходящих тактических играх смотрю какие-то дополнительные фишки или альтернативные решения в плане игромеханик. И одно время был интерес поиграть в пару частей Mario + Rabbits, потому что там вроде реализовали то, что мне хотелось в качестве альтернативных решений для игры в тактику - управление движением героя в реалтайме, но ограниченное определённым радиусом.

Тактика с клеточками (картинка из проекта игрового стола - "Монстробой: Тактика")

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

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

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

Есть ещё семейство игр с активной паузой, и они мне чаще всего тоже не слишком нравятся, за счёт излишней хаотичности происходящего. То есть, это всё-таки слишком уход в реалтайм, персонажи в большинстве случаев справятся и без твоего вмешательства, плюс разбегаются кто куда на своё усмотрение и у тебя не так много контроля за происходящим - просто отдать команды и точечно чинить мисспозиции. Нет это тоже может быть реализовано удачно - например, Final Fantasy 12 играется чудесно. Но там просто исчезает некое ощущение тактичности, плюс большую часть времени группа просто красиво колотит врагов автоатаками в реалтайме. Конкретно FF12 тебя завлекает скорее качеством исполнения и общей комплексностью механик/прокачки, поэтому и боёвка с активной паузой в этой игре мне начинает нравится, в отличие от пачки западных ролёвок с активной паузой, которые я традиционно не перевариваю (исключая разве что первый Planescape, но он просто был интересен и оригинален сам по себе).

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

Радиусная тактика

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

А в итоге первое демо выглядело так:

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

Каждый ход движение текущего героя ограничено окружностью определённого радиуса. Герой может переместиться в этих пределах и, когда делает действие, то двигаться в этом ходу уже не может. Если до движения герой что-то делает, то потом может перейти куда-то уже не совершая действий.

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

Для действий в радиусе мы СНАЧАЛА отмечаем цель, а затем приближаясь/удаляясь смотрим на то, какие наши скиллы подсвечиваются (когда цель в пределах радиуса этого скилла). Далее нажимаем на скилл и он применяется в цель, если та на нужном расстоянии. Это всё позволяет не тратить время на перебор каждого конкретного скилла и выяснение, дотянется ли он до желаемой цели с текущего места.

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

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

Ход одного из персонажей (над ним белый светильник). Выбран один из врагов (отмечен красной сферой). Внизу видно, что третий скилл (с радиусом 10) подсвечен - то есть герой дотягивается им до врага, но не первыми двумя скиллами (с радиусами 2 и 5).

Как показали тесты - всё более менее работает и вроде можно обойтись без использования навмешей. Очень нужных для отображения радиуса декалей в Godot 3 по дефолту нет, но можно реализовать вручную через шейдера, чем я и воспользовался.

Эффекты по области теоретически могут быть доступны и в режиме радиусов тоже, просто тогда зональный скилл применится на карту именно в том месте, где стоит отмеченный враг (или не враг).

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

Другой класс проблем - это предусмотреть триггеры, вроде контратак, шаги в начале или конце хода, всякие события на конец/начало хода (тики отравления, например). Сложности всему этому добавляет то, что когда хочешь "сделать красиво", то персонаж СНАЧАЛА должен изобразить действие, и уже ПОСЛЕ должно случиться последствие действия и рисуется нанесение дамага.

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

Попадания и промахи

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

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

В тактических боёвках часто используются вероятности срабатывания чего либо, а также вариации "бросков на попадание". Получить промах при атаке - психологически это уже лучше воспринимается, чем отмена в MTG. Результат хотя бы происходит, просто он не поменял ситуацию и таким образом потратил время/ресурсы. Нехорошо, но этому нехорошо дали произойти до конца, гештальт закрылся.

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

Естественно, совсем убирать промахи из системы я не стал, но игрок может подобрать оружие, которое вобще не промахивается, успешное попадание еще не означает что будет нанесён урон (может защиты снизят его до 0), а способностей, которые срабатывают с шансом, не стал делать слишком много. К тому же способности с шансом срабатывания - это не то же самое, что промазать обычной атакой. Игрок обычно видит шансы приёма и соглашается/не соглашается получить какой-то редкий эффект, принимая возможность провала. А от стандартной атаки он не ждёт, что та попадает с шансом, пусть даже игра шанс этот прописывает - это простой инструмент, часто с не таким великим уроном, и он должен работать просто. Вот с этим ожиданием я и работал - например, делая низкоуровневые жезлы и посохи мажущими в половине случаев (ведь маг должен понимать, что забить кого-то посохом - идея вряд ли удачная и не для того он записывался в маги), или добавляя возможность промаха в топоры (но и подкрутив им урон при хорошем попадании). А вот мечи и кортики, даже первоуровневые, попадают в любом случае, за тем исключением что у кортиков поначалу есть шанс нанести нулевой урон при попадании, но они попадают при этом (и к этому 0 урона может добавиться бонусный урон или какие-то наносимые атакой статусы/эффекты).

Некоторое оружие из настольно-ролевой тактической игры "Монстробой"

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

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

AI врагов

В радиусной тактике я захотел делать не очередную адаптацию урезанной системы из настолки, а всё-таки попробовать концепцию смены профессии и комбинации способностей классов, на манер того что было в FFT (консольная Final Fantasy Tactics). Ну и ещё какие-то вещи, которые больше зайдут под компьютерную реализацию или попроще в менеджменте/управлении. Допустим, вместо экшен-поинтов просто 1 движение и 1 действие на ход. Настольная тактика тоже не останется в стороне - оттуда есть что позаимствовать, например, концепцию оружия с 4 позициями атаки (что уже реализовано - герои и монстры при нормальной атаке словно "бросают" четырёхгранный кубик со своими определёнными исходами) и то, что нулевой урон всё-таки тянет за собой прочие возможные бонусы к повреждениям и шанс наложить эффекты.

В интеллекте монстров я решил использовать нечто в стиле гамбитов из FF12. Собственно, уже в FFT разработчики явно использовали нечто подобное, в FF12 просто эту систему причесали и вынесли в часть основного геймплея. Суть в следующем - у с��щества есть некий последовательный набор директив, которые записаны как "цель-действие" или скорее "цель и условия - действие". Когда существо свободно и нужно что-то сделать - оно перебирает эти директивы (от первой к последней) и выполняет то, для чего есть подходящая цель и условия.

Окно настройка гамбитов из Final Fantasy 12, где разработчики вынесли часть игровой логики, превратив её в игромеханику (часто нечто подобное происходит и в прочих играх). Первая директива: если у союзника меньше 30 % здоровья - лечить его.

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

Например, как это работает сейчас - получая ход скелет пытается с места применить стартовый гамбит (атаку), если она получилась, то происходит пост-передвижение и там есть директива с условием (здоровье скелета меньше 50%). Если условие срабатывает, то скелет идёт к цели с малым количеством хитпоинтов. Если нет, то директива пропускается и скелет идёт к ближайшей цели. Если же стартовый гамбит не случился (атака сразу с места невозможна), то скелет бежит к ближайшей цели и во время этого могут сработать финальные гамбиты - атака (если цель оказалась близко), затем бросок головы (у этой директивы есть условие - здоровье скелета должно быть менее 25/%; дальность этой атаки выше, но сам скелет при этом умирает).

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

Демо и геймплей

В итоге появилась демо-версия, которая потом получила ещё несколько обновлений и доступна в вёб-варианте, а также виде скачиваемых билдов для linux/windows здесь:

Radius TactiX

thenonsense.itch.io

Видеонарезка с демонстрацией того, как это всё в итоге выглядит:

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

В начальном меню одна кнопка показывает ростер персонажей, где можно выбрать героев в партию - 4 слота внизу. Другая кнопка меняет режим - ростер остаётся перед глазами, но теперь при клике на героя откроется экран экипировки.

У каждого оружия свои параметры атаки - 4 возможных исхода, записываемые, например. вот так: 2/3/3/8. У различных заклинаний базовый урон чаще фиксирован, а у способностей может быть привязан к параметрам атаки текущего оружия.

Меню экипировки, совмещённое с выбором одной из 4-х профессии. Сейчас герой переквалифицирован в Рыцари и если нажать кнопку LEARN - откроется интерфейс изучения способностей данного класса.

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

Например, если персонаж находится в классе Странника (по умолчанию все герои этого класса), то он увидит доску способностей этой профессии, где можно выучить 8 способностей, потратив указанное на способности количество очков. Это несколько бустов количества здоровья, владение Посохом и Луком, бонус к силе, скорости и разуму. На все способности, правда, очков не хватит - их сейчас у всех героев по 30 в каждом классе и это число не увеличивается.

Доска классовых способностей Странника. Выделена способность "Владение Луком" - открытие которой стоит 5 Class Points.

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

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

Еще на стартовом экране можно выбрать сражение. Пара карт с разными наборами противников. У врагов немного разные скорость/атака/здоровье, а также особенности поведения. "Тела" персонажей остаются на поле боя и пока что получают урон тоже.

Моделей локаций пока используется две - это вторая карта, у которой пока нет своей текстуры

В сражении герой может перемещаться как в реальном времени, но ограничен зоной радиуса своего передвижения. Кнопки "radius", "aoe" и "personal" показывают доступные в каждом из этих режимов действия. Действия в радиусе возможны когда цель находится ближе чем указанное число. Для выбора кого-то в качестве цели нужно кликнуть на врагах или прочих союзниках. Помимо атаки оружием герою доступны заклинания и способности - например огненный трюк (дальность 5, 7 огненного урона) и снежок (дальность 10, 5 физического урона). Вместо базового урона способностей в подсказках выводится уже модифицированный, но об этом позже.

Для доступного действия AoE (эффект по области) указан диапазон дальности от героя, в котором его можно совершить. На карте появляется маркер, который можно двигать, если кликнуть в тот момент когда число дальности горит желтым, действие будет сделано. Все цели вблизи маркера будут поражены (если возможно). Например, одно из AoE заклинаний наносит 9 физического урона по области на расстоянии от 3 до 9.

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

Режимы (персональный/радиус/эффекты по области) переключаются специальным слайдером:

Слайдер переключения режимов. Слева - включен режим радиусов, справа - режим эффектов по области (AoE)

Параметры и вера

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

Вера. С ней возникли некоторые сложности. Я хотел её сделать на манер того как было в Final Fantasy Tactics - персонажи с низкой верой получают меньше урона от магии, но и их магия наносит мало урона. В то же время у героев с высокой верой всё наоборот - они наносят много урона магией, но и сами огребают от неё сильнее.

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

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

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

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

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

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

Для этого пришлось всё плотно переписать и перенастроить, но в целом я реализовал веру полноценно и магия/атаки теперь пишут не свой исходный урон, а уже модифицированный статами персонажа.

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

Однако, даже так повреждения становятся куда более прогнозируемыми. Особенно от атак, которые вера не меняет и весь буст от силы мы видим сразу. Что касается магии - я дополнительно подправил её показываемый ожидаемый урон просто домножая его кроме собственной веры героя поделённой на сто, ещё на 1/2 (то есть на гипотетическую цель со средним параметром веры 50, а 50/100 - это и есть 1/2).

Особенности реализации игромеханик

Изначально враги и герои двигались по очереди, но затем я реализовал принцип получения хода на основе скорости - у каждого персонажа есть некое значение быстродействия и когда кто-либо получает ход, то все прочие участники сражения получают плюс к своей инициативе равный своему быстродействию. У того, кто получает ход - вся накопленная инициатива сбрасывается в 0. При нажатии на кнопку конец хода - право ходить получит персонаж с наивысшей инициативой на данный момент. Кликая по участникам сражения можно увидеть параметр Init - это и есть текущая накопленная каждым из них инициатива.

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

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

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

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

Конкретные герои и виды оружия имеют свои словари с параметрами. При этом у героя есть массив с данными по его экипировке, то есть параметры оружия не хранятся на самом герое, а мы получим их по соответствующему номеру экипировки.

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

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

Если же у нас предметы сложные, но сами по себе предустановленные/фиксированные - то тут как раз и пригодится практика более плотной работы с указателями на их дату.

Дополнительный плюс - в дату можно заранее отправить разные штуки, которые неохота каждый раз дополнительно выяснять проверками в процессе. Например, если у нас игра переведена на несколько языков, то в дату того же предмета мы забиваем вместо какого-нибудь Name : Меч, массив наименований - Name : [Меч, Sword, ...] И теперь когда нам требуется показать имя этого предмета, то мы выводим в интерфейсе не Name, а Name [chosen_language], где переменная chosen language будет содержать номер установленного в настройках языка, когда мы к этому Name обратимся. То есть, если русский язык начальный, то Name[0] даст "Меч", а если мы переключим его на первый, английский, то Name[1] даст Sword и так далее.

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

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

Переработанный вид (принципы которого и сохранились в дальнейшем), где всё работает проще и интуитивнее - сверху кликаем на слот экипиров��и и открывается лист именно этой категории. Затем кликаем по любому варианту и его картинка появляется в слоте - экипировано. — Переработанный вид (принципы которого и сохранились в дальнейшем), где всё работает проще и интуитивнее - сверху кликаем на слот экипировки и открывается лист именно этой категории. Затем кликаем по любому варианту и его картинка появляется в слоте - экипировано.

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

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

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

Radius TactiX, тактика на Godot