GenJam 2016

19 ноября 2016 года в Сан-Франциско прошёл первый ежегодный Gen Jam (геймджем по процедурной генерации). Идея была в том, чтобы за субботу создать генератор графики, «объект, создающий объекты», если вам угодно.

Я создал программу, рисующую спрайты персонажей в удивительном стиле набора 16-битных спрайтов Кристофера «Oryx» Барретта из Oryx Design Lab. Посмотрите на примеры того, что делает программа:

Иногда этот метод называют «крестьянское умножение», иногда «древнеегипетское», иногда «эфиопское», иногда «умножение через удвоение и деление пополам». Некоторым он хорошо известен, некоторым – непонятен, но при этом он достаточно полезен и может использоваться не только для умножения, но и для возведения в степень и расчётов матриц.

Алгоритм

  13  x  19 ->     0
   6     38       19
   3     76 ->
   1    152 ->    95
   0    304      247
                 ^^^

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

Если число в левом столбце нечётное, мы добавляем число из правого столбца в нарастающую сумму. Изначально она будет равна нулю.

Затем в левом столбце ниже мы записываем число из заголовка, делённое пополам (с отбрасыванием остатка). 13 / 2 = 6. А во втором столбце мы пишем число, равное удвоению заголовка столбца, 19*2 = 38.

Поскольку число в левом столбце чётное, мы не увеличиваем нарастающую сумму.

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

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

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

• Интересной.
• С простым порогом входа.
• Реалистичной для задач погружения.

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

Внимание, ниже немного спойлеров и много скриншотов (трафик).

Мы постоянно работаем над тем, чтобы IaaS был простым и понятным даже для тех, кто не сталкивался с ИТ-сферой. Для этого мы проводим оптимизацию всех систем и рассказываем о своем опыте в нашем блоге на Хабре.

Пара примеров:

• «Удобный хостинг»: Предустановка панели управления и дозаказ лицензий на лету
• Как работает API нашего IaaS-провайдера
• Как мы разработали свой DNS-менеджер

Сегодня мы поговорим о том, как ускорить загрузку страниц, и взглянем на советы эксперта по Ruby Нейта Беркопеца (Nate Berkopec).

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

Например, мы захотели создать незатейливую RPGMMO-шечку «убийцу WoW», и у нас уже почти все готово. Мы уже нафантазировали, какая в игре будет крутая механика боя и система умений. Дело осталось за малым – абстрактные мысли превратить в конкретные значения. Причем, каким-то образом, сочетание этих значений должно убедить игрока в том, что фраза «баланс – говно» — это не про нас.

Допустим, я создал браузерную игру, а что дальше? Если для мобильных — есть магазины Google Play, App Store, Windows Store и куча всяких альтернативных. Можно найти площадки для распространения сборок standalone — Desura, Steam, Itch.io. Но когда задумываешься о судьбе браузерки, то невольно впадаешь в ступор. И куда ее?

Думать о судьбе своего детища необходимо еще на начальном этапе разработки. Так, в случае с Dangerous Insects, я уже знал, где и как буду размещаться, хотя от игры в лучшем случае был только диздок. Вот и с HTML5 захотелось заранее прощупать почву.

IndexedDB – стандарт хранения больших объемов структурированных данных на клиенте – был ожидаем также как и WebSocket (ну может самую малость меньше). В свете выхода FireFox 4 я нашёл время и силы всё-таки разобраться, как им пользоваться, и попытаться написать что-то больше, чем пример с адресной книгой, гуляющий по интернетам (в процессе поиска информации у меня сложилось впечатление, что это был единственный пример).

Уже около полугода я пишу на ES6 (который в итоге назвали ES-2015) и ES7, с использованием бабеля в качестве транслятора. Писать мне приходилось в основном серверную часть, соответственно, использование модулей было само собой разумеющимся: до ES6 — с помощью модульной системы самой ноды, а теперь — с помощью стандартизированной семантики самого языка. И мне захотелось написать статью, в которой расписать тонкости, плюсы, подводные камни и необычности новообретенной модульной системы языка: отчасти — чтобы другим было проще, отчасти — чтобы разобраться во всём окончательно самому.

