Как сделать браузерную онлайн игру

Введение в разработку Web-игр

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

Качество браузерных игр не уступает аналогам, созданных для настольных компьютеров. Благодаря современным веб-технологиям вполне возможно создавать первоклассные игры. И мы не говорим о простых карточных играх или играх, которые раньше создавались с использованием Flash®. Мы говорим о 3D-шутерах, ролевых играх и многом другом. Благодаря значительному повышению производительности JavaScript и новым API-интерфейсам вы можете создавать игры, которые запускаются в браузере (или на устройствах, поддерживающих HTML5) без каких-либо проблем.

Игровая платформа HTML5

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

Функционал	Технология
Звук	Web Audio API
Графика	WebGL (OpenGL ES 2.0)
Ввод	Touch events, Gamepad API, датчики устройства, WebRTC, Full Screen API (en-US) , Pointer Lock API
Язык программирования	JavaScript (или C/C++ с использованием Emscripten для компиляции в JavaScript)
Сеть	WebRTC и/или WebSockets
Хранилище	IndexedDB или «облако»
Веб	HTML, CSS, SVG (и много других!)

Экономическое обоснование

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

Охват интернета огромен, он повсюду. Игры, построенные на HTML5, работают на смартфонах, планшетах, ПК и телевизорах Smart TV.
Маркетинг и открытость улучшаются. Вы не ограничиваетесь продвижением своего приложения в чужом магазине приложений. Вместо этого вы можете рекламировать и продвигать свою игру по всему интернету, а также в других средствах массовой информации, используя преимущества присущей сети связности и доступности для новых клиентов.
У вас есть контроль, где это имеет значение: Платежи. Вы не должны отдавать 30% своих доходов кому-то другому только потому, что ваша игра в их экосистеме. Вместо этого, взимать плату, что вы хотите, и использовать любую услугу обработки платежей вам нравится.
Опять же, с большим контролем, вы можете обновить игру, когда захотите. Не жди, затаив дыхание, одобрения, пока кто-то прячется внутри другого.
Контролируйте свою аналитику! Вместо того чтобы полагаться на кого-то другого в принятии решений о том, какая аналитика вам нужна, вы можете собрать свою собственную-или выбрать третью сторону, которая вам больше всего нравится, — чтобы собрать информацию о ваших продажах и досягаемости вашей игры.
Вы можете управлять своими отношениями с клиентами более тесно, по-своему. Больше не придётся работать с обратной связью магазина приложений. Взаимодействуйте со своими клиентами так, как вы хотите, без посредника.
Ваши игроки могут играть в вашу игру в любом месте, в любое время. Поскольку интернет распространён повсеместно, ваши клиенты могут проверить статус своей игры на своих телефонах, планшетах, домашних ноутбуках, рабочих столах или на чем-либо ещё.

Веб-технологии для разработчиков игр

Эта информация будет полезна техническим специалистам. Давайте углубимся в API-интерфейсы, которые веб-технологии предлагают разработчикам игр. Вот подробный список, который даст вам представление об этом:

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

Этот простой API позволяет вашей игре использовать весь экран, тем самым погружая игрока в действие.

Если вы хотите, чтобы ваши пользователи могли использовать геймпады и прочие игровые контроллеры для работы с игрой, вам потребуется этот API

Эти технологии помогут вам создать и разместить UI вашей игры, а HTML-элемент это один из способов создать 2D-графику

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

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

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

SVG (масштабируемая векторная графика)

Позволяет создавать векторную графику, которая плавно масштабируется независимо от размера или разрешения дисплея пользователя.

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

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

Позволяет создавать высокопроизводительную аппаратно-ускоренную 3D (и 2D) графику из веб-контента. Это веб-реализация OpenGL ES 2.0.

API WebRTC (Real-Time Communications) даёт вам возможность управлять аудио- и видеоданными, включая телеконференции и передачу данных из других приложений между двумя пользователями. Хотите, чтобы ваши игроки могли общаться друг с другом, взрывая монстров? Это API для вас!

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

Web Workers даёт вам возможность создавать фоновые потоки, выполняющие собственный код JavaScript, используя преимущества современных многоядерных процессоров.

Разработка браузерной онлайн-игры

Привет, хабровчане. Меня зовут Евгений, по профессии я backend-разработчик и пишу я на языке c# в сегменте enterprise приложений. В этой публикации я хочу рассказать вам о своём опыте в не совсем профильной для меня сфере — разработке видеоигр, а конкретнее — о разработке браузерной онлайн-игры.

Я привык относить себя к тем везучим людям, у которых хобби совпадает с работой — я люблю разработку ПО. Поэтому для меня абсолютно нормально, вернувшись домой, вновь сесть за компьютер, открыть 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) Производительность одного инстанса игрового сервера

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

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

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

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

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

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

Самым серьёзным бустом к производительности был отказ от использования 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, на котором сейчас проект и живёт. Довольно-таки непривычный домен первого уровня, но зато легко запоминается.

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

разработка игр
браузерная игра
онлайн-игра

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

Рассказываем о создании простой многопользовательской браузерной игры на JavaScript и Node.js с использованием веб-сокетов.

Рассказывает Алвин Лин, разработчик программного обеспечения из Нью-Йорка

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

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

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

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

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

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

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

npm init npm install --save express socket.io

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

// Зависимости var express = require('express'); var http = require('http'); var path = require('path'); var socketIO = require('socket.io'); var app = express(); var server = http.Server(app); var io = socketIO(server); app.set('port', 5000); app.use('/static', express.static(__dirname + '/static')); // Маршруты app.get('/', function(request, response) < response.sendFile(path.join(__dirname, 'index.html')); >); // Запуск сервера server.listen(5000, function() < console.log('Запускаю сервер на порте 5000'); >);

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

  Наша многопользовательская игра canvas

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

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

// Обработчик веб-сокетов io.on('connection', function(socket) < >);

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

setInterval(function() < io.sockets.emit('message', 'hi!'); >, 1000);

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

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

var socket = io(); socket.on('message', function(data) < console.log(data); >);

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

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

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

socket.on('name', function(data) < // аргумент data может содержать любые отправляемые данные >);

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

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

var movement = < up: false, down: false, left: false, right: false >document.addEventListener('keydown', function(event) < switch (event.keyCode) < case 65: // A movement.left = true; break; case 87: // W movement.up = true; break; case 68: // D movement.right = true; break; case 83: // S movement.down = true; break; >>); document.addEventListener('keyup', function(event) < switch (event.keyCode) < case 65: // A movement.left = false; break; case 87: // W movement.up = false; break; case 68: // D movement.right = false; break; case 83: // S movement.down = false; break; >>);

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

socket.emit('new player'); setInterval(function() < socket.emit('movement', movement); >, 1000 / 60);

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

var players = <>; io.on('connection', function(socket) < socket.on('new player', function() < players[socket.id] = < x: 300, y: 300 >; >); socket.on('movement', function(data) < var player = players[socket.id] || <>; if (data.left) < player.x -= 5; >if (data.up) < player.y -= 5; >if (data.right) < player.x += 5; >if (data.down) < player.y += 5; >>); >); setInterval(function() < io.sockets.emit('state', players); >, 1000 / 60);

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

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

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

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

var canvas = document.getElementById('canvas'); canvas.width = 800; canvas.height = 600; var context = canvas.getContext('2d'); socket.on('state', function(players) < context.clearRect(0, 0, 800, 600); context.fillStyle = 'green'; for (var id in players) < var player = players[id]; context.beginPath(); context.arc(player.x, player.y, 10, 0, 2 * Math.PI); context.fill(); >>);

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

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

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

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

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

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

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

while (true) < socket.emit('movement', < left: true >); >

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

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

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

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

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

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

setInterval(function() < // код . player.x += 5; // код . >, 1000 / 60);

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

var lastUpdateTime = (new Date()).getTime(); setInterval(function() < // код . var currentTime = (new Date()).getTime(); var timeDifference = currentTime - lastUpdateTime; player.x += 5 * timeDifference; lastUpdateTime = currentTime; >, 1000 / 60);

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

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

io.on('connection', function(socket) < // обработчик событий . socket.on('disconnect', function() < // удаляем отключившегося игрока >); >);

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

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

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

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

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

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

Выводы и советы

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

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

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