WebGL *

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

Очередные «попугаи»?! О, нет. Три реальных теста, три разных направления, различные устройства и интересные факты.

Three JS Editor — еще минималистичный, но очень полезный редактор 3D графики, на основе WebGL и библиотеки ThreeJS.
Three.js — легковесная кросс-браузерная библиотека JavaScript, используемая для создания и отображения анимированной компьютерной 3D графики при разработке веб-приложений.


Кликабельно

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

В 2014 году 2ГИС выпустил Этажи — это фича, позволяющая посмотреть схему этажей здания и найти на ней нужную организацию. Долгое время она существовала только в мобильных приложениях 2ГИС. Теперь эта возможность появилась и в онлайн-версии.

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

Не так давно в Unity вышла из беты возможность создания проектов для WebGL. Делюсь своим опытом сборки под эту платформу большого игрового проекта.

Disclaimer: Статья только для тех, кто сам собирается сделать что-то подобное — она очень техническая и использует специфическую для Unity терминологию.

Как-то утром, пробегая мимо славного урока, я подумал: «Это круто, только всё же кой-чего тут не хватает». Если надо много кода написать легко и быстро, то нужна нам, без сомнений, для сего библиотека. Только как её нам выбрать, если каждый, кто умеет на гитхабе заводить репозиторий, запилил велосипед свой? И об этом для тебя, друг, напишу сегодня пост вдруг.

WebGL — одна из самых интересных новых технологий, которая способна удивительным образом преобразовать интернет. На базе этой технологии уже создано несколько движков, которые позволяют без лишних усилий создавать удивительные вещи, и наиболее известный из них Three.js. Познакомится с ним было моим давним желанием, и лучший способ сделать это — создать что-нибудь интересное. Первой идей было набросать “воодушевляющую” сцену на Three.js содержащую как большое количество полигонов, источников освещения и частиц, так и имеющую, при этом, какой-то осмысленный контекст. Вскоре, эта идея превратилась в желание создать бесконечный город в который можно было бы погрузиться сквозь браузер.

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

Иногда я считаю себя первопроходцем, открывающим новые страницы использования Blend4Web. Это молодой движок, с энергичной командой разработчиков, богатыми возможностями и множеством не очень хорошо документированных функций. Что-то я черпаю из исходников большого количества демо, дергаю разработчиков по всяким вопросам, а чаще всего действую методом “научного тыка”. В этой статье я хочу поделиться своими наработками по созданию пользовательского интерфейса для приложения. И что важно, с помощью Blend4Web и HTML5 можно сделать вполне приличный игровой GUI.

В этом материале постарался описать создание браузерного 3D-шутера, начиная от импорта симпатичных моделей танков на сцену и заканчивая синхронизацией игроков и ботов между собой с помощью websocket и asyncio и балансировкой их по комнатам.

Введение
1. Структура игры
2. Импорт моделей и blender
3. Подгрузка моделей в игре с babylon.js и сами модели
4. Передвижения, миникарта и звуки игры в babylon.js
5. Вебсокеты и синхронизация игры
6. Игроки и их координация
7. Балансировка игроков по комнатам и объектный питон
8. Asyncio и генерация поведения бота
9. Nginx и проксирование сокетов
10. Асинхронное кэширование через memcache
11. Послесловие и RoadMap

Всех кому интересна тема асинхронных приложений в Python3, WebGL и просто игр, прошу под кат.

В августе прошлого года я обратил внимание на интересный WebGL-движок для разработки своих браузерных проектов. Меня подкупила его тесная интеграция с Blender и русская команда разработчиков. И вот совсем недавно на официальном сайте появился своеобразный отчет о прошедшем годе и планах на будущее. Я подумал, а почему бы и мне не высказаться на это тему, но с точки зрения своего опыта и времени работы с этим фреймворком. На хабре уже есть немало обучающих статей написанных мною о Blend4Web. Помимо всего прочего я рассказывал и о текущих проблемах. Теперь я хочу суммировать накопленные положительные и отрицательные оценки в нечто целое. Учтите, что это только личное мнение.

Разрабатывая игру, приходится идти на всевозможные ухищрения для повышения производительности. В самом деле, если сцена будет притормаживать при каждом выстреле или генерации врагов, то пользователь может махнуть рукой и найти более шуструю игру (благо рынок ими сейчас перегружен). «Узких мест» в игровом приложении немало, но я хотел бы рассказать про оптимизацию именно со стороны кода.

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

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

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

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

В предверии ажиотажа вокруг 7-го эпизода Звездных Войн, Google запустил специальный тематический раздел на своем сайте www.google.com/starwars.

Особое внимание привлекает браузерная аркада Побег Джедая (eng. Lightsaber Escape), запущенная в рамках Chrome Experience.

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

В этой статье я расскажу о том, как своими руками, имея только блокнот и любой веб-сервер, сделать шейдерные 2D-тени на WebGL. Все шаги лежат на гитхабе как ветки и переключаются git checkout stepN, так что добро пожаловать даже тем, кто не настроен кодить.

КДПВ:

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

Из закона всемирного тяготения известно, что на поверхности тел шарообразной формы ускорение свободного падения постоянно по модулю и направлено к центру шара. Для тел неправильной формы это правило, очевидно, не выполняется. В этой статье я покажу способ расчёта и визуализации ускорения свободного падения для таких тел. Расчёт будем производить на JavaScript, визуализировать — на WebGL с использованием библиотеки three.js.

В итоге получим следующее (красным цветом отмечены области с большим ускорением свободного падения, синим — с малым):

Даже самый примитивный игровой персонаж должен обладать хоть какими-нибудь “мозгами”. Рыбки априори не блещут интеллектом, но кое-что они все же должны уметь — передвигаться, “смотреть”, убегать или нападать. От них не требуется искать укрытия или “морщить лоб” для умной ответной фразы. Выглядит просто, но легко ли сделать?

Разговор пойдет о реализации AI силами JavaScript и Blend4Web. Поставленные задачи, способы их решения или вынужденные пути обхода — все это на примере разрабатываемого живого, игрового проекта.

На сайте разработчиков движка опубликовано множество материалов, в том числе и по этой теме. Все «разжевано» и на русском языке. Но вот казус — задача оказалась не простой, даже для человека имеющего солидный опыт работы с Blender и искренне считающего себя game developer`ом. Некоторые этапы вызывали критические приступы “зависания”, происходящих от недопонимания особенностей работы с движком и, откровенно говоря, слабого знания JavaScript.

Немаловажным фактором была попытка переноса опыта работы с Unity (c#) на абсолютно иную платформу. И это было серьезной ошибкой. Blend4Web — инструмент заточенный исключительно для создания приложений WebGL, что дает солидное преимущество перед кроссплатформенным Unity, но и накладывает некоторые ограничения. В связи с прекращением поддержки веб-плеера и слабой работоспособностью экспортера Unity WebGL, платформа Blend4Web выглядит очень интересной. Поэтому, хочешь — не хочешь, а разбираться приходится.

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

Запаситесь попкорном — я поведаю вам интересную историю… В общем, это будет одно из тысячи сочинений на тему «Как я написал свою игру». Сначала я планировал осветить как можно больше технических деталей, но потом понял, что их слишком много для одной статьи и она получится огромной. Поэтому «первая серия» будет, скорее, обзорной. Если будет интересно, то продолжу. Итак.