На чем пишут браузерные игры

Создаем многопользовательскую браузерную игру. Часть первая. Клиент-серверная архитектура

socket

В 2014 году я впервые побывал на CodeDay в Нью-Йорке. И хотя CodeDay не совсем хакатон, это было моё первое знакомство с подобными мероприятиями. Там мы с моим другом Кеннетом Ли написали многопользовательскую игру в танчики. Так как несколько моих друзей спрашивали меня о том, как я её написал, я решил описать процесс её создания.

В этом посте я вкратце опишу ход своих рассуждений и покажу, как воссоздать архитектуру, а также дам некоторые советы, если вы захотите сделать игру сами. Этот пост рассчитан на тех, кто владеет основами JavaScript и Node.js. Если вы с ними не знакомы, то есть много замечательных онлайн-ресурсов, где можно их изучить.

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

Бэкенд игры написан на Node.js с использованием веб-сокетов, которые позволяют серверу и клиенту общаться в режиме реального времени. Со стороны клиента игра отображается в HTML5-элементе Canvas . Для начала нам, конечно же, понадобится Node.js. В этой статье описана работа с версией 6.3.1, но вы можете использовать любую версию выше 0.12.

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

Создание проекта

Для начала установите зависимости. Создайте папку проекта, перейдите в неё и запустите следующий код:

Для быстрой настройки сервера целесообразно использовать фреймворк Express, а для обработки веб-сокетов на сервере — пакет socket.io. В файл server.js поместите следующий код:

Это довольно типичный код для сервера на связке Node.js + Express. Он устанавливает зависимости и основные маршруты сервера. Для этого демонстрационного приложения используется только один файл index.html и папка static . Создайте их в корневой папке проекта. Файл index.html довольно простой:

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

Теперь нужно настроить веб-сокеты на сервере. В конец файла server.js добавьте:

Пока что в игре нет никаких функций, поэтому в обработчик веб-сокетов ничего добавлять не нужно. Для тестирования допишите следующие строки в конец файла server.js :

Эта функция будет отправлять сообщение с именем message и содержимым hi всем подключенным веб-сокетам. Позже не забудьте удалить эту часть кода, так как она предназначена только для тестирования.

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

Запустите сервер командой node server.js и в любом браузере перейдите по ссылке http://localhost:5000. Если вы откроете окно разработчика (нажать правую кнопку мыши → Проверить (Inspect)), то увидите, как каждую секунду приходит новое сообщение:

Как правило, socket.emit(name, data) отправляет сообщение с заданным именем и данными серверу, если запрос идет от клиента, и наоборот, если запрос идет от сервера. Для получения сообщений по конкретному имени используется следующая команда:

С помощью socket.emit() вы можете отправить любое сообщение. Можно также передавать объекты JSON, что для нас очень удобно. Это позволяет мгновенно передавать информацию в игре от сервера к клиенту и обратно, что является основой многопользовательской игры.

Теперь пусть клиент отправляет некоторые состояния клавиатуры. Поместите следующий код в конец файла static/game.js :

Это стандартный код, который позволяет отслеживать нажатие клавиш W , A , S , D . После этого добавьте сообщение, которое оповестит сервер о том, что в игре появился новый участник, и создайте цикл, который будет сообщать серверу о нажатии клавиш.

Эта часть кода позволит отправлять на сервер информацию о состоянии клавиатуры клиента 60 раз в секунду. Теперь необходимо прописать эту ситуацию со стороны сервера. В конец файла server.js добавьте следующие строки:

Давайте разберёмся с этим кодом. Вы будете хранить информацию о всех подключенных пользователях в виде объектов JSON. Так как у каждого подключённого к серверу сокета есть уникальный id, клавиша будет представлять собой id сокета подключённого игрока. Значение же будет другим объектом JSON, содержащим координаты x и y .

Когда сервер получит сообщение о том, что присоединился новый игрок, он добавит новый вход в объект игроков при помощи id сокета, который будет в этом сообщении. Когда сервер получит сообщение о движении, то обновит информацию об игроке, который связан с этим сокетом, если он существует.

io.sockets.emit() — это запрос, который будет отправлять сообщение и данные ВСЕМ подключённым сокетам. Сервер будет отправлять это состояние всем подключённым клиентам 60 раз в секунду.

На данном этапе клиент ещё ничего не делает с этой информацией, поэтому добавьте со стороны клиента обработчик, который будет отображать данные от сервера в Canvas .

Этот код обращается к id Canvas ( #canvas ) и рисует там. Каждый раз, когда от сервера будет поступать сообщение о состоянии, данные в Canvas будут обнуляться, и на нём в виде зеленых кружков будут заново отображаться все игроки.

Теперь каждый новый игрок сможет видеть состояние всех подключенных игроков на Canvas . Запустите сервер командой node server.js и откройте в браузере два окна. При переходе по ссылке http://localhost:5000 вы должны будете увидеть нечто похожее:

Вот и всё! Если у вас возникли проблемы, посмотрите архив с исходным кодом.

Некоторые тонкости

Когда будете разрабатывать более функциональную игру, целесообразно разделить код на несколько файлов.

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

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

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

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

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

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

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

Кроме того, старайтесь избегать такого кода:

В этом отрезке кода обновление координаты х для игрока связано с частотой смены кадров в игре. SetInterval() не всегда гарантирует соблюдение интервала, вместо этого напишите нечто подобное:

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

Также можно сделать так, чтобы из игры удалялись отключенные игроки. Когда сокет отключается, автоматически отправляется сообщение о разъединении. Это можно прописать так:

Также попытайтесь создать собственный физический движок. Это сложно, но весело. Если захотите попробовать, то рекомендую прочитать книгу «The Nature of Code», в которой есть много полезных идей.

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

Игровые движки для браузеров: как создать свою игру

Игровой контент – одно из самых распространенных направлений в программировании. Разработчики и программеры стараются создавать развлекательный софт не только клиентского типа, но и браузерного. Для реализации поставленной задачи человеку потребуются определенные навыки, умения и знания. Тогда даже начинающий сможет справиться с self made контентом.

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

Движок – определение

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

При помощи соответствующих компонентов удается получить:

3D и 2D-графику;
скриптинг;
звук;
кат-сцены;
рендеринг;
сетевые коды;
реализацию физического движка;
внедрить искусственный интеллект.

Это – настоящий подарок для тех, кто планирует заниматься разработкой self made контента. Говоря простыми словами, рассматриваемый платформер – это база для игр.

О языках

Игровые объекты и другие составляющие как клиентской, так и браузерной self игрушки лучше внедряются через движки. Они бывают готовыми («чужими») и собственными. Первый вариант применяется в большинстве случаев. Лишь изредка крупные разработчики софта пишут для тех или иных проектов собственные движки (пример – REEngine от Capcom).

В основе платформеров лежит программирование на различных языках. Браузерные self games пишутся преимущественно на:

JavaScript;
PHP;
Python.

Это – основные языки разработки веб-контента. Отдельное все они схожи между собой, но имеют собственные нюансы и особенности. Можно обучиться как одной «лексике» для успешной разработки self контента, так и нескольким. Второй вариант больше подойдет тем, кто планирует активное программирование «с нуля».

Лучшие платформеры

Игрушки, сделанные при помощи готовых платформеров-движков – это практически совершенный контент. Но многое зависит от того, какую именно «базу» выберет программер.

Вот несколько самых популярных на сегодняшний день вариантов:

CryEngine;
Unity 3D;
Unreal Engine 4;
GameMaker Studio 2;
Cocos;
Corona (он же Solar2D);
Godot;
libGDX.

Лучший контент для создания игр выбрать трудно. Но на практике в ходу софт и приложения, сделанные при помощи Unity 3D и Unreal Engine.

Что лучше для браузера

Self Made Games браузерного типа – это преимущественно 2D-софт. Для его воспроизведения используем разнообразные проигрыватели (пример – Flash Player) и расширения.

Браузерные утилиты должны быть:

«легкими» по объему, иначе возможна долгая загрузка;
с тщательно проработанной графикой;
обладающими высокой частотой кадров;
удобными;
быстрыми.

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

Python – определение

Приложения, написанные на Питоне – это быстрые и удобные, практически совершенные self утилиты. Браузерный софт основывается на скриптах. Python состоит из соответствующих «составляющих».

Это – стремительно развивающийся скриптовый язык. Применяется при решении разноплановых задач и достижения целей. На нем пишут self утилиты для:

мобильных платформ;
компьютеров;
приставок.

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

Софт, написанный на Питоне, считают кроссплатформенным. Его легко перенести из одной операционной системы в другую. Разрабы часто используют соответствующую «лексику» для создания браузерных игрушек.

PyGame – это

Тем, кто хочет заниматься созданием игр на Python, рекомендуется обратить внимание на такой объект, как PyGame. Без него self made контент будет трудно сделать.

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

классы;
методы;
функции;
циклы.

Pygame – это некая библиотека, используется при создании self «мейд» софта 2D-типа. Сборник необходимых для реализации поставленной задачи инструментов.

Pygame – своеобразная оболочка мультимедийной библиотеке SDL. Используется для обработки опросов событий, вставки изображений в окна, а также «прикручивания» звуков и других важных для игрового процесса составляющих.

Pygame впервые появился в 2000 году, в ноябре. Обладает отличным комьюнити, а также сопутствующей документацией и всевозможными справками. Некоторые программеры называют Pygame фреймворком. Это не совсем правильно, но иногда такое «приравнивание» уместно. А еще Pygame часто считают игровым движком. При классификации соответствующего объекта можно сделать вывод: для ПО это – API Python к API библиотеке SDL.

База для игр

Важная часть 2D-игры – это простой скелет. Основная масса браузерного софта представлена в виде основного цикла. Кодификация будет выполняться множество раз в процессе реализации контента.

При создании self made games на Pygame важно уметь «прикреплять» различные объекты, при помощи которых человек сможет играть в браузере и наслаждаться процессом. Это не так трудно даже начинающим программерам.

Основы PyGame

Для того, чтобы написать собственную утилиту на рассматриваемом «движке», важно понимать, с чем предстоит работать. Для начала рекомендуется изучить следующий элементарный пример утилиты, написанной в Python. С ней будет осуществляться дальнейшая работа.

Теперь важно подключить библиотеку. Проводится соответствующее действие командой import pygame. Далее предстоит выполнить следующие манипуляции:

Вызвать функцию init() для подготовки модулей «движка» к функционированию – pygame.init().
Создать графическое окно – screen = pygame.display.set_mode ((1200, 800)).
Запустить основной цикл утилиты. Здесь будет перехватываться закрытие основное графокна юзером.

Как только желаемое событие наступает, предстоит завершить работу с библиотекой (def update pygame) посредством pygame.quit(). Далее требуется вызвать exit() из модуля sys.

Создание геометрии

В утилите можно размещать разнообразные фигуры. Пример – прямоугольник. В Питоне и Pygame при создании Self Game используется тип Rect.

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

В библиотеке функции отображения фигур геометрического типа расположены в модуле draw. Рисуется рассматриваемый объект через rect().

Требуется передать в функции в виде аргументов поверхность, на которой размещается прямоугольник. Дополнительно прописываются:

цвет;
сама фигура;
толщина линий.

Вот пример приложения:

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

Прочие операции для рисования фигур

При создании Self игрушек в Pygame могут использоваться различные операции и функции. Их основа – геометрические фигуры:

Pygame.draw.line (surface, color, start_pos, end_pos, width=1). Происходит рисование линии на поверхности заданного цвета. Начало – в точке «старт», конец – в «энд». Толщина линии – width.
Pygame.draw.lines (Surface, color, closed, pointlist, width=1). Рисуется линия, которая соединяет последовательности «поинлист» на заданной поверхности установленным цветом. Каждая точка – это пара координат. Здесь xlosed равен True, а конец соединяется с начальной.
Pygame.draw.circle (Surface, color, pos, radius, width=0). Рисовка окружности с центром в точке «пос» и заданным радиусом. Если width = 0, происходит закрашивание круга.
Pygame.draw.ellipse (Surface, color, Rect, width=0). Создание в Pygame эллипс, ограниченный прямоугольником Rect. При нулевом параметре width происходит закрашивание фигуры.
Pygame.draw.polygon (Surface, color, pointlist, width=0). Изображение многоугольника из последовательностей «поинтлист». Каждая точка – это пара координат. Если последний элемент = 0, фигура закрашивается полностью.

Пока этого будет достаточно для практики. Цветовые гаммы представляются моделью RGB. Цвет задается тройкой чисел от 0 до 255. Чем меньше значение числа, тем темнее получится в итоге оттенок.

Также есть модуль color, который содержит словарь thecolors. Там ключи – это цветовые гаммы. Подключение производится командой from pygame.color import thecolors.

Основной экран можно закрасить через метод fill().

Шрифт и текст

Если пользователь делает игру или иной контент, ему не обойтись без текста и шрифтов. Последние представлены Font. Для создания соответствующего типа используется функция SysFont (имя, размер, bold=False, italic=False).

задается имя шрифта – первый элемент после скобок;
размер в ПТ – «размер»;
bold и italic – на начертание.

Чтобы посмотреть все шрифты, имеющиеся в базе, стоит воспользоваться операцией get_fonts():

Теперь через метод render() можно вывести картинку с текстом, которая передается методу vlit() для отображения на основном экране:

В предложенном примере текст будет размещаться на главном дисплее по координатам (50, 50).

Как стать гейм-разработчиком

Для того, чтобы стать разработчиком или программером, который создает self made games для браузеров на Python или PHP, предстоит выбрать тот или иной путь развития. После того, как юзер определился, на каком языке работать, ему необходимо получить определенные знания.

Существуют следующие варианты развития событий:

Поступление в ВУЗ для получения высшего образования. Сегодня университеты набирают как гейм-создателей, так и обычных программистов. Срок обучения в среднем составляет 5 лет. В процессе человека научат основам программирования на различных языках. По выпуску выдается диплом государственного образца.
Самообразование. Наиболее долгое решение, но для многих оно является верным. Юзеру предстоит самостоятельно изучать основы программирования на выбранном языке. В интернете полно соответствующей литературы. Никаких сертификатов человек не получит, зато сможет сконцентрироваться только на важных для себя сферах. . Относительно новое решение для тех, кто не готов поступать в ВУЗ. В Москве и других регионах образовательные центры предлагают курсы как по программированию на языках, так и по созданию игр. В конце выдается специальный сертификат.

Последний вариант встречается на практике чаще остальных. Он часто сочетается с самообразованием. Данный вариант помогает довольно быстро охватить программирование на Питоне и создание собственных игрушек.

На самом деле разработка браузерных игр через Python и PHP – это не так трудно. С элементарными задачами сможет справиться даже новичок. А по ссылке можно отыскать полезные уроки по созданию собственной игрушки на Питоне. Также вам может быть интересен профессиональный курс Otus по Python-разработке:

Особенности разработки игры для браузера

Для образовательного проекта Банка России мы сделали яркую веб-игру «Тайна потерянной копилки». Она привлекает внимание школьников к теме финансовой грамотности, знакомит с терминами, учит разумно распоряжаться деньгами. Игра понравилась не только детям, но и взрослым из разных городов России — в неё сыграли более 30 000 человек.

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

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

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

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

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

Игровой движок Phaser — мы уже реализовывали на нём игру для Эльдорадо/Майкрософт.
Unity с возможностью экспорта игры в Web — мы делали игровые проекты на этом движке.
Также рассматривали малоизвестные нам движки LibGDX, Godot, PlayCanvas.

Неизвестные варианты отвалились по вполне очевидной причине — их надо было осваивать и изучать, что, некоторым образом, пугало, хоть и не казалось невозможным. Вариант с Unity отвалился потому, что ограничения движка и экспорта не позволяли, например, использовать аудио в IE 11. А ещё потому, что экспортируемый из Unity код Javascript получался очень большой, а IE 11 значительно более медленный в парсинге и исполнении кода, чем современные браузеры.

Таким образом, было решено взять свежую версию движка Phaser (на момент начала разработки это была версия Phaser 3.11). Выбрали этот движок ещё и потому, что вся логика и отрисовка — программные, а значит, мы могли контролировать в коде абсолютно любой аспект будущей игры.

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

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

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

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

Стек разработки был взят довольно типичный для подобного проекта — webpack, webpack-dev-server, babel, babel/preset-typescript.

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

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

Было опробовано несколько теоретических и практических гипотез, из которых родилось финальное решение. Решение состоит в следующем:

На экране загрузки игры, где идёт прогресс от 0 до 100 %, фактическая загрузка ресурсов заканчивается на 92 %.
После этого за пределами экрана создаётся сцена, на которую помещаются тяжёлые анимации и немного физики.
Далее в течение 5 секунд измеряется среднее время отрисовки одного кадра.
После этого принимается решение о производительности устройства и прогресс доходит до 100 %.

Очень важным было требование полной работоспособности игры в IE 11, что тоже доставляло неудобства. Оказалось, что при запущенных инструментах разработчика, и без того небыстрое выполнение Javascript в этом браузере ещё замедлялось.

То есть ты сталкиваешься с тормозами в игре, открываешь инструменты разработчика, чтобы найти причину, а игра тормозит ещё больше.

Игровые механики сами по себе несложные, во многом вдохновлённые существующими играми.

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

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

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

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

Все остальные механики собственно тем же и являются — срабатывание приближения и пересечения персонажа и игровых объектов в определенные моменты времени и анимации.

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

Определитесь с жанром на самом раннем этапе.

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

Совет — относитесь к разработке веб-игры как к реальной игре, а не как к очередному «скрипту на странице». Тестируйте, профилируйте, не допускайте утечек памяти и повышенной нагрузки на процессор. Игроки и батареи их устройств будут довольны.