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

Обновлено: 24.04.2024

HTML5 вместе с CSS3 и JavaScript дают разработчику широкие возможности создания игр с использованием 3D, анимации, Canvas, математики, цветов, звука, WebGL. Одно из наиболее очевидных преимуществ HTML5 заключается в его независимости и от платформы, и в общем случае от аппаратной начинки.

При детальном рассмотрении можно выявить предоставляемые движками дополнительные возможности: упрощение некоторых часто встречающихся задач или подгрузка ресурсов, оформленный ввод, физика, звук, bitmap’ы (таких, конечно же, немного). Есть и довольно слабо оформленные движки, а есть и те, которые предоставляют в пользование разработчику редактор 2D уровней и инструменты отладки.

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

Итак, вот, собственно, сами движки.

Crafty

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

Quintus

Quintus – игровой HTML5-движок, разработанный, чтобы быть модульным и легковесным, с четким JavaScript-подобным интерфейсом. Для того, чтобы реализовать основные особенности ООП-игрового движка в HTML5-движке, в Quintus в некотором отношении схож с jQuery, а также поддерживает плагины, управление событиями и гибкую модель наследования, чтобы упростить повторное использование реализованных функций.

gameQuery

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

Идеально подойдет для реализации 2D спрайтовых аркад в ретро-стиле и головоломок вроде Судоку. Он имеет готовый к использованию самозапускающийся игровой цикл. Поддерживаются мышь и клавиатура. Отлично документирован, и главным недостатком можно считать только отсутствие поддержки звуков.

lycheeJS

Игровая библиотека JavaScript, которая предлагает готовое решение для проектирования и реализации HTML5 Canvas и WebGL или нативных OpenGL игр внутри браузера или стационарных платформ. Оптимизирован для Google Chrome.

Enchant.js

Фреймворк Enchant.js для HTML5+JavaScript игр был разработан в 2011 году, распространяется с открытым исходным кодом (MIT лицензия) и потому бесплатен.

The Render Engine

Кросс-браузерный опенсорсный движок, написанный полностью на JavаScript. Созданный с нуля для того, чтобы быть максимально гибким, он имеет обширный API и использует самые новые фичи современных браузеров. Этот фреймворк предназначен, чтобы делать все за вас: ваша идея – его реализация с помощью самых часто используемых инструментов.

GameJS

Большая библиотека на верхнем уровне HTML Canvas. В добавок к функциям рисования в ней имеется растущий ассортимент полезных для разработки игр модулей. Большинство имеющегося API основан на популярной PyGame.

CSS Game Engine

Для формирования страницы используются JavaScript и CSS. Вместе они работают достаточно уверенно и слаженно. Разработан для новичков, обучающихся азам программирования видеоигр. Вам будет проще, если у вас уже есть какие-то навыки работы с CSS.

ClanFX

clanfx основан на JavaScript и CSS и использует плиточную графику. Работает на данный момент в Firefox, Epiphany и Opera. Среди реализованных фич: анимированные спрайты, эффекты заклинаний, постройки, плитки/текстуры и базовый искусственный интеллект.

gTile

Браузерный движок на чистом JavaScript и DHTML. В gTile плиточная графика была выбрана за ее простоту и доступность. Упор в реализации был сделан на высокий уровень интерактивности и поведении игровых объектов. Меньшее внимание было уделено графике. А потому движок подойдет больше для создания текстовых РПГ, а графических возможностей должно хватить для изображения локаций.

Графический JS движок с открытым исходным кодом (GPLv3). Легкий в использовании синтаксис предназначен для того, чтобы сделать фреймворк быстрым и расширяемым.

2D игровая библиотека, основанная на HTML5. Использует и Canvas, и средства DOM.

Cocos2D

Портированный с iPhone графический 2D HTML5-движок на JavaScript. Позволяет быстро создавать 2D игры и графические приложения, которые могут работать на всех современных устройствах без установки дополнительных плагинов.

CopperLicht