Я разберу, что такое модуль, как происходит экспорт сущностей, как происходит импорт сущностей, чем система модулей ES6 отличается от системы модулей в NodeJS.

Сегодня речь пойдет о том, как создать игру не используя js и прочих скриптов. Только HTML / CSS, только хейткор.

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

Идея сделать браузерный синтезатор у меня появилась достаточно давно, ещё когда Audio API был в весьма зачаточном состоянии и практически единственным шансом извлечь звук из браузера (кроме воспроизведения готовых файлов) была генерация WAV с его последующей кодировкой в base64 и записью в аудио-тег. И если синтез и кодирование удавались без проблем (WAV формат довольно прост), то с потоковым аудио для музицирования в реальном времени всё было хуже и никакими ухищрениями не удавалось добиться бесшовной буферизации, в связи с чем идея и заглохла, так не успев родиться. За прошедшие годы браузеры в поддержке Audio API заметно прибавили, что в свою очередь вдохновило меня на новые эксперименты в этой области. В данной статье шаг за шагом описывается процесс создания браузерного синтезатора средствами HTML5, начиная с генерации простой синусоиды, продолжая коммутацией и модуляцией сигналов и заканчивая аудиоэффектами.

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

Смотрите видео и под кат.

Последнее время почти в любом проекте требуется сделать сборку less/sass/css/js/html и т.д. файлов. Gulp является отличным решением для выполнения этих задач, это глоток воздуха после grunt'a, но и он не идеален.



Например, если нужно сделать сборку common js, используя browserify, то нужно подключать с десяток зависимостей и писать почти 50 строчек кода. Вот один из примеров.

Нужно упрощать gulpfile.js

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

Нравится мне Chrome, но надоело мне что он скрипит винчестером так как будто они не ломаются. Решил я его отучить это делать. Получилось, теперь делюсь рецептурой.

Зачем? Во-первых, винчестер — не железный, в смысле — железный, конечно, но ломаться умеет и чем больше его долбят — тем быстрее ломается (как я понял на собственном опыте, когда потерял все данные); во-вторых, Хром очень много всякого барахла хранит в базах данных, которые почти не используют память компа, в результате через месяц использования даже набор адреса становится пыткой — винчестер скрипит, буквы по секунде набираются. Все эти проблемы убираются.

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

Предпосылки и философские размышления

Как и у многих моих коллег по программистскому цеху, особенно у тех, кто рано начал пробовать свои силы в области компьютерных технологий, у меня где-то на задворках сознания хранится набор самых тёплых и романтических воспоминаний о первых опытах. Когда-то, в далёком 1987 году, отец впервые взял меня в выходной к себе на работу, где торжественно усадил на стул перед гудящей «Искрой-1030-11». Примерно тогда я твёрдо понял, чем хочу заниматься в своей дальнейшей жизни.

Как известно, существует три вида алгоритмов: линейные, разветвленные и циклические:



Основой всего, что сделано в методологии программирования, включая и объектное программирование стало структурное программирование, предложенное Эдсгером Дейкстрой в 1970-х годах. Одной из основных идей было введение блочных операторов ветвления (IF, THEN, ELSE) и цикличности (WHILE, FOR, DO, UNTIL и др.) вместо проблемного оператора GOTO, который приводил к получению запутанного, неудобочитаемого «спагетти-кода».

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

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

Привет!

Отгремели фанфары, прошел звон в ушах от истязаний «евангелистов», модников в сфере фронтенд разработки. Кто-то ушел на sprockets, кто-то пустился во все тяжкие и стал писать свои велосипеды или расширять функционал gulp или grunt. Но статей по поводу популярных инструментов автоматизации процесса сборки – стало существенно меньше и это факт! Пора бы заполнить освободившееся пространство чем-то существенно иным.

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

Здравствуйте, любители нашего хаброблога и прочие читатели!

Мы планируем вновь отметиться на поле неувядающего Node.js и рассматриваем возможность издания этой книги:



Поскольку вполне понятен читательский интерес «а как он впихнул все это в двести страниц, и зачем мне это нужно»? под катом предлагаем перевод доскональной статьи Томислава Капана о том, зачем на самом деле нужен Node.js.