Как мы это сделали: Fright Fight — 3D-файтинг от zGames

Главным триумфатором премии DevGAMM Awards, вручение которой состоялось в рамках одноименной минской конференции разработчиков и издателей игр, стала команда zGames — подразделение компании Softeq Development. Их онлайновый кроссплатформенный многопользовательский 3D-файтинг Fright Fight признан лучшей игрой-2014, оставив позади 25 претендентов.

Команда zGames в лице менеджера проекта Николая Дзнеладзе, гейм-дизайнера Павла Штангеева и главного разработчика Артёма Воробьёва рассказала о том, как появилась идея создания игры в жанре файтингов, о сложных моментах в разработке и радости долгожданного релиза.

Как всё начиналось

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

Мы просмотрели тонны игр в App Store и заметили, что жанр файтингов представлен всего лишь несколькими портами с консолей, со всеми вытекающими недостатками в духе 12 виртуальных кнопок на экране. Именно этот момент и стал отправной точкой проекта, известного сегодня как Fright Fight — кроссплатформенный многопользовательский файтинг на Unity 3D в стилистике, напоминающей культовых Super Smash Brothers.

От идеи до прототипа

Файтинг — один из самых сложных жанров с точки зрения игрового дизайна. Дизайн файтинга для мобильных устройств сильно усложняется, так как не приходится рассчитывать на игровые контроллеры, а тачскрин банально неудобен для управления классической боевой системой файтингов. Начиная писать дизайн для Fright Fight, мы ориентировались, в первую очередь, на адаптацию управления под мобильные платформы. Это повлекло за собой ряд изменений в ключевых механиках, было создано множество прототипов управления, но результат стоил потраченных сил.

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

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

Разработка: дизайн

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

Проблему со сложной боевой системой и простым управлением мы решили в два этапа:

  • Убрали второстепенные части боевки и добавили вспомогательные автоматические механики для балансировки. Например, мы убрали из игры броски, что сделало блок доминирующей стратегией. Для балансировки мы дали возможность части медленных атак пробивать блок и ввели показатель «ярости» — она требуется для поддержания блока.
  • Повесили все атаки на единственный жест — тап в правой части экрана — и сделали их контекстными. По сути, игрок может либо тапнуть для проведения атаки (несколько быстрых тапов приведут к выполнению комбо), либо тапнуть и удерживать палец для «зарядки» более сильной атаки. Конкретная атака зависит от текущего положения персонажа (стоит, бежит, прыгает и так далее) и количества накопленной «ярости».

контролы

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

В целом эксперимент с ролевой системой удался. Мы сумели сбалансировать её практически идеально. Это потребовало построения довольно сложной математической модели и проведения ряда продолжительных плейтестов, но результат удивил даже нас — после 1 000 000 сыгранных онлайн матчей, разница в победах между персонажами колебалась в районе 1%.

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

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

Дерево скиллов Вампирши

Разработка: программирование

Самой сложной задачей для программистов было сделать сетевой мультиплеер. Когда начинался Fright Fight, мы не знали ничего о том, как играть в одном мире с разных девайсов. Мы понимали, что есть сотни способов сделать сеть плохо. Начали с изучения теории: в книге «Game Engine Architecture» (J. Gregory) было вкратце описано, как строится архитектура мультиплеерных игр, но уж слишком коротко. Из «Networking and online games» (G. Armitage) узнали об основных проблемах в сетевых играх и о том, как их можно решать. Затем стали смотреть сетевые движки, из которых нам больше всего понравился Photon — у него были хорошие отзывы и возможность попробовать бесплатно. Базовый API PhotonCloud оказался слишком базовым и использовать его напрямую было бы чересчур громоздко. Поэтому стали искать обёртки — рассмотрели три (в т.ч. PUN), нарисовали их архитектурные схемы, ужаснулись и… придумали свою.

Время на разработку было очень ограничено, поэтому мы решили не делать сервер, а обсчитывать всё на клиентах. План был простой: каждый клиент рассчитывает то, что касается него, и сообщает результат остальным. Добавить защиту от взлома, выделить клиента, который бы принимал общие решения, — и всё должно работать, так? Так, но лучше бы мы делали сервер.

Во-первых, защита от взлома отнимает время разработчиков, на сервере проверки делать проще.

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

В-третьих, синхронизировать состояние с сервером было бы быстрее — в нашем случае данные сначала шли от клиента А в PhotonCloud, потом из PhotonCloud в клиент Б, и потом то же самое от Б к А; итого, если задержка между А и PhotonCloud составляла 0.1 секунды, то общая задержка синхронизации — 0.4 секунды. Для файтинга 0.4 секунды — это очень много.

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

Можно обобщить наш опыт в следующих советах:

  • использовать обсчёт на клиентах можно, но только при медленном геймплее, для быстрого геймплея нужен сервер;
  • нужно обобщать синхронизацию данных, чтобы не пришлось синхронизировать каждую игровую механику по отдельности. Хорошую идею мы подсмотрели в Quake3, но это тема отдельной статьи :)
  • для мобильных мультиплеерных игр делать геймплей по возможности более медленным, чтобы меньше зависеть от задержек сети; либо делать асинхронный мультиплеер, как в Clash of Clans;
  • организовывать запросы к серверу в виде отдельных объектов (мы называем их джобами), которые можно создать, запустить на выполненеие, дождаться их окончания и получить из них результат — этого нам не хватало в существующих обёртках Photon.

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

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

Эволюция от GDD до релиза

Долгожданный релиз и жизнь после него

В конце 2013 мы решились представить широкой публике альфа-версию своей новинки, начав активную кампанию на известном краудфандинговом портале Kickstarter.com. Несмотря на скептический настрой многих собратьев по цеху и отечественных медийных ресурсов, а также невзирая на то, что инициатива по сбору средств на развитие игры не достигла желаемого результата, нам удалось добиться резонанса в игровом сообществе и заручиться поддержкой поклонников жанра онлайн-файтинга со всего мира. Весной 2014 год игра появилась в App Store.

Теперь наши рабочие будни проходят вот так:

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

Fright Fight доступна для свободного скачивания на Android и iOS-устройствах, а также игровой консоли OUYA.

*Редакция dev.by не несёт ответственности за содержание корпоративных блогов
Вакансии

Обсуждение

Missing-male
+2

Может я что-то не понимаю, но где здесь 3D ?

Missing

Ты что-то не понимаешь, и это непонимание можно списать разве что на мультяшность графики в игре. :)

5a3b89e573da755befe514b46a797287?1365455438

Сцена и персонажи сделаны в 3D, камера движется в одной плоскости, поэтому может казаться, что игра 2D.

Missing-male
+5

я не дизайнер и не разработчик игр, но звучит как-то странно:

- 3D сделано но так, что похоже на 2D.

Я бы еще понял:

- Сделано 2D так, что бы был эффект 3D :)

5a3b89e573da755befe514b46a797287?1365455438

Не обязательно крутить камерой, если игра 3D. Есть 3D игры, гораздо более качественные, чем Fright Fight, в которых камера движется в одной плоскости (посмотрите Trine или Starcraft 2).

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

Missing-male
+2

Если бы сейчас кто изобрел новый "StarCraft", было бы все равно 2D или 3D он, он все равно был бы в топе.

Picture?type=square
+4

139 оценок в app store/usa свидельствуют о провале...

3.5 на google play оценка тоже не признак триумфа...

1 место на dev gamm - может это за будущие успехи - авансом так сказать :)

5a3b89e573da755befe514b46a797287?1365455438
+3

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

Picture?type=square
+4

Проблема не в аудитории - а в игре - что и было высказано оценкой

Аудитория которая хотела играть в игру - скачала ее посмотрев на скриншоты/описание

и надежды не оправдались

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

Игра не интересная/не дает эндорфинов с точки зрения игроков и не более того... И это объективный факт - а не мое субъективное суждение - оценку рынок дал :)

А первое место наводит на мысль - а судьи кто? уж не сами ли разработчики...

5a3b89e573da755befe514b46a797287?1365455438
+2

Не буду спорить, нам далеко до самых топовых игр.

Missing

Пора Девбаю возвращаться к переводному контенту: и то лучше, чем откровенный пиар разных шарашкиных контор. Сначала IBA хвастается валидаторами - проектом, которые ненавидят все, кто пользуется общественным транспортом, теперь вот некий SOFTek рассказывает про мегадостижение - игру с оценкой 3,5.

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

Da2af29cb6c44fdb2c79bbc7f7fb1d0e?1401053490
+10

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

ЗЫ к данной статье последнее не относится, прочитал с интересом, хотя и не поклонник игрушек.

Missing-male
Drew
– ведущий инженер-программист в SCAND

+7

+1. Мне тож интересно почитать о наших.

Missing-male
Алексей Данченко
– Инженер-программист в ЛюксСофт

+2

>Сначала IBA хвастается валидаторами - проектом, которые ненавидят все, кто пользуется общественным транспортом

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

И как раз интересно, как этот проект реализовывался, как это работает, и какие потенциальные возможности есть у системы.

Missing
+2

Раскажите про идею из Q3 ??? (Аж всплакнул от ностальгии)

5a3b89e573da755befe514b46a797287?1365455438
+2

Ок) Кто не заинтересован в технических деталях - не читайте этот коммент.

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

Missing-female
+3

Молодцы. Реально очень сложно (могу себе представить), а результат ОЧЕНЬ достойный.

Picture?type=square

Тому кто придумал схему управления должно хватить мужества зайти за угол и упасть на меч (с)

5a3b89e573da755befe514b46a797287?1365455438
+4

Мы работаем над схемой управления))

В тему, один из первых отзывов на русском AppStore:

"Управление сделано через жопу - срабатывает даже не через раз, а хрен знает как. Тестил и на пятом айфоне и на втором айпаде. Десять раз можешь двигать пальцев в одну в сторону, но персонаж стоит. И если ооочень повезет, то на 11 раз персонаж сдвинется. Разработчикам кол в жопу!" (by "Ilisid")

Прогресс налицо, пол года упорного труда и мы получаем меч вместо кола :)


Авторизуйтесь, чтобы оставлять комментарии

© 2008-2017 Частное предприятие "Дев Бай"
Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси