Как создаются браузерные игры
Как сегодня делают игры в браузере? Часть 1
Игра в браузере на React и Three.js!
Я занимаюсь фронтендом уже очень давно, порядка 10 лет. И как любой уважающий себя фронтендер, я люблю тащить javascript туда, где обычно его не используют: на сервер, в мобильные приложения, в геймдев. С тех пор как я увидел первые WebGL демосцены в 2013-м, я мечтал сделать что-то похожее, скажем, на это.
Так что я провел немало времени экспериментируя и читая документацию, и вот что у меня получилось.
Дисклеймер: я не претендую на абсолютные знания того, как делают игры, я всего лишь описываю свой наивный подход к поиску ответа на вопрос, который задает заголовок. Поэтому это будет не совсем игра, а скорее концепт, интерактивная демо-сцена.
Дизайн
Шаг 1. Настройка проекта
Как и в любом другом JS-проекте, в первую очередь придется выполнить настройку. Я ненавижу долгие настройки, полные магических операций, поэтому буду пользоваться Parcel, так как он придерживается zero-config концепции. В качестве рендер-движка я буду использовать Three.js и react-three-fiber, который склеит React и Three.js и освободит от императивности последней.
В первую очередь, я создам папку под проект и выполню следующее:
А так же следующая строчка в разделе scripts package.json:
А еще index.html со следующим содержимым.
Теперь после выполнения команды npm start можно перейти по адресу http://localhost:1234 и приступить к делу.
Шаг 2. Базовые вещи
Позвольте мне пропустить подробности того, как сделан react-three-fiber и как он работает, в сети довольно много информации по этой теме. Например, в официальной документации.
Прежде всего, в игре должна быть земля, поверхность, чтобы все не выглядело так, словно персонажи висят в воздухе. В приведенном ниже примере я создал базовую сцену с компонентами:
Canvas. Самый главный компонент, который делает за вас много работы: запускает игровой цикл, следит за всем, является контекстом. Большинство настроек сцены будут в нем.
axesHelper. Компонент, который добавляет в сцену оси (хотя, конечно, не очень полезный, потому что ось Y направлена вверх, хотя я ожидал, что вверх будет направлена ось Z).
mesh. Поверхность. В такой компонент нужно прокинуть два потомка: описание геометрии поверхности и ее материала.
pointLight. Источник света. Без него вы не увидите ничего.
Тут должен был быть эмбед codesandbox, но что-то пошло не так: https://codesandbox.io/embed/sleepy-wu-4vt60
Шаг 3. Движение камеры
Шаг 4. Файрбол
Ок, пришло время перейти к более интересным и сложным вещам. К созданию файрбола. К сожалению, я не умею писать шейдеры, поэтому взял и адаптировал уже готовый код из подходящей демки.
Идея проста как дважды два. Всего три компонента: сфера, цилиндр для огня и еще один, большего размера, для дыма. Все компоненты имеют прозрачный shaderMaterial, который обновляется в каждом новом кадре. В итоге все выглядит, как будто он состоит из пылающей лавы.
Вот тут лежит полный код файрбола, а пока я расскажу о некоторых аспектах.
Файл /src/fireball/fireball.jsx экспортирует единственный компонент, который, в свою очередь, состоит из трех других, завернутых в группу. Почему? Потому что это позволяет применять трансформации на всех потомках, сохраняя их относительное местоположение и соотношения.
В каждом подкомпоненте есть следующие строки:
Наконец, если поместить компонент в сцену и прокинуть в него свойства position и scale, то выглядеть это будет следующим образом:
Тут должен был быть эмбед codesandbox, но что-то пошло не так: https://codesandbox.io/embed/exciting-marco-iyy6h
Шаг 5. Персонажи
Где взять модели персонажей? Отличный вопрос. К примеру, в mannequin.js или mixamo. Можно даже купить на sketchfab (и использовать mixamo для создания скелета в нем). В целях эксперимента я буду использовать mixamo, там есть подходящие модели и анимации.
При скачивании модели стоит выбрать формат FBX.
В целях отображения модели персонажа я создал два новых файла: getModel.js и NPC.jsx. Первый экспортирует хук, который ответственен за асинхронную загрузку файлов моделей и включение теней, второй использует этот хук и контролирует анимации. Все довольно просто. Кстати, анимации уже включены в состав FBX файла, но не будем же мы каждый раз из заново парсить. Проще сохранить их где-то в виде json-а и использовать на разных моделях (в этом универсальное преимущество mixamo: все модели имеют скелет с одинаково названными костями, так что можно взять описание анимации одного персонажа и сыграть на другом).
Спасибо, что дочитали до конца! В следующей части я опишу, как использовать геймпад, заставить модели двигаться и как сюда вписывается state management.
Разработка ММО РПГ – практическое руководство. Эпизод 1
В цикле статей «Разработка ММО РПГ – практическое руководство» вы получите ответы на эти и многие другие вопросы. Все цифры реальны. Все схемы, таблицы, исходный код, диаграммы БД и прочее взяты из реально существующего и успешно работающего проекта.
В тексте будет много отсылок к геймплею и внешнему виду нашей игры «Звездные Призраки». Я постараюсь излагать материал так, чтобы вам не было нужды вникать (и играть) в наш продукт, но для лучшего понимания материала желательно потратить пару минут и посмотреть, как это все выглядит.
Готовы? Тогда в путь!
Трудозатраты
Начнем мы, пожалуй, с самого интересного – со стоимости разработки. На диаграмме (см. рис.1) отображены затраты в процентном отношении к общему бюджету проекта. При расчете не учитывалась стоимость офиса, амортизация оборудования и налоги.
На аутсорс мы отдавали концепт-арт и создание 3D-моделей, причем первые единицы техники в линейке (например, турель 1-го и 20-го уровня) обязательно создавались в офисе. А вот остальное (турели 40-го, 60-го и 80-го) – и концепты, и 3D-моделинг отдавали на аутсорс. Почему так? В офисе, прежде всего, происходит поиск концепта и его отображения в 3D. И, как любая исследовательская работа, она требовала высококвалифицированных (и, следовательно, дорогих) специалистов. А когда форма найдена производство можно смело отдавать на аутсорс.
Так же на аутсорс были полностью отданы создание видеороликов, озвучка, музыкальное оформление, создание звуков и верстка сайта. Контента такого типа для нашей игры было нужно не так уж и много, поэтому не было ни какого смысла брать людей в штат. А наши попытки отдать на аутсорс часть программного кода (в виде конечных задач) успехом не увенчались, поэтому вся программная часть была полностью написана нашими силами.
Еще одна величина в диаграмме может показаться странной – всего 1% расходов на тестирование. Основной вклад в тестирование сделали сами игроки на этапах от альфы до открытого бета теста, и платили мы им в апсидиуме (премиумная игровая валюта). Поэтому удалось существенно снизить затраты в реальных деньгах.
Состав команды
В офисе на постоянной основе над проектом работали пять человек. Примерно за 2 месяца до альфы мы взяли в офис на полставки еще двух тестеров, но проработали они у нас не долго – примерно по три месяца каждый (или 1.5 человеко-месяца каждый). Уже начиная с закрытой беты мы смогли полностью переложить тестирование на удаленных тестеров: часть – за реальные деньги, часть – за игровые.
В таблице (см. табл.1) приведен состав команды, их роли и суммарные трудозатраты. Каждая строка таблицы – это один человек, который мог совмещать одновременно несколько функций. Трудозатраты указаны от начала работ (подготовка первых документов и создание демо) до релиза продукта.
Схема системы и план разработки
Формально «Звездные Призраки» — браузерная игра. Но веб-часть работает под управлением Adobe Flash и использует сокетное соединение. Поэтому, фактически, это клиент-серверная игра, только загрузка клиента происходит прозрачно для пользователя. Из каких же компонентов состоит игра? Казалось бы, все должно быть просто – из клиента и сервера. Но на самом деле (см. рис. 2) все несколько сложнее.
Мы придерживались следующего порядка разработки:
Этот порядок позволил нам на ранних стадиях разработки получить действующую систему и тестировать на ней те или иные концепции.
Ниже я приведу краткое описание каждого из компонентов, для общего понимания системы, после чего мы подробно остановимся на каждом из них.
Этап 1. В первую очередь был разработан прототип игры без всякого сервера, но в который вошли практически все предполагаемые к использованию в клиенте технологии, а именно: Adobe Flash, Adobe Away3D, Adobe Starling. У нас был космос, в котором пользователь управлял одиноким кораблем. На этом прототипе мы обкатали базовую систему расчета кривой перемещения корабля, перемещение космоса (параллакс), проверили возможности отрисовки моделей на текстуру. В общем, мы протестировали все узкие места, которые видели в начале разработки и примерно поняли, как у нас все будет выглядеть. Это позволило сделать вывод о возможности технической реализации задуманного, а так же дало демо, с которым можно было идти к инвесторам.
Этап 2. После утверждения тех.задания мы выработали тех.требования к 3D-моделям: на этом этапе у нас уже было представление о внешнем виде игры, платформе и движке. Кроме того, мы создали «пробирку» для 3Dшников – отдельный инструмент, в который можно было загрузить 3D-модель и посмотреть, как она будет выглядеть после рендера в Away3D. Дело в том, что после экспорта непосредственно в движок, модель выглядит немного не так, как в инструменте моделирования. Поэтому нашему артотделу, а особенно арт-директору, было крайне важно видеть, как все будет выглядеть на самом деле, чтобы «подтянуть текстуры», как он говорил. Тут сразу оговорюсь: в ходе работ мы перешли на новую версию Away3D, в которой шейдеры были другими, и это привело к изменению визуального отображения моделей. «Подтягивать текстуры» пришлось заново. Отсюда есть два очень важных вывода: во-первых, требуйте от текстурщиков порядка в файлах текстур, раскладки всего по слоям с человеческими названиями, чтобы через полгода другой человек мог открыть файл и найти нужный слой, а, во-вторых, все «подтягивания» графики делайте не сразу по ее готовности, а ближе к концу проекта.
Этап 4. Дальше некоторое время шла итеративная разработка клиента и сервера. Первое, что появилось – это XML конфиги оборудования, чтобы гейм-дизайнер мог тестировать параметры пушек и кораблей. Так же на этом этапе было много экспериментов, создания различных видов вооружений и поиск механизма боя.
Этап 5. Когда механика игры более-менее устоялась, можно было подключать БД к серверу. В качестве СУБД был выбран MySQL. Подключение подразумевало, прежде всего, перенос загрузки данных оборудования из XML файлов в БД, а также загрузку и сохранение состояния пользователей. Естественно, необходимо было создать админку, которая позволила бы гейм-дизайнеру создавать/редактировать предметы и локации. Админка была написана на PHP. Когда отпала необходимость редактировать XML файлы, гейм-дизайнер был очень рад, и процесс наполнения игры предметами и локациями стал продвигаться существенно быстрее.
Этап 6. По мере усложнения проекта мы столкнулись с тем, что создание руками каждого нового пакета отнимало много времени, и было сопряжено с ошибками. Поэтому, опять же, на РНР был написан скрипт, который принимает XML файл и по нему генерирует файлы исходного кода для клиента и сервера (и, в последствии, и для чат-сервера). Аналогичная проблема возникла и у гейм-дизайнера: по мере роста номенклатуры предметов управлять и модифицировать их стало крайне затруднительно. Поэтому и для него был написан ряд скриптов, которые облегчали генерацию сразу всей линейки предметов.
Этап 7. Изначально мы собирались использовать IRC чат-сервер. Казалось, что там все просто и вопрос чата был отложен. Но когда пришла очередь создавать чат, выяснилось, что интегрировать IRC-сервер с нашей системой не так уж и просто. Ведь нам нужна не просто авторизация, а еще и система модерирования, а также отображение специфических данных в чате — уровень, клан и т.п. Мы оценили, что проще написать свой чат-сервер, чем модифицировать IRC-сервер. По факту, на клиенте мы потратили меньше времени на интеграцию с нашим сервером, чем с IRC, так что это решение было верным.
Этап 8. Мы приближались к закрытому бета-тесту (ЗБТ). Стало очевидным, что потребуется сбор статистики. Доработки затронули сервер и БД, плюс отображение в админке. Работы было много, но, в основном рутина, за исключением проектирования БД.
Этап 9. После ЗБТ мы пофиксили баги и выполнили некоторые модификации, после чего стали готовиться к открытому бета-тесту (ОБТ). Конечно же, необходимо было реализовать возможность приема платежей. Такие доработки затронули клиент, сервер, БД, а так же пришлось создать специальный скрипт. Здесь, опять же, никакой особой магии – все на РНР.
Этап 10. Пришло время разобраться с поставщиками трафика. С ними мы работаем по двум схемам: фиксированная стоимость в месяц независимо от количества переходов/регистраций или оплата за регистрацию (СРА). Для работы по модели СРА необходимо было провести интеграцию с API этих поставщиков трафика. Доработки затронули клиент, сервер, БД, веб-сайт и админку (фильтры в статистике).
Этап 11. Непосредственно перед ОБТ мы создали сайт игры (во время ЗБТ игроки переходили на страницу с Flash, а регистрация и логин были реализованы во флеше). Больше всего времени заняла интеграция игры с базой форума, чтобы обеспечить сквозной логин форум/игра.
Этап 12. После ОБТ и нагрузочного тестирования мы поняли, что лить трафик на основной игровой сервер – плохая идея. Дело в том, что кол-во трафика очень сильно зависит от времени суток. И в пиковое время могло приходить до ста запросов в секунду. Игроки у нас кидались прямо в игру, для каждого нового игрока создавался отдельный инстанс. Это очень сильно нагружало игровой сервер и вызывало на нем лаги. Поэтому был создан специальный регистрационный сервер (фактически – еще один инстанс основного сервера, но запускаемый со специальным ключом, поэтому он загружает только регистрационные локации) и отдельный клиент, в котором игрок играет только до регистрации (после этого его редиректит на основной сервер). Кроме того, мы уменьшили объем загружаемых данных в регистрационном клиенте, так как точно знали, что необходимо для игрока. Это позволило уменьшить время загрузки клиента и решило проблему с лагами на основном сервере, а так же сделало систему масштабируемой – при необходимости мы может развернуть хоть сто отдельных регистрационных серверов.
Этап 13. Непосредственно перед релизом была добавлена интеграция с социальными сетями, а именно возможность авторизации через социальные сети. Это увеличило конверсии переходов в регистрации примерно на 10%.
Разработка браузерной онлайн-игры
Привет, хабровчане. Меня зовут Евгений, по профессии я backend-разработчик и пишу я на языке c# в сегменте enterprise приложений. В этой публикации я хочу рассказать вам о своём опыте в не совсем профильной для меня сфере — разработке видеоигр, а конкретнее — о разработке браузерной онлайн-игры.
Я привык относить себя к тем везучим людям, у которых хобби совпадает с работой — я люблю разработку ПО. Поэтому для меня абсолютно нормально, вернувшись домой, вновь сесть за компьютер, открыть Visual Studio и продолжить что-то разрабатывать — отдых от этой деятельности мне не нужен. Проблема лишь одна — нужен проект, который мне интересен и который я смог бы осилить один в свободное время — по вечерам и в выходные дни.
Примерно год назад мне показали довольно популярную браузерную онлайн-игру — слитерио. После ознакомления у меня появилась навязчивая идея — мне захотелось сделать что-то похожее по подходу, но с чуть более продвинутым геймплеем. Спустя пару месяцев идея сформировалась в тему этой публикации — игру World of Frogs.
Суть игры — вы управляете лягушкой, можете нападать на других игроков, а также на управляемые компьютером объекты — мух, тараканов, болотных лягушек. Мухи не умеют нападать и умирают с одного удара, тараканы нападают лишь обороняясь, болотные же лягушки нападают как на мух, так и на игроков.
Побеждая врагов вы получаете опыт, растёте по уровням, изучаете новые способности и становитесь сильнее.
Основные пункты, от которых я отталкивался:
1) Клиентский код
Мне не хотелось погрязнуть в межбраузерных различиях, а также в реализации примитивов, поэтому я сразу задвинул подальше идею работать напрямую с canvas — я начал с поиска графической библиотеки (разумеется, бесплатной).
Изначально взгляд упал на pixi.js — это движок, по которому немало документации, о котором положительно отзываются в плане производительности и вообще всячески хвалят.
Однако углубившись в поиски, я остановился на phaser.js (о нём уже были статьи на хабре) — это более высокоуровневая библиотека, которая позволила мне забыть о многих нюансах и сосредоточиться непосредственно на игровой логике.
Движок позволил без особых проблем прикрутить анимации, бэкграунд текстуру, камеру, границы мира и многое другое. И всё бы хорошо, но когда настало время проверять работу на других компьютерах, с другими операционными системами, выявились следующие проблемы:
1.1 Главная из проблем — фоновая текстура (tilesprite) жутко тормозит на windows 7
Выяснил я это с рабочего компьютера после первого деплоя на хостинг — ФПС был очень и очень низким — в районе 5. И так было во всех браузерах кроме, на удивление, IE — в нём всё работало вполне прилично, пускай и не идеально.
До того, что тормозит бэкграунд я додумался далеко не сразу — первым делом, я, методом тыка выяснил, что игра резко перестаёт тормозить при уменьшении размера окна браузера. Нагуглить по что-то по таким симптомам мне не удалось, поэтому я, профилактики ради, решил внедрить часть практик, которые советуют ребята из Mozilla — в частности, использование Object Pool (переиспользование игровых объектов). Особых успехов такого рода оптимизациями я не достиг, а профилировщик по-прежнему показывал что больше всего ресурсов съедает рендеринг.
Тогда, прибегнув к постепенному отключению отображения различных элементов игры я и выявил виновника — tilesprite.
Погуглив по tilesprite я выяснил, что такая проблема не у меня одного, и причина кроется в том, что canvas перерисовывается полностью при любом изменении — т.е. маленький объект сдвинулся — перерисоываем весь канвас, включая фон, что даёт нам высокий расход на отрисовку.
В попытке решить эту проблему я вынес фон на отдельный канвас с меньшим z-index, чтобы он перерисовывался отдельно, независимо от движущихся объектов — особых результатов это не дало.
В конечном итоге я решил отказаться от phaser.js и работать напрямую с canvas, созданным для отрисовки фона — в результате ФПС вырос примерно до 20.
1.2 Разные версии phaser — разная производительность в разных операционках
После изменения принципа отрисовки фона с производительностью всё стало намного лучше, но 20 ФПС — это всё ещё не желаемые 60 — было над чем поработать. Путём тыканья пальцем в небо было выяснено, что phaser версии 2.4.6 работает быстрее на windows 7, а версии 2.6.2 быстрее на windows 10. На линухе и маке обе версии показали себя одинаково хорошо.
Пришлось добавить условие, которое подключало ту или иную версию библиотеки в зависимости от браузера пользователя — это повысило ФПС на моей рабочей машине до 25-30. Выше поднять ФПС у меня так и не получилось — на этом я решил остановиться, т.к. после опроса друзей/знакомых, у которых стоит семёрка, сложилось впечатление, что проблема редкая, да и уже не такая серьёзная как изначально.
Описанное в этих двух пунктах — это не единственные, но основные и наиболее запомнившиеся проблемы, связанные с phaser.js — всё остальное прошло в общем-то гладко.
Также стоит отметить, что на разных машинах с windows 7 производительность была разной — кое-где и без всех моих телодвижений всё было хорошо, где-то же наблюдались проблемы аналогичные тем, что я наблюдал — какой-либо корреляции я установить не смог
2) Производительность одного инстанса игрового сервера
Здесь начать стоит с того, какая в целом архитектура у приложения, которое служит как игровой сервер. Было решено использовать следующую схему:
Параллельно от разных игроков принимаются сообщения по websocket и закладываются на обработку основному потоку, который обновляет игровую логику. Основной поток работает итерациями по 40мс, в рамках которых обновляет передвижение, видимость, респавн NPC, прогресс использования способностей и т.п.
Запись данных в базу происходит асинхронно — поток обновления игровой логики закладывает сообщения в очередь другому фоновому потоку, который их группирует и пачками пишет в базу.
Сериализация и отправка сообщений игрокам тоже происходит асинхронно — этим занимается очередной фоновый тред, которому сообщения в очередь для обработки пишутся в рамках выполнения итерации, а в конце итерации сообщения группируются для каждого пользователя и пачкой отправляются на клиент.
Если отобразить на схеме, то верхнеуровнево серверная архитектура выглядит так:
Т.к. с бэкендом у меня опыта прилично больше, здесь каких-то особо запомнившихся трудностей не было — неоптимальные места я отлавливал профилировщиком — где-то применял микрооптимизации вычислений, где-то кэширование, где-то оптимизации иного рода.
Самым серьёзным бустом к производительности был отказ от использования SignalR, т.к. он не поддерживает бинарный протокол, а на сериализацию в json уходило вычислительных ресурсов больше, чем на всю остальную логику игрового сервера вместе взятую. Остановился в итоге на использовании Fleck, т.к. он поддерживает бинарный формат, а также позволяет отключить алгоритм Нэйгла.
3) Возможность горизонтального масштабирования
Будучи оптимистом я решил заранее заложиться на то, что игра всем понравится и в неё захочет играть множество людей. В рамках одной машины можно долго заниматься оптимизациями, можно бесконечно апгрейдить железо, можно переписать приложение на чистом си с ассемблерными вставками для микрооптимизаций, но всё равно рано или поздно упрёшься в потолок. Было решено иметь архитектуру, позволяющую иметь множество серверов малой мощности, на каждом из которых потолок по онлайну в районе 200-300 человек.
Чтобы не было бутылочного горлышка в виде сети до какого-то одного глобального прокси, а также чтобы обеспечить минимальный пинг, было решено на стороне сайта выбирать из пула серверов один конкретный, с минимальным онлайном, закреплять его за сессией пользователя и в дальнейшем обеспечивать взаимодействие браузера пользователя напрямую с игровым сервером.
На текущий момент в выборе сервера из пула используются простая логика — берётся сервер с минимальным онлайном. В дальнейшем планируется также добавить логику учёта местоположения клиента и сервера.
4) Низкий порог вхождения в игру и быстрый старт
Мне не раз приходилось видеть игры, которые просто обязаны иметь наиужаснейшую конверсию из-за перегруженности интерфейса или же из-за необходимости вводить миллион полей для того, чтобы зайти в игру.
Я хотел обеспечить вход по одному клику мыши с главной страницы, т.е. никакой обязательной регистрации. В том же слитерио используется похожий подход, за одной небольшой разницей — от игрока всё же хотят, чтобы он ввёл ник.
Т.к. онлайн игра как правило предполагает возможность отличать одного игрока от другого, я решил использовать подход никогенерации — при входе в игру берётся случайное прилагательное из заранее заданного списка и комбинируется с случайным существительным, что выдаёт ники вида Неспящий Бугай, Жадный Бурундук, Могучий Валенок и т.п…
В дальнейшем, если игроку понравилась игра, ему предоставляется возможность зарегистрироваться, сохранив за собой прогресс, а также сменив ник на что-то более вменяемое.
Для более быстрого погружения на главную страницу было добавлено обучающее видео, а в саму игру были добавлены тултипы, выплывающие при изучении новых способностей.
5) Чуть более разнообразный геймплей, чем в слитерио
Как бывший поклонник игры WoW, я хотел разнообразить игру, внеся в неё такие элементы как набор опыта, рост по уровням, получение новых способностей по мере роста, PvE, PvP.
Игроку доступно к использованию 6 способностей (1-я доступна сразу, 2-4 становятся доступны по мере роста по уровням, а 5-6 оформлены как одноразовые поверапы — их можно поднять на игровом поле):
Для возможности немного выделиться была добавлена возможность выбрать другую модель игрового персонажа.
6) Красивый и запоминающийся домен;
Спасибо за внимание. Надеюсь, что кому-то мой опыт будет полезен.