В 2017м году я начал писать проект на nodejs — реализацию протокола ObjectServer от Weinzierl для доступа к значениям KNX. В процессе написания было изучено: работа с бинарными протоколами, представление данных, работа с сокетами(unix sockets в частности), работа с redis базой данных и pub/sub каналами.

Проект достиг стабильной версии. В это время я потихоньку ковыряю другие языки, в частности Dart и Flutter как его приложение. На полке пылится без действия купленный во времена студенчества справочник Г.Шилдта.

Настойчивая мысль переписать проект на C поселилась в голове. Рассматриваю варианты Go, Rust, отталкивающие иными синтаксическими конструкциями. Начать никак не получается, идея откладывается на время.

Раньше облака в играх рисовались обычными 2D спрайтами, которые всегда повернуты в направлении камеры, но последние годы новые модели видеокарт позволяют рисовать физически корректные облака без заметных потерь в производительности. Считается, что объемные облака в игры принесла студия Guerrilla Games вместе с игрой Horizon Zero Dawn. Конечно, такие облака умели рендерить и раньше, но студия сформировала что-то вроде промышленного стандарта на исходные ресурсы и используемые алгоритмы, и в настоящее время любая реализация объемных облаков так или иначе этому стандарту соответствует.

UPD. Картинка обновлена. Изменения описаны в конце статьи.

В некоторых сферах программирования нормально хотеть написать такую структуру данных или алгоритм, которые могут работать с элементами разных типов. Например, список дженериков или алгоритм сортировки, которому нужна только функция сравнения. В разных языках предложены всевозможные способы решения этой задачи: от простого указания программистам на подходящие общие функции (С, Go) до таких мощных систем дженериков, что они стали полными по Тьюрингу (Rust, C++). В этой статье я расскажу о системах дженериков из разных языков и их реализации. Начну с решения задачи в языках без подобной системы (вроде С), а затем покажу, как постепенное добавление расширений приводит к системам из других языков.

От переводчика:
Представляю вашему вниманию статью авторства Andy Gainey, в прошлом независимого разработчика игровых инструментов, ныне сотрудника Paradox Development Studio. На мой взгляд, автор играючи создал один из лучших процедурных генераторов планет с открытым исходным кодом.

Генерация уровней в Unexplored 2

Мы очень гордимся генератором уровней игры Unexplored 2, это программа, отвечающая всем современным требованиям. В посте я расскажу о том, как создаются уровни игры.

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

Имитация «человеческого» дизайна уровней

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

Небольшой рассказ о граблях, встреченных на пути познания ARM на примере stm32f103c8t6 и stm32l151rct6.

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

Сама по себе способность есть ни что иное, как набор действий. Минимальный интерфейс способности состоит из одного метода: «применить», но не всё так просто и о сложностях под катом.

«Мы начинаем разработку новой игры, и нам нужна классная вода. Такую сможешь?»


, — cпросили меня. «Да не вопрос! Конечно, смогу», — ответил я, но голос предательски задрожал. «А, еще и на Unity?», — и мне стало понятно, что впереди очень много работы.

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

— А. Стругацкий, Б. Стругацкий «Пикник на обочине»

Привет, %username%!

В том, что я всё ещё что-то пишу — вините вот этого человека. Он навеял идею.

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

Поехали.

Отгремели выстрелы минувшего Ludum Dare 44, но тяга делать игры, оттачивать свое мастерство ещё не покидает меня, да и думаю многих. Проглядывая главную страницу онлайн-мероприятия, я наткнулся на интереснейший пост, где автор задался вопросом составления инструментария, помогающего разработчикам (командам) создавать свои игровые шедевры. В статье автор задался целью собрать в один список набор инструментов, псевдо-случайным образом генерирующих различные ресурсы для вашей игры, начиная от фиксированной палитры цветов, заканчивая простейшей chiptune-like фоновой музыкой и спрайтами персонажей.

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

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