WebGL библиотека и JavaScript 3D движок для создания браузерных игр и 3D приложений. Использует WebGL Canvas, поддерживаемый современными браузерами и способный поддерживать рендеринг 3D моделей, используя аппаратное ускорение без плагинов.

Этот HTML/JavaScript движок – реинкарнация набора инструментов для разработки олдскульных RPG (но с более привлекательной графикой). И все только с помощью HTML и JS. Никаких плагинов. Никакого Flash.

LimeJS

HTML5 движок для разработки игр с поддержкой сенсорного ввода. LimeJS создан с использованием Closure Library, созданной Google, и в нем уже реализованы классы и функции для отслеживания времени, событий, обработки форм и анимации. Также фреймворк поддерживает спрайтовые листы (т.е. все используемые изображения могут быть помещены в один файл).

Phaser

Ещё один фреймворк для создания мобильных и десктопных игр на HTML5 с применением Canvas и WebGL. Бесплатный и с открытым исходным кодом. Есть быстрые гайды для старта на JavaScript и TypeScript.

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

Примерно год назад мне показали довольно популярную браузерную онлайн-игру — слитерио. После ознакомления у меня появилась навязчивая идея — мне захотелось сделать что-то похожее по подходу, но с чуть более продвинутым геймплеем. Спустя пару месяцев идея сформировалась в тему этой публикации — игру World of Frogs.

Суть игры — вы управляете лягушкой, можете нападать на других игроков, а также на управляемые компьютером объекты — мух, тараканов, болотных лягушек. Мухи не умеют нападать и умирают с одного удара, тараканы нападают лишь обороняясь, болотные же лягушки нападают как на мух, так и на игроков.

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

Основные пункты, от которых я отталкивался:

С клиентской стороны никакого Flash, только html + js;
Одна машина должна тянуть как можно больший онлайн игроков;
Возможность горизонтального масштабирования;
Низкий порог вхождения в игру и быстрый старт;
Чуть более разнообразный геймплей, чем в слитерио;
Красивый и запоминающийся домен;

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) Производительность одного инстанса игрового сервера

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

Если отобразить на схеме, то верхнеуровнево серверная архитектура выглядит так:

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

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

3) Возможность горизонтального масштабирования

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

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

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

4) Низкий порог вхождения в игру и быстрый старт

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

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

Т.к. онлайн игра как правило предполагает возможность отличать одного игрока от другого, я решил использовать подход никогенерации — при входе в игру берётся случайное прилагательное из заранее заданного списка и комбинируется с случайным существительным, что выдаёт ники вида Неспящий Бугай, Жадный Бурундук, Могучий Валенок и т.п…

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

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

5) Чуть более разнообразный геймплей, чем в слитерио

Как бывший поклонник игры WoW, я хотел разнообразить игру, внеся в неё такие элементы как набор опыта, рост по уровням, получение новых способностей по мере роста, PvE, PvP.

Игроку доступно к использованию 6 способностей (1-я доступна сразу, 2-4 становятся доступны по мере роста по уровням, а 5-6 оформлены как одноразовые поверапы — их можно поднять на игровом поле):

Удар языком — лягушка выстреливает языком и наносит малый урон первой цели на пути;
Прыжок — лягушка прыгает в указанном направлении и в месте приземления наносит высокий урон. Высокий урон способности компенсируется сложностью попадания, а также длительной задержкой между использованиями;
Щит — в течение 3-х секунд поглощает 2 следующие вражеские атаки;
Плевок — лягушка выплёвывает снаряд, который наносит средние повреждения всем врагам на траектории движения);
Лечение — восстанавливает половину жизни;
Ускорение — увеличивает скорость передвижения на 100% на 4 секунды;

Для возможности немного выделиться была добавлена возможность выбрать другую модель игрового персонажа.

6) Красивый и запоминающийся домен;

Изначально в планах было разместить игру на домене .io, аналогично слитерио, агарио и многим другим играм такого формата. Банальные frog.io и frogs.io были заняты, а чего-то более подходящего в .io подобрать не удалось. Играясь с доменами, содержащими frog, наткнулся на весьма удачный вариант — frogs.world, на котором сейчас проект и живёт. Довольно-таки непривычный домен первого уровня, но зато легко запоминается.

В январе я участвовала в своем первом геймджеме — Global Game Jam 2022, в Стамбуле. На джеме все участники писали игры на движках — ибо надо быстро. Игровой движок — это физика, рендеринг, скрипты, искусственный интеллект. Создавать игру с нуля или пользоваться движком — вопрос вкуса. Вон, Джонатан Блоу вообще пишет свой движок, чтобы писать на нем игру.

Я обратила внимание, что большинство студентов использовали либо Unity либо GameMaker. Сама я питаю нежные чувства к Construct, но на нем всего одна команда делала игру. Я решила поискать альтернативу для себя, заодно запилила подборку бесплатных движков для начинающих (а может и продолжающих) игроделов.

Еще я веду канал в Telegram GameDEVils (на русском) и блог на Substack (на английском), делюсь там клевыми материалами (про геймдизайн, разработку и историю игр).

1. Unity

На Unity разработали много игр, прям МНОГО. Вот ссылочка на Википедию. Unity поддерживается на iOS, Android, Windows Phone, Tizen и Fire OS.

Если оборот или объем привлеченных инвестиций не превышает $100 тыс. за последние 12 месяцев, то можно пользоваться бесплатной подпиской Personal.

Про Unity на Хабре:

2. Unreal

Игровой движок от компании Epic Games, тоже очень популярный, вот список игр из Википедии.

Unreal Engine бесплатный аж с 2015 года, но разработчики игр должны передавать 5% от выручки с продаж игры компании Epic Games, если ежеквартальная выручка превышает $1 000 000.

Про Unreal на Хабре:

3. GameMaker: Studio2

Интерфейс Game Maker объединяет в себе редакторы спрайтов, объектов, комнат, скриптов, а также тайм-лайнов (последовательностей действий с привязкой по времени), путей (маршрутов) движения и констант. Летом 2021 года YoYo Games сделали беплатный доступ без ограничений по времени. Изначально они выдавали триалку только на месяц, для знакомства. Правда экспортировать на бесплатной версии можно разве что на GXC.

За базовую подписку CREATOR (≈ 80 руб./мес.) появляется экспорт для Windows, macOS и Linux. За INDIE (≈ 260 руб./мес.) появляется экспорт для HTML5 и мобилки.

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

Про GameMaker на Хабре:

4. Godot

Про Godot на Хабре:

Cocos2d

Крос-платформенный опенсорсный фрейворк для разработки игр и приложений, преимущественно для мобилки с лицензией MIT. Cocos2d-x развертывается в iOS, Android, HTML5, Windows и Mac.

Фреймворк поддерживает создание 2D и 3D игр, предоставляет такие функции, такие как рендеринг графики, графический интерфейс, аудио, сеть, физика, пользовательский ввод и т.д. Ядро написано на C++ и поддерживает разработку на C++, Lua или JavaScript. У фрейворка есть множество ответвлений: Cocos2d-ObjC, Cocos2d-x, Cocos2d-html5 и Cocos2d-XNA.

Про Cocos2d на Хабре:

5. Construct

Ноу-код движок для создания 2D игр. Запускается в браузере, работает из десктопа офлайн. Движок не дает большой гибкости, как GameMaker, и также дружелюбен к новичкам без технического бэкграунда + на ютубе выложена куча туториалов.

Есть бесплатная версия Construct, основное ограничение — 2 слоя и максимум 25 «событий» (если авторизоваться, то 50 «событий») в проекте. За события считается любое действие / поведение объекта. Но чтобы попробовать, и даже собрать элементарный платформер — хватает. Персональная лицензия стоит около $5.

6. Twine

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

Чтобы создать простенький сторителлинг с помощью Twine, код писать не нужно. Но можно. Можно дополнить свои истории с за счет переменных, условной логики, изображений, CSS и JavaScript.

Про Twine на Хабре:

7. Adobe AIR SDK (HARMAN)

