На каких языках программирования пишут игры
Новички часто спрашивают, на каком языке программирования можно создать игру. Поставим точку в этом вопросе.
Ориентироваться лучше на то, что хотите реализовать и на какой платформе:
Если создаёте игру впервые, воспользуйтесь каким-нибудь движком:
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
В чём отличие языков для создания игр
У каждого языка свои преимущества и назначение, поэтому не стоит думать, что какой-то лучше остальных — все они для решения разных задач. Многие, например, пишут большую часть проекта на одном, а высоконагруженную — на другом.
Чтобы выбрать, какой язык подойдёт вам, давайте разберемся в нескольких моментах. А для совсем новичков мы предлагаем курс «Профессия Разработчик игр на Unreal Engine 4».
Браузерные игры
Они хоть и не такие крутые, как игры для консолей и компьютеров, но тоже затягивают. Причина в умелой работе гейм-дизайнеров — они продумывают механики так, чтобы вы тратили на игру больше времени и денег.
Если вы играли хотя бы в одну крупную браузерную игру, то знаете: игровой процесс дозируют, чтобы игроку не наскучило. А чтобы продолжить игру, приходите на следующий день либо платите.
Тут уже можно подключить JavaScript — он позволяет хранить в переменных данные персонажа, а графику обрабатывать с помощью Canvas. Если прикрутить PHP, получится создать базу данных, построить защиту и реализовать многопользовательский режим. А это уже полноценная браузерная игра.
Многие из таких игр создаются на Flash, который работает на языке ActionScript. Мы не рекомендуем изучать эту технологию, потому что скоро её поддержка будет прекращена, а на HTML5 появится ещё больше возможностей, чтобы полностью её заменить.
Примеры браузерных приложений
Игры для мобильных устройств
Мобильные игры превосходят браузерные, но не сильно. Маленький экран и небольшая мощность не позволяют создавать крутую графику. И ещё нельзя реализовать такое же удобное управление, как на компьютерах и приставках.
Это компенсируется простотой разработки. Можно скачать популярный движок и за несколько недель выпустить готовое приложение — это программы, которые предоставляют готовые решения для работы с графикой и физикой. Разработчику остается только добавить спрайты или модели, а потом прописать несколько скриптов на одном из предложенных языков. Можно даже не заморачиваться из-за всех ресурсов — они скачиваются или покупаются в интернете.
Unity, один из самых популярных движков, даёт возможность писать на C# и JavaScript. Подключаете скачанные файлы, пишете несколько команд — и простенькая игра готова.
Примеры мобильных игр
Компьютерные и консольные игры
Тут настоящий размах. Реалистичная графика, VR, большой игровой мир, поддержка огромного количества игроков онлайн и так далее. Можно создавать проекты вроде Limbo или Super Meat Boy в одиночку, а можно в команде разрабатывать новый Fortnite.
Но и сложность возрастает. Чем масштабнее вы мыслите, тем больше работы предстоит проделать. Вот неполный список аспектов разработки, над которыми следует потрудиться:
В таких играх ведется работа над освещением, тенями, частицами, разрушаемостью — всем, что важно для конкретного проекта. Один человек не потянет всё это за год или даже два, поэтому такое под силу только крупным студиям. Конечно, многое решается в движках, но работа всё равно колоссальная.
Без движков тоже можно обойтись: World of WarCraft был написан на C++, а MineCraft создан одним человеком на Java, после чего игру купила компания Microsoft за 2,5 миллиарда долларов.
Даже Super Mario написали на ассемблере, когда о движках никто и не задумывался.
Игровые движки для браузеров: как создать свою игру
Игровой контент – одно из самых распространенных направлений в программировании. Разработчики и программеры стараются создавать развлекательный софт не только клиентского типа, но и браузерного. Для реализации поставленной задачи человеку потребуются определенные навыки, умения и знания. Тогда даже начинающий сможет справиться с self made контентом.
В данной статье будет рассказано о том, что необходимо знать, а также какой платформер лучше для создания собственной браузерной игрушки. Информация будет полезна как новичкам, так и тем, кто уже имеет общее представление о программировании.
Движок – определение
Self контент игрового характера создается посредством специальных сред программирования. Обычно для этого используется игровой движок. Так называют пакет программ и утилит, которые необходимы для создания различных видеоигр и интерактивных приложений.
При помощи соответствующих компонентов удается получить:
Это – настоящий подарок для тех, кто планирует заниматься разработкой self made контента. Говоря простыми словами, рассматриваемый платформер – это база для игр.
О языках
Игровые объекты и другие составляющие как клиентской, так и браузерной self игрушки лучше внедряются через движки. Они бывают готовыми («чужими») и собственными. Первый вариант применяется в большинстве случаев. Лишь изредка крупные разработчики софта пишут для тех или иных проектов собственные движки (пример – REEngine от Capcom).
В основе платформеров лежит программирование на различных языках. Браузерные self games пишутся преимущественно на:
Это – основные языки разработки веб-контента. Отдельное все они схожи между собой, но имеют собственные нюансы и особенности. Можно обучиться как одной «лексике» для успешной разработки self контента, так и нескольким. Второй вариант больше подойдет тем, кто планирует активное программирование «с нуля».
Лучшие платформеры
Игрушки, сделанные при помощи готовых платформеров-движков – это практически совершенный контент. Но многое зависит от того, какую именно «базу» выберет программер.
Вот несколько самых популярных на сегодняшний день вариантов:
Лучший контент для создания игр выбрать трудно. Но на практике в ходу софт и приложения, сделанные при помощи 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. Далее предстоит выполнить следующие манипуляции:
Как только желаемое событие наступает, предстоит завершить работу с библиотекой (def update pygame) посредством pygame.quit(). Далее требуется вызвать exit() из модуля sys.
Создание геометрии
В утилите можно размещать разнообразные фигуры. Пример – прямоугольник. В Питоне и Pygame при создании Self Game используется тип Rect.
Чтобы создать объект, требуется прописать координаты левого верхнего угла прямоугольника, а также длину его сторон.
В библиотеке функции отображения фигур геометрического типа расположены в модуле draw. Рисуется рассматриваемый объект через rect().
Требуется передать в функции в виде аргументов поверхность, на которой размещается прямоугольник. Дополнительно прописываются:
Вот пример приложения:
Стоит обратить внимание на последнюю строчку game. Если требуется разместить графические составляющие на главном экране, сначала они переходят в спецбуфер. Оттуда отображение корректировок вызываются посредством flip().
Прочие операции для рисования фигур
При создании Self игрушек в Pygame могут использоваться различные операции и функции. Их основа – геометрические фигуры:
Пока этого будет достаточно для практики. Цветовые гаммы представляются моделью RGB. Цвет задается тройкой чисел от 0 до 255. Чем меньше значение числа, тем темнее получится в итоге оттенок.
Также есть модуль color, который содержит словарь thecolors. Там ключи – это цветовые гаммы. Подключение производится командой from pygame.color import thecolors.
Основной экран можно закрасить через метод fill().
Шрифт и текст
Если пользователь делает игру или иной контент, ему не обойтись без текста и шрифтов. Последние представлены Font. Для создания соответствующего типа используется функция SysFont (имя, размер, bold=False, italic=False).
Чтобы посмотреть все шрифты, имеющиеся в базе, стоит воспользоваться операцией get_fonts():
Теперь через метод render() можно вывести картинку с текстом, которая передается методу vlit() для отображения на основном экране:
В предложенном примере текст будет размещаться на главном дисплее по координатам (50, 50).
Как стать гейм-разработчиком
Для того, чтобы стать разработчиком или программером, который создает self made games для браузеров на Python или PHP, предстоит выбрать тот или иной путь развития. После того, как юзер определился, на каком языке работать, ему необходимо получить определенные знания.
Существуют следующие варианты развития событий:
Последний вариант встречается на практике чаще остальных. Он часто сочетается с самообразованием. Данный вариант помогает довольно быстро охватить программирование на Питоне и создание собственных игрушек.
На самом деле разработка браузерных игр через Python и PHP – это не так трудно. С элементарными задачами сможет справиться даже новичок. А по ссылке можно отыскать полезные уроки по созданию собственной игрушки на Питоне. Также вам может быть интересен профессиональный курс Otus по Python-разработке:
Разработка браузерной онлайн-игры
Привет, хабровчане. Меня зовут Евгений, по профессии я 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) Красивый и запоминающийся домен;
Спасибо за внимание. Надеюсь, что кому-то мой опыт будет полезен.
Особенности разработки игры для браузера
Для образовательного проекта Банка России мы сделали яркую веб-игру «Тайна потерянной копилки». Она привлекает внимание школьников к теме финансовой грамотности, знакомит с терминами, учит разумно распоряжаться деньгами. Игра понравилась не только детям, но и взрослым из разных городов России — в неё сыграли более 30 000 человек.
Мы долго просили нашего техлида рассказать о том, как происходила разработка веб-игры. Он не только рассказал, но и написал огненную статью о нашем опыте в этом проекте, о возникших сложностях, а также поделился лайфхаками в разработке браузерных игр. Получился насыщенный полезностью материал. Читайте.
Веб-игра принципиально отличается и от обычной компьютерной игры и от обычного сайта в браузере. Обычной игре все игровые ресурсы доступны оффлайн, игровому движку известны сведения о процессоре, памяти и видеокарте компьютера. Обычному сайту требуется немного ресурсов компьютера, а в случае неполадок, можно просто перезагрузить страницу.
Предположения об особенностях браузерной игры у нас были — значительные ограничения на доступный и используемый размер оперативной памяти (в ТЗ, например, зафиксировано, что для мобильных устройств должно хватать 1 Гб оперативной памяти), баланс между качеством игровых ресурсов (изображения, текстуры, спрайты, звуки, видео) и скоростью их скачивания.
К этому добавились требования от клиента — игра должна запускаться и работать во всех заявленных мобильных и десктопных браузерах (включая IE 11), на минимально возможных аппаратных характеристиках. Требования эти исходили из того, что игру предполагалось показывать при любой удобной возможности, на любом попавшемся под руку устройстве — например, в школе.
У нас уже был опыт игровой разработки, поэтому направления выбора движка обозначили сразу:
Неизвестные варианты отвалились по вполне очевидной причине — их надо было осваивать и изучать, что, некоторым образом, пугало, хоть и не казалось невозможным. Вариант с Unity отвалился потому, что ограничения движка и экспорта не позволяли, например, использовать аудио в IE 11. А ещё потому, что экспортируемый из Unity код Javascript получался очень большой, а IE 11 значительно более медленный в парсинге и исполнении кода, чем современные браузеры.
Таким образом, было решено взять свежую версию движка Phaser (на момент начала разработки это была версия Phaser 3.11). Выбрали этот движок ещё и потому, что вся логика и отрисовка — программные, а значит, мы могли контролировать в коде абсолютно любой аспект будущей игры.
В начале у нас не было проработанных механик, но было известно, что это точно будет платформер. Поэтому мы решили собрать хоть какой-то прототип, чтобы освежить свои знания по движку, а также сделать приблизительные замеры по потребляемым ресурсам и нагрузке на браузер.
В прототипе даже чуть больше было, чем надо. Например, была реализована механика управления двумя персонажами, между которыми можно было переключаться в любой момент.
После успешного прототипа у нас появилось понимание, как будет реализована архитектура и организован код. Если говорить про инфраструктурную часть, то это работа с движком в части загрузки ресурсов, создания игровых объектов, переключения экранов. Что касается непосредственно игровой логики — это реализация персонажей, реализация механик взаимодействия с добычей, ловушками, врагами.
Стек разработки был взят довольно типичный для подобного проекта — webpack, webpack-dev-server, babel, babel/preset-typescript.
С трудностями столкнулись в соблюдении требований по производительности и в командном взаимодействии. Приходилось работать с новыми инструментами и передавать друг другу материалы в новых форматах, поэтому не всегда всё получалось гладко с первого раза.
Например, в ТЗ было предусмотрено, что игра при запуске пытается определить производительность устройства, и в случае низкой производительности отображается соответствующее уведомление. На данном этапе мы столкнулись с двумя проблемами. Во-первых, браузер не даёт практически никаких сведений на этот счёт. Во-вторых, производительность конкретной вкладки браузера в конкретный момент времени очень сильно зависит от внешних факторов — сколько вкладок открыто, нет ли тяжёлых сайтов в других вкладках, не свёрнут ли браузер.
Было опробовано несколько теоретических и практических гипотез, из которых родилось финальное решение. Решение состоит в следующем:
Очень важным было требование полной работоспособности игры в IE 11, что тоже доставляло неудобства. Оказалось, что при запущенных инструментах разработчика, и без того небыстрое выполнение Javascript в этом браузере ещё замедлялось.
То есть ты сталкиваешься с тормозами в игре, открываешь инструменты разработчика, чтобы найти причину, а игра тормозит ещё больше.
Игровые механики сами по себе несложные, во многом вдохновлённые существующими играми.
Интересной была механика с ловлей ключей от сундука. Для ключа, который нужно было поймать, область срабатывания сделана меньше, чем визуальный спрайт ключа, а также незначительно смещена в сторону случайным образом. Это привело к желаемому эффекту «у меня ключ с первого раза не собирается» — иногда нужно несколько раз попробовать собрать ключ, чтобы попасть на область его срабатывания. Иначе было слишком просто, хотя в финальном релизе область срабатывания всё-таки была чуть увеличена, чтобы уменьшить процент неудачных попыток.
Все остальные механики собственно тем же и являются — срабатывание приближения и пересечения персонажа и игровых объектов в определенные моменты времени и анимации.
Чуть сложнее были механики с Драконом Страхования, перелётом через пропасть и финальной битвой. Приёмы использовались те же самые, но дополнительно были срежиссированы паузы и бездействия, для того чтобы в это время воспроизвести анимации других персонажей.
Определитесь с жанром на самом раннем этапе.
Игры в вебе — это реально существующее явление, со своей аудиторией и со своими правилами. Такие игры не требуют установки, позволяют устраивать короткие игровые сессии, механикой привлекают больше, чем внешним видом.
Совет — относитесь к разработке веб-игры как к реальной игре, а не как к очередному «скрипту на странице». Тестируйте, профилируйте, не допускайте утечек памяти и повышенной нагрузки на процессор. Игроки и батареи их устройств будут довольны.