Pixi.js позволяет использовать мощь WebGL для рендеринга 2D-сцен, совершенно не вникая в подробности реализации, более того, он умеет самостоятельно определять наличие поддержки WebGL и переключаться между способами рендеринга. В отсутствие WebGL рендеринг осуществляется средствами canvas. Кроме того в Pixi.js реализован граф сцены, поддержка текстур и спрайтов, чуть больше недели назад в нём появилась поддержка интерактивности — на спрайты можно повесить обработчики событий мыши и тачскрина.

Искажения, бесшовный шум и как с ними работать.

Генерируем планету

Один из простейших способов генерации планеты — использование шума. Если мы решим выбрать его, то у нас есть пара возможных вариантов. Давайте рассмотрим каждый и определим лучший:

• Шум Перлина (Perlin Noise) — самый простой вариант. Шум Перлина был разработан Кеном Перлином в 1983 году, он имеет пару недостатков — визуальные артефакты и довольно низкая по сравнению с другими вариантами скорость при генерации больших изображений.
• Симплекс-шум (Simplex Noise) — разработан Кеном Перлином в 2001 году как попытка устранения недостатков шума Перлина; это вполне достойное и быстрое решение, однако обладающее серьёзным недостатком: использование трёхмерного симплекс-шума защищено патентом, что делает его довольно дорогостоящим.
• Открытый симплекс-шум (Open Simplex Noise) — был разработан KDotJPG с одной простой целью: создать современную и бесплатную версию симплекс-шума, относительно быструю и без искажений.

Из этих трёх лично я предпочитаю Open Simplex Noise, который использую в своих личных проектах. Стоит заметить, что в текущей реализации OpenSimplexNoise для получения простого доступа к масштабу, октавам и порождающим значениям потребуется дополнительная работа. В Интернете есть множество информации о том, что делает каждый из этих элементов, и я крайне рекомендую вам её изучить. Однако в своей статье я буду говорить не об этом.

12 апреля мы собираемся запустить стратосферный зонд с небольшим сервером, откуда на CDN внизу будет передаваться наша страница. Входящий канал — низкоорбитальные спутники связи, исходящий — радиопоток на частотах любительского диапазона (телеметрия и управление) и Wi-Fi (видео и данные).

Проблема с запуском в том, что это неуправляемый летательный аппарат. В смысле, это просто шар с гелием, к которому прицеплено несколько килограммов железа. И это важно, потому что это железо может стукнуться о чей-нибудь самолёт или упасть на чью-нибудь территорию. Муниципалитетам, например, не очень нравится, когда на территорию его объектов такое падает. Заповедникам тоже. А Росатому уж вообще очень не нравится.

На борту будет камера, то есть это получится аэрофотосъёмка. Разрешение на неё надо получать у Федеральной службы безопасности.

Это пиковый полёт, то есть мы поднимаемся до рабочей высоты, быстро выполняем миссию и спускаемся на посадку. Зонд обычно уносит на 100-150 километров от точки старта по направлению ветра, дующего на высоте от земли до 30 километров. Выше 20 км как правило пропадает турбулентность, да и плотность воздуха там в 100 раз меньше (на съёмке видно характерную границу атмосферы), поэтому полёт там становится более плавным. Лететь мы можем хоть до Владивостока, но чем больше траектория тем сложнее получить официальное согласование полёта, что заставляет нас максимально сокращать полёт.

Подготовили перевод следующей части многосерийной статьи, где сравнивается функциональность Apache Kafka и RabbitMQ. В этой публикации речь идёт о семантике и гарантии доставки сообщений. Обращаем ваше внимание, что автор учитывал Кафку до версии 0.10 включительно, а в версии 0.11 появился exactly-once. Тем не менее, статья остаётся актуальной и полна полезных с практической точки зрения моментов.
Предыдущие части: первая, вторая.

