Всем привет! В нескольких статьях я хотел бы поделиться опытом создания подобия ММО игры используя Unreal Engine и Netty. Возможно архитектура и мой опыт кому-то пригодится и поможет начать создавать свой игровой сервер в противовес unreal dedicated server, который слегка прожорлив или заменить собой фреймворки для разработки многопользовательских игр такие как Photon.

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

Часть 1. Общая картина, сборка библиотек, подготовка клиента и сервера к обмену сообщениями
Часть 2. Наращивание игрового функционала + алгоритм Diamond Square

Шаблоны проектирования часто встраивают в популярные фреймворки. Например, шаблон MVC (Model-View-Controller, Модель-Представление-Контроллер) можно встретить буквально повсюду. В JavaScript трудно отделить фреймворк от реализованного в нём шаблона проектирования, причём, часто авторы фреймворков интерпретируют MVC по-своему и навязывают программистам своё видение вопроса.



То, как именно будет выглядеть конкретная реализация MVC, полностью зависит от фреймворка. В результате мы получаем массу разных реализаций, что сбивает с толку и ведёт к беспорядку. Особенно это заметно, когда в одном проекте используется несколько фреймворков. Эта ситуация заставила меня задаться вопросом: «А есть ли способ лучше?».

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



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

Проблема многопользовательских игр

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

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

Обычно программа игры должна симулировать следующее:

изменения в окружении с учётом времени и вводимых игроками данных.

Игра — это программа, хранящая состояние, поэтому она зависит от времени (реального или логического). Например, PACMAN симулирует окружение, в котором постоянно перемещаются призраки.

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

Сегодня Redux — это одно из наиболее интересных явлений мира JavaScript. Он выделяется из сотни библиотек и фреймворков тем, что грамотно решает множество разных вопросов путем введения простой и предсказуемой модели состояний, уклоне на функциональное программирование и неизменяемые данные, предоставления компактного API. Что ещё нужно для счастья? Redux — библиотека очень маленькая, и выучить её API не сложно. Но у многих людей происходит своеобразный разрыв шаблона — небольшое количество компонентов и добровольные ограничения чистых функций и неизменяемых данных могут показаться неоправданным принуждением. Каким именно образом работать в таких условиях?

В этом руководстве мы рассмотрим создание с нуля full-stack приложения с использованием Redux и Immutable-js. Применив подход TDD, пройдём все этапы конструирования Node+Redux бэкенда и React+Redux фронтенда приложения. Помимо этого мы будем использовать такие инструменты, как ES6, Babel, Socket.io, Webpack и Mocha. Набор весьма любопытный, и вы мигом его освоите!

Оглавление

0. Подготовка к работе
1. Введение [Вы тут]
2. Загрузка ресурсов
3. Создание игрового мира
4. (wip) Группы
5. (wip) Мир физики
6. (wip) Управление
7. (wip) Добавление целей
8. (wip) Последние штрихи

Добро пожаловать в наш первый урок по созданию игр на Phaser. Здесь я расскажу вам, как создать небольшую игру — платформер, которая познакомит вас с основными функциями данного фремворка и работу с ним в нынешних реалиях (ES6 / TypeScript + WebPack).

Что такое Phaser?

Phaser — это HTML5 (JavaScript / TypeScript) игровой фреймворк, который призван помочь разработчикам создавать крутые, кросс-браузерные HTML5 игры в короткие сроки и, в отличии от других фреймворков, phaser изначально затачивался под мобильные устройства. Единственное требование выдвигаемое данным фреймворком — поддержка тега <canvas />. Он также много чего унаследовал от Flixel.

Давайте представим, что вас перевели на новый проект. Или вы сменили работу и о проекте максимум только слышали. Вот вы садитесь за рабочее место, к вам приходит менеджер, жмёт руку и… прямо сходу открывает страницу проекта, тыкает пальцем в монитор и просит вставить «информер о предстоящем событии Х». На этом вы расстаётесь… Что делать? С чего начать? Как создать «информер»? Где найти нужный шаблон? И море других вопросов.

Под катом будет рассказ, как мы стараемся организовать эти процессы, какие инструменты создаём для препарирования SPA. Кроме этого, мы поговорим о технических подробностях реализации Live Coding / Hot Reload и чуток о VirtualDom и React с Angular.

