Игроконцепты

Наработки по некоторым проектам в движках Godot и PlayCanvas: мини-jrpg, радиусная тактика и... квест?

Одно время была мысль подобрать какой-то из проектов, что хорошо подходил бы мобильной платформе и сделать что-то мобильное. Так я начал делать прототип Disengage - игра, в которой планировалось прохождение лабиринта, продвигаясь по предлагаемым карточкам, которые иногда приносят предметы, иногда новых членов партии, а иногда сражения в виде пошаговой боёвки из классических jrpg. Получилась вёб версия и apk файл с мини-демкой, сделанные на Godot.

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

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

Тем не менее, у такого способа есть свои нюансы. Во-первых, тут (в PlayCanvas) намного меньше готовых инструментов по сравнению с Godot, то есть разработка всякой элементарщины может сильно затянуться или должна упрощаться. Затем привязка к онлайну и фоновая загрузка проекта, чтобы в него сыграть. Код - на java script, конечно, писать немного тяжелее чем на gdscript или c# из за вот этого "this.", слежения за большим количеством нюансов и более сложного процесса отлова ошибок, но плюс минус нормально.

Для экономии веса я тут использую вертексную покраску моделей, обходясь без текстур. Или можно обходится одной ультра-текстурой, например (вернее одним материалом). То есть технология продумана, но пока не решил, стоит ли браться на PlayCanvas за проект такой сложности. Или всё-таки прибегать к нему для проектов попроще или вобще 2д.

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

Главным образом проблема скорее в самом мобильном девайсе. Я не особо люблю играть в игры на этом устройстве, даже где нужно лишь размеренно нажимать кнопки. В него устаешь смотреть, его не слишком хочешь поворачивать горизонтально. А если переосмыслить интерфейс под вертикальность, то в браузере на пк это начнёт смотреться слишком узко. Вобщем, не знаю. Может быть имеет смысл просто переделать проект Disengage с нуля, разрабатывая чисто под ПК, так как под мобилки большой проект делать некомфортно.

И далее переходим уже к одному из прототипов для ПК:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В старых играх, особенно в квестах, и всяких полу-квестовых штук - от страшилок до некоторых jrpg - часто использовали технологию пререндеренных (или "пренарисованных") бэкграундов.

В Godot несложно выводить двухмерный задник позади 3д-объектов и я попробовал пособирать нечто такое в качестве теста:

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

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

#gamedesign #gamedev #godot #tactics #jrpg #fantasy #разработкаигр #3d #игромеханики #прототип #тактика #long #playcanvas #webgl #turnbased