Вчера Mozilla довела до финальной версии один из своих экспериментальных проектов Firefox Send: простой и безопасный сервис обмена зашифрованными файлами. Поддерживаются файлы до 1 ГБ (до 2,5 ГБ после авторизации в Firefox Account).

Сервис выглядит просто, но под ним работает движок, который обеспечивает настоящее end-to-end шифрование, то есть вы никуда не передаёте файлы в открытом виде — они шифруются конкретно на вашем ПК, а расшифровываются на компьютере получателя (JS в браузере). Как это работает, можно посмотреть на примере Firefox Sync, здесь реализована похожая архитектура.

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

Нуль-блоки не надо хранить на диске. Благодаря sparse флагу, операционная система просто помечает этот участок файла как заполненный нулями и не хранит эти нули на диске.

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

Откуда берутся нуль-блоки в файле

1. Раздающий не дождался полного скачивания и проверки файла и выложил неполный(partial) файл.
2. Результат повреждения сектора диска раздающего.

Это те варианты, которые пришли в голову.

Почему эти файлы продолжают распространяться

1. Видео/аудио файл может иметь нуль-блок в середине и спокойно воспроизводится, просто перескакивая то место, где попался нуль-блок. Тем самым он может казаться целым.
2. Образ диска также может иметь нуль-блоки в разных местах и это проявит себя только при попытке чтения файлов из этих блоков.

Расскажу, как нам удалось написать линтер, который получился достаточно быстрым, чтобы проверять изменения во время каждого git push и делать это за 5−10 секунд при кодовой базе в 5 миллионов строк на PHP. Мы назвали его NoVerify.

NoVerify поддерживает базовые вещи вроде перехода к определению и поиску использований и умеет работать в режиме Language Server. В первую очередь наш инструмент ориентирован на поиск потенциальных ошибок, но умеет проверять и стилистику. Сегодня его исходные коды появились в open-source на GitHub. Ищите ссылку в конце статьи.

В течение последних месяцев я исследовал несколько разных игр, в том числе «Uncharted 4» и «The Last of Us» (разработанные Naughty Dog).

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

1 — Введение: что такое level flow

Моё определение термина:

«Когда игрок знает, что делать и куда идти, но не всегда знает, как достичь этого и двигаться по направлению к цели».

(Ключевое слово: восприятие пространства)

Это состояние, в котором игрок испытывает удовольствие, перемещаясь по уровню. Оно рука об руку идёт с game flow.

Это определение довольно размытое, потому что level flow — это широкая тема. Для простоты я разделю «level flow» на четыре (4) более мелких элемента. С высокоуровневой точки зрения, это элементы, которые дизайнеры уровней используют, чтобы направлять игроков.

Наверно худшее, что случилось в области процедурной генерации контента (если считать, что это действительно область процедурной генерации контента, в чём я уверен не полностью) — это шум Перлина. Шум Перлина невероятно хорошо подходит (по крайней мере, если не приглядываться слишком внимательно) для генерации интересных ландшафтов. В сабреддите /r/proceduralgeneration недели не проходит без того, чтобы кто-нибудь не опубликовал «систему процедурной генерации», которая оказывается визуализированным разными цветами шумом Перлина. (За время написания этой статьи появилось два таких поста!)


Я не хочу унизить шум Перлина. Это невероятно полезный для процедурной генерации инструмент, ставший точкой входа в эту область для множества людей, в том числе и меня. Но в то же время он очень сбивает с толку, потому что подразумевает, что процедурная генерация намного проще, чем это есть на самом деле. Большинство еженедельных постов о «системах процедурной генерации» в /r/proceduralgeneration исчезают без следа, когда их авторы обнаруживают, что следующий шаг в процедурной генерации гораздо сложнее. Истина в том, что шум Перлина стал своего рода счастливой случайностью. Он отлично подходит для генерации интересных ландшафтов, но на то нет систематических или повторяемых причин.