Около 2-х месяцев назад я и TheShock собирали вопросы по JavaScript в теме FAQ по JavaScript: задавайте вопросы. Первая часть, те вопросы, которые достались мне, появилась буквально через несколько дней JavaScript F.A.Q: Часть 1, а вот вторая часть все не выходит и не выходит. TheShock сейчас переезжает в другую страну и поэтому ему не до ответов. Он попросил меня ответить на его часть. Итак вторая часть ответов — те вопросы, которые достались тоже мне.

Несколько дней назад мы с TheShock создали топик в котором собирали ваши вопросы, касательно JavaScript (архитектура, фрэймворки, проблемы). Настало время ответить на них. Мы получили очень много вопросов, как в комментариях так и по email. Эта первая часть ответов — те вопросы, которые достались мне.

Русский вариант названия игры, звучит как «Беспризорные блоки», что достаточно емко передает ее сюжетную линию. Негоже достойным представителям рода «четырехугольных» околачиваться где ни попадя. Основной задачей игрока будет поиск им пристанища за что и будут начисляться игровые баллы. Приютить наших «сироток» можно по бортам игрового поля, но только при условии соответствия цвета и достаточного уровня благонадежности. Далее обо всем по порядку…

Это перевод статьи Крэга Баклера (Craig Buckler) «SitePoint Smackdown: PHP vs Node.js» и судейских решений Бруно Шкворца и Джеймса Хиббарда (Bruno Škvorc, James Hibbard) статьи Крэга Баклера.

От переводчика

Существует много статей на эту тему, с качественными характеристическими анализами и прогнозами производительности. Однако, мне все же хотелось найти такую статью, где профессиональные программисты делятся своими мнениями и пытаются что-то подсказать, предостеречь новичка, который только изучает PHP или NodeJS (cерверный JavaScript). Многие не любят PHP и говорят, что PHP создан, чтобы умирать (да, там есть сборщик мусора, который убивает наши переменные после выполнения скрипта, а не потому что его забросил Расмус Лердорф), однако, что теперь не учить PHP совсем, в то время как на нем работает 80% сайтов в интернете. Поэтому, если мы хотим быть профессионалами и пытаться хоть как-то расширить свой кругозор, нам нужно четко разделять задачи PHP и задачи NodeJS, а не сливать все в кучу.

«10 раундов боксеров разных весовых категорий»

Одним прекрасным днем Крэг Баклэр (Craig Buckler) на сайте SitePoint.com опубликловал сравнительный анализ PHP и NodeJS под названием «10 раундов», чтобы определить кто является абсолютным чемпионом. Однако, в это же время он отметил, что такой анализ является несколько спорным. Поэтому, для некоторого развлечения, он пригласил двух судей, которые внесли бы свою лепту в этот боксерский поединок. Он попросил Бруно Шкворца (Bruno Škvorc, редактор колонки PHP на сайте SitePoint.com) и Джеймса Хиббарда (James Hibbard, редактор колонки JavaScript на сайте SitePoint.com) прокомментировать каждый из раундов, удар за ударом — оценка.

В последнее время все чаще возникают разговоры по поводу пресыщения проектами стандартных игровых рынков, таких как мобильный, Steam, онлайн. Начинающим, инди или небольшим компаниям становится всё сложнее продвигать свой продукт и хотя-бы отбивать затраты на его создание. В том же Google Play ежедневно выходят десятки новых игр и для попадания в заветные топы тратятся значительные деньги на продвижение. Сложилась ситуация, когда верхние строчки топов постоянно забиты проектами с очень серьезными бюджетами. То же самое касается и Steam. Так что же делать?

В октябре этого года в Москве прошла уже привычная конференция по разработке и продвижению игр White Nights 2016. В этот раз прозвучали некоторые обнадеживающие новости по образованию перспективных рынков сбыта.

Отличная подборка, как нарисовать различные геометрические фигуры одним элементом HTML.

Квадрат

#square {
	width: 100px;
	height: 100px;
	background: red;
}

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

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

Суть методики

Методика включает в себя 22 показателя, напрямую влияющий на продажи. Каждый имеет свой вес (балл), в итоге они дают количество баллов, где максимум 100. Факторы включены только те, что можно оценить снаружи сайта без изучения внутренних данных. Оценка происходит визуально человеком, в данном случае мной. Методика создана как универсальная, подходит для интернет-магазина товаров (не услуг), вне зависимости от его тематики, ассортимента и объема продаж.