Кроссплатформенный движок (Windows, OS X, Linux, QNX, Android) от компании Adobe, которая пару лет назад передала на нее права компании HARMAN. Этот движок можно использовать бесплатно, если вы зарабатываете менее 50 тысяч долларов в год. Движок все еще популярен в Steam, от части из-за адаптаций браузерных игр на Flash.

На Хабре про AIR:

8. Ren'Py

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

Про Ren'Py на Хабре:

9. Bitsy

Крошечный онлайн редактор для мини-игр. Это какой-то супер-милый проект и милым сайтом. Разработчик выкладывает логи проекта на itch.io. И там же можно поиграть в игры, сделанные с помощью Bitsy движка.

10. LÖVE

Фреймворк для создания 2D игр на Lua. Он бесплатный, с открытым исходным кодом и работает на Windows, Mac OS X, Linux, Android и iOS. Лицензия zlib, позволяет свободное использовать движок даже в коммерческих проектах с закрытыми исходниками.

Про LÖVE на Хабре:

11/12. XNA и/или MonoGame

НЕбесплатные движки с itch.io и Steam

PICO-8

RPG Maker

Это серия движков для создания РПГ, точнее JRPG, японских ролевых игр. Для RPG Maker тоже нет бесплатной подписки, но есть пробная триалка. RPG Maker поддерживает только Windows. В Steam он лежит для разовой покупки от 500 до 3000 рублей, в зависимости от продукта, там есть несколько «комплектаций». Менять скрипты под себя можно на Ruby-подобном языке.

Больше бесплатных движков

Вот бонусом еще 11 бесплатных вариантов движков:

1. Amazon Lumberyard

Бесплатный кросс-платформенный игровой движок, разработанный Amazon. Визуальная технология Lumberyard основана на CryEngine, но команда разработчиков Amazon уже внесла в систему значительные обновления. Роялти нет, лицензионных сборов нет. Amazon зарабатывает деньги через Amazon Web Service. Естественно, у этого игрового движка прекрасная совместимости с AWS. Помимо бесшовной интеграции с AWS, Lumberyard также предлагает интеграцию с Twitch.

Про Amazon Lumberyard на Хабре:

2. Solar2D (бывший Corona SDK)

Кросплатформенный движок с открытым исходным кодом для создания мобильных 2D-игр и приложений. Поддерживает такие платформы, как Android, iOS, Kindle, macOS, Windows, Linux. Предусмотрена сборка веб-приложений (HTML5). Solar 2D использует интегрированный Lua, наложенный поверх C++ / OpenGL.

Про Solar2D на Хабре:

3. jMonkeyEngine

Движок с открытым исходным кодом, написанный на Java для создания игр и приложений для Android или iOS. Точнее jMonkeyEngine — это набор библиотек для низкоуровневой разработки, а в высокоуровневый инструментарий его превращает интегрированная среда разработки, к примеру jMonkeyEngine 3 SDK.

Про jMonkeyEngine на Хабре:

4. SpriteKit

Это движок для 2-D игр, разработанный Apple и предназначенный для устройств Apple.

Про SpriteKit на Хабре:

5. Box2D

Физический движок от разработчика из Blizzard Entertainment, написан на C++, лицензия MIT.

Про Box2D на Хабре:

6. LibGDX

Кросплатформенная среда разработки на Java, которая предоставляет унифицированный API для создания 2D- и 3D-игр. LibGDX дружит с движком Box2D (физика реального мира), можно добавить поддержку TrueType шрифтов или работать с 3D объектами.

А еще коммьюнити LibGDX проводит геймджемы раз в сезон (март, июнь, сентябрь, декабрь), вот ссылочка на подробную информацию: Game Jams.

Про LibGDX на Хабре:

7. Urho3D

Бесплатный 2D и 3D игровой движок, запускается на Windows, Linux, macOS/iOS/tvOS, Android, и даже на Raspberry Pi и в браузере. Вики Urho3D содержит всю инфу для начала работы с движком, включая практические руководства по настройке.

Про Urho3D на Хабре:

8. CryEngine

Если вы использовали версию движка 5.5+ и заработали 5000$, то придется выплачивать 5% от прибыли. Если вы используете более ранние версии, то можете подать заявку на освобождение от выплат.

Про CryEngine на Хабре:

9. Panda 3D

Движок с открытым исходным кодом для 3D-игр. Язык разработки игр — Python. Сам движок написан на C++ и использует автоматический wrapper-генератор для предоставления полной функциональности движка в интерфейсе Python. Panda 3D может работать практически на всех основных платформах.

10. Bitty

Небольшой кроссплатформенный движок и опенсорсный фреймворк для создания 2D-игр на Lua…

11. Phaser

HTML5-опенсорсный движок для тех, кому хочется писать JavaScript or TypeScript браузерные 2D игры. Для начала работы с движком создатель предлагает просто начать вносить свои правки в уже существующие общедоступные игры и смотреть, что из этого получается. Плюс есть форум, где чувачки из комьюнити активно отвечают.

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

(Это я в шапочке, честное слово)

Мой канал в Telegram с находками про разработку игр, историю игр и геймдизайн: GameDevils (на русском) и блог на Substack (на английском).

Современная вычислительная техника позволяет создавать классные компьютерные игры! И сейчас, достаточно популярны игры с 3d-графикой, так как, играя в них, ты окунаешься в вымышленный мир и теряешь всякую связь с реальностью. Развитие интернета и браузерных технологий сделало возможным запускать головоломки и стрелялки в любимом Хроме, Мозилле или еще в чем-то там (про Эксплорер помолчим) в онлайн-режиме, без загрузки. Так вот, здесь я расскажу о том, как создать простую трехмерную браузерную игру.

Выбор жанра, сюжета и стилистики игры является достаточно интересной задачей, и от решения этих вопросов может зависеть успех игры. Кроме этого, свои нюансы вносит и выбор технологии, на основе которой будет создаваться продукт. Моя цель – показать элементарные основы этого увлекательного процесса, поэтому я буду делать 3-мерный лабиринт с незамысловатым оформлением. Более того, я это сделаю на чистом коде без использования библиотек и движков, типа three.js (хотя большие проекты лучше делать все-таки на нем), чтобы показать, как можно создать движок для своих нужд. Полностью самописная игра может быть оригинальной, а потому интересной. В общем, оба подхода имеют свои плюсы и минусы.

Я полагаю, если вы читаете эту статью, то вам интересна тема создания игр для гугл Хром, а, значит, понимаете, как работает связка html-css-javaScript, поэтому не буду останавливаться на основах, а сразу приступлю к разработке. В html5 и css3, которые поддерживают все современные браузеры (Эксплорер не в счет), есть возможность расположения блоков в 3-мерном пространстве. Также есть элемент , в котором можно рисовать линии и графические примитивы. Большинство браузерных движков используют , так как на нем можно сделать больше вещей, да и производительность на нем выше. Но для простых вещей вполне можно использовать методы transform-3d, которые будут занимать меньше кода.

1. Инструменты для разработки

Я использую для проверки сайтов и игр только 2 браузера: Chrome и Mozilla. Все остальные браузеры (кроме того самого Эксплорера) построены на движке первого, поэтому использовать их я не вижу смысла, ибо результаты точно такие же, как и в Chrome. Для написания кода достаточно Notepad++.

2. Как реализуется трехмерное пространство в html?

Посмотрим на систему координат блока:

По умолчанию, дочерний блок имеет координаты (left и top) 0 пикселей по x и 0 пикселей по y. Смещение (translate), также 0 пикселей по всем трем осям. Покажем это на примере, для чего создадим новую папку. В нем создадим файлы index.html, style.css и script.js. Откроем index.html и запишем туда следующее:

В файле style.css зададим стили для элементов “container” и “world”.

Сохраним. Откроем index.html c помощью Chrome, получим:

Попробуем применить translate3d к элементу “world”:

Как вы поняли, я перешел в полноэкранный режим. Теперь зададим смещение по оси Z:
transform:translate3d(200px,100px,-1000px);

Если вы снова откроете html-файл в браузере, то никаких изменений вы не увидите. Чтобы увидеть изменения, нужно задать перспективу для объекта “container”:

Квадрат отдалился от нас. Как работает перспектива в html? Взглянем на картинку:

d – расстояние от пользователя до объекта, а z – его координата. Отрицательный z (в html это translateZ) означает, что мы отдалили объект, а положительный – наоборот. Значение perspective определяет величину d. Если же свойство perspective не задано, то значение d принимается за бесконечность, а в этом случае объект визуально не изменяется для пользователя с изменением z. В нашем случае мы задали d = 600px. По умолчанию, точка взгляда перспективы находится в центре элемента, однако ее можно изменить путем задания свойства perspective-origin: .

Теперь повернем “world” вокруг какой-нибудь оси. В сss можно использовать 2 способа вращения. Первый – вращение вокруг осей x,y и z. Для этого используются transform-свойства rotateX(), rotateY() и rotateZ(). Второй – вращение вокруг заданной оси с помощью свойства rotate3d(). Мы будем использовать первый способ, так как он больше подходит для наших задач. Обратите внимание, что оси вращения выходят из центра прямоугольника!

Точка, относительно которой происходят трансформации, может быть изменена путем задания свойства translate-origin: . Итак, зададим вращение “world” по оси x:

Заметно смещение против часовой стрелки. Если же мы добавим rotateY(), то получим смещение уже по оси Y. Важно заметить, что при вращении блока оси вращения также поворачиваются. Вы также можете поэкспериментировать с различными значениями вращения.
Теперь внутри блока “world” создадим еще один блок, для этого добавим тег в html-файл:

В style.css добавим стили к этому блоку:

То есть, элементы внутри блока “world” будут трансформироваться в составе этого блока. Попробуем повернуть “square1” по оси y, добавив к нему стиль вращения:
transform: rotateY(30deg);

«Где вращение?» — спросите вы? На самом деле именно так выглядит проекция блока “square1” на плоскость, образуемую элементом “world”. Но нам нужна не проекция, а настоящее вращение. Чтобы все элементы внутри “world” стали объемными, необходимо применить к нему свойство transform-style:preserve-3d. После подстановки свойства внутрь списка стилей “world” проверим изменения:

3. Создаем движение в трехмерном мире

Для того, чтобы пользователь мог по этому миру передвигаться, нужно задать обработчики нажатия клавиш и перемещения мыши. Управление будет стандартным, какое присутствует в большинстве 3д-шутеров. Клавишами W, S, A, D мы будем перемещаться вперед, назад, влево, вправо, пробелом мы будем прыгать (проще говоря – перемещаться вверх), а мышью мы будем менять направление взгляда. Для этого откроем пока еще пустой файл script.js. Сначала впишем туда такие переменные:

Изначально клавиши не нажаты. Если мы нажмем клавишу, то значение определенной переменной изменится на 1. Если отпустим ее, то она снова станет 0. Реализуем это посредством добавления обработчиков нажатия и отжатия клавиш:

Номер 32 – код пробела. Как видите, тут появилась переменная onGround, указывающая на то, находимся ли мы на земле. Пока разрешим движение вверх, добавив после переменных press… переменную onGround:

Итак, мы добавили алгоритм нажатия и отжатия. Теперь необходимо добавить само передвижение. Что, собственно, мы передвигаем. Представим, что у нас есть объект, который мы двинаем. Назовем его “pawn”. Как и принято у нормальных разработчиков, для него мы создадим отдельный класс “Player”. Классы в javaScript создаются, как ни странно, с помощью функций:

Вставим этот код в script.js в самом начале файла. В конце же файла создадим объект данного типа:

Распишем, что означают эти переменные. x, y, z – это начальные координаты игрока, rx, ry – углы его поворота относительно осей x и y в градусах. Последняя записанная строка означает, что мы создаем объект “pawn” типа “player” (специально пишу тип, а не класс, так как классы в javascript означают несколько другие вещи) с нулевыми начальными координатами. Когда мы двигаем объект, координата мира изменяться не должна, а должна изменяться координата «pawn». Это с точки зрения переменных. А с точки зрения пользователя, игрок находится на одном месте, а вот мир двигается. Таким образом, нужно заставить программу изменять координаты игрока, обрабатывать эти изменения и двигать, в конце концов, мир. На деле это проще, чем кажется.

Итак, после загрузки документа в браузер мы запустим функцию, которая перерисовывает мир. Напишем функцию перерисовки:

В новых браузерах world будет соответствовать элементу с однако надежнее ее присвоить перед функцией update() с помощью следующей конструкции:

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

Запустим игру. Ура, теперь мы можем двигаться! Однако мир вылазит за пределы рамок элемента «container». Чтобы этого не происходило, зададим css-свойство для него в style.css. Добавим строку overflow:hidden; и посмотрим на изменения. Теперь мир остается в пределах контейнера.

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

Если у вас что-то по-другому, обязательно поправьте!

Мы научились двигать персонажа, однако мы еще не умеем поворачивать его! Поворот персонажа, конечно же, будет осуществляться с помощью мыши. Для мыши к переменным состояния клавиш press… мы добавим переменные состояния движения мыши:

А после обработчиков нажатия-отжатия вставим обработчик движения:

В функцию update добавим поворот:

Обратите внимание на то, что движение мыши по оси y вращает pawn по оси x и наоборот. Если мы посмотрим на результат, то ужаснемся от увиденного. Дело в том, что если смещения нет, то MouseX и MouseY остаются прежними, а не приравниваются к нулю. Значит, после каждой итерации update смещения миши должно обнуляться:

Уже лучше, мы избавились от инерции вращения, однако вращение происходит все равно странно! Чтобы понять, что все-таки происходит, добавим div-элемент «pawn» внутрь «container»:

Зададим ему стили в style.css:

Проверим результат. Теперь все ровно! Единственное — синий квадрат остается впереди, но пока оставим это. Чтобы сделать игру от первого лица, а не от третьего, нужно приблизить мир к нам на значение perspective. Сделаем это в script.js в функции update():

Теперь можно делать игру от первого лица. Скроем pawn добавив строку в style.css:

Отлично. Сразу скажу, что ориентироваться в мире с одним квадратом крайне тяжело, поэтому создадим площадку. Добавим в «world» блок «square2»:

А в style.css добавим стили для него:

Теперь все четко. Ну… не совсем. Когда мы нажимаем по клавишам, мы движемся строго по осям X и Z. А мы хотим сделать движение по направлению взгляда. Сделаем следующее: в самом начале файла script.js добавим 2 переменные:

Градус — это pi/180 от радиана. Нам придется применить синусы и косинусы, которые считаются от радиан. Что нужно сделать? Взгляните на рисунок:

Когда наш взгляд направлен под углом и мы хотим пойти вперед, то изменятся обе координаты: X и Z. В случае перемещения в сторону тригонометрические функции просто поменяются местами, а перед образовавшимся синусом изменится знак. Изменим уравнения смещений в update():

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

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

Теперь совсем другое дело. Однако лучше вообще сделать так, чтобы вращение производилось только тогда, когда курсор захвачен. Введем новую переменную после переменных нажатия клавиш press…

Добавим обработчик изменения состояния захвата курсора (захвачен или нет) перед обработчиком захвата курсора (извините за тавтологию):

А в update() добавим условие вращения “pawn”:

А сам захват мыши при клике по контейнеру разрешим только тогда, когда курсор еще не захвачен:

С движением мы полностью разобрались. Перейдем к генерации мира

4. Загрузка карты

Мир в нашем случае удобнее всего представить в виде множества прямоугольников, имеющих разное местоположение, поворот, размеры и цвет. Вместо цвета также можно использовать текстуры. На самом деле, все современные трехмерные миры в играх – это набор треугольников и прямоугольников, которые называют полигонами. В крутых играх их количество может достигать десятков тысяч в одном только кадре. У нас же их будет около сотни, так как браузер сам по себе имеет невысокую графическую производительность. В предыдущих пунктах мы вставляли блоки “div” внутрь “world”. Но если таких блоков много (сотни), то вставлять каждый из них в контейнер очень утомительно. Да и уровней может быть много. Поэтому пусть эти прямоугольники вставляет javaScript, а не мы. Для него же мы будем создавать специальный массив.

Откроем index.html и удалим из блока “world” все внутренние блоки:

Теперь создадим массив прямоугольников (запихнем его, примеру, между конструктором player и переменными press… в script.js):

Можно было это сделать в виде конструктора, но пока обойдемся чисто массивом, так как запуск цикла расстановки прямоугольников проще реализовать именно через массивы, а не через конструкторы. Я же поясню, что означают цифры в нем. Массив map содержит одномерные массивы из 9 переменных: [. ]. Я думаю, вы понимаете, что первые три числа – это координаты центра прямоугольника, вторые три числа – углы поворота в градусах (относительно того же центра), затем два числа – его размеры и последнее число – фон. Причем фон может быть сплошным цветом, градиентом или фотографией. Последнее очень удобно использовать в качестве текстур.

Массив мы записали, теперь запишем функцию, которая переделает этот массив в собственно прямоугольники:

Поясню, что происходит: мы создаем новую переменную, которая указывает на только что созданный элемент. Ему мы присваиваем id и css-класс (именно это и имеется ввиду под словом класс в языке javaScript), задаем ширину с высотой, фон и трансформацию. Примечательно, что в трансформации помимо координат центра прямоугольника мы указываем смещение на 600 и 400 и половины размеров для того, чтобы центр прямоугольника точно оказался в точке с нужными координатами. Запустим генератор мира перед таймером:

Теперь мы видим площадку с розовыми стенами и серым полом. Как видите, создание карты технически несложно реализовать. А в результате ваш код в трех файлах должен получиться примерно таким:

Если все хорошо, переходим к следующему пункту.

5. Столкновения игрока с объектами мира

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

А вызывать ее будем в update():

Как это происходит? Представим себе, что игрок – это шар с радиусом r. И он движется в сторону прямоугольника:

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

И обратную функцию:

Вставим эти функции после функции update(). Я не буду объяснять, как это работает, потому что мне не хочется рассказывать курс аналитической геометрии. Скажу, что есть такие формулы перевода координат при вращении и мы просто ими воспользовались. С точки зрения прямоугольника наш игрок расположен вот так:

В этом случае условие коллизии становится таким: если после смещения шара на величину v (v – это вектор) координата z между –r и r, а координаты x и y лежат в пределах прямоугольника или отстоят от него на величину, не большую r, то объявляется коллизия. В этом случае координата игрока по z после смещения будет составлять r или – r (в зависимости от того, с какой стороны придет игрок). В соответствии с этим, смещение игрока изменяется. Мы специально вызываем коллизию перед тем, как в update() координаты игрока будут обновлены, чтобы вовремя изменить смещение. Таким образом, шар никогда не пересечется с прямоугольником, как бывает в других алгоритмах коллизии. Хотя физически игрок будет представлять собой, скорее, случае куб, мы не будем обращать на это внимание. Итак, реализуем это в javaScript:

x0,y0 и z0 – начальные координаты игрока в системе координат прямоугольника (без поворотов. x1,y1 и z1 – координаты игрока после смещения без учета коллизии. point0, point0, point1 и point2 – начальный радиус-вектор, радиус-вектор после смещения без коллизии и радиус-вектор с коллизией соответственно. map[i][3] и другие, если вы помните, это углы поворота прямоугольника. Заметим, что в условии мы к размерам прямоугольника прибавляем не 100, а 98. Это костыль, зачем, подумайте сами. Запустите игру и вы увидите довольно качественные столкновения.

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

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

В 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 :

Интенсив «Быстрый старт в Go-разработке: создаём Telegram-бота с нуля»» 23 июня в 19:00, Онлайн, Беcплатно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также: