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

Еще пару лет назад, когда к нам приходили запросы от пользователей на разработку чего-то новенького (не входящего в генеральный план развития продукта), мы долго прогнозировали сроки, оценивали универсальность и востребованность функции у широкого круга пользователей. И часто либо отказывали, либо оценивали сроки реализации как очень долгие. Но однажды нам пришел запрос для крупного проекта. В случае успешной и быстрой реализации недостающей пользователю функции, перспективы и масштабы внедрения Macroscop были очень хорошими. И мы взялись попробовать! У нас были жесткие временные рамки, отзывчивый и готовый помогать пользователь и полная свобода действий.

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

Посмотрите на сцену из игры 2010 года Mass Effect 2 с раздевающимся Джейкобом. На первый взгляд кажется, что он стянул рубашку, как это сделал бы любой человек, демонстрируя невидимому оператору заработанные в боях кубики пресса. А теперь приглядитесь внимательно: к моменту, когда его руки движутся по телу, «снимая» рубашку, её уже нет. Игра переключилась с одетой на раздетую модель с помощью иллюзии, заставляющей игрока подумать, что он снимает рубашку.

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

Сейчас я постараюсь рассказать об этом вам, максимально всё упростив.

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

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

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

Введение

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

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

Что же такое «игровой ИИ»?

Игровой ИИ в основном занимается выбором действий сущности в зависимости от текущих условий. В традиционной литературе по ИИ называет это управлением "интеллектуальными агентами". Агентом обычно является персонаж игры, но это может быть и машина, робот или даже нечто более абстрактное — целая группа сущностей, страна или цивилизация. В любом случае это объект, следящий за своим окружением, принимающий на основании него решения и действующий в соответствии с этими решениями. Иногда это называют циклом «восприятие-мышление-действие» (Sense/Think/Act):

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

До недавнего времени трава в играх обычно обозначалась текстурой на земле, а не рендерингом отдельных стеблей. Но с увеличением мощности железа появилась возможность рендерить траву. Замечательные примеры такого рендеринга можно увидеть в играх наподобие Horizon Zero Dawn и The Legend of Zelda: Breath of the Wild. В этих играх игрок может бродить по травяным лугам, и, что более важно, трава реагирует на действия игрока.

К счастью, создать такую систему не очень сложно. На самом деле, статья научит вас именно этому! В этом туториале вы научитесь следующему:

• Создавать векторное поле с помощью захвата сцены (scene capture) и системы частиц
• Сгибать траву от игрока на основании векторного поля

Самое большое препятствие улучшения образования для детей (с компьютерами или без них) — это совершенно обедневшее воображение большинства взрослых.
— Алан Кей

Откопал статью Алана Кея 2009 года. Содержание — бомба и напалм, особенно на фоне большинства сегодняшних ИБД в области образования.

Вопрос: Вы часто говорите, что компьютерная революция еще не произошла. Что вы имеете в виду?

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

Большинство школ определяют компьютерную грамотность как умение использовать Microsoft Office и, возможно, немного заниматься веб-дизайном. Они упускают суть. Это все равно что сказать: «Если вы знаете, за какой конец книги нужно держаться, и вы знаете, как перейти к третьей главе, тогда вы грамотны».

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

Создатель Papers, Please Лукас Поуп работает над новым трёхмерным проектом Return of the Obra Dinn, в котором пытается с помощью эффекта дизеринга воссоздать в игре ощущение старинной книги.

Для начала краткое объяснение: Obra Dinn выполняет внутренний рендеринг всего в 8-битной палитре в градациях серого, а затем на этапе постобработки преобразует конечные выходные данные в 1-битные значения. Преобразование из 8-битного в 1-битный цвет выполняется сравнением каждого пикселя исходного изображения с соответствующей точкой в тайловом паттерне дизеринга. Если значение пикселя изображения больше значения точки паттерна дизеринга, то выходному биту присваивается значение 1, в противном случае оно равно 0. Выходные данные упрощаются до 1-битных значений, а глаз зрителя объединяет пиксели, аппроксимируя из них больше битов.

Псевдотонирование: обзор

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

На самом деле псевдотонирование по-прежнему остаётся уникальным методом не только по практическим соображениям (например, подготовка полноцветного изображения для печати на чёрно-белом принтере), но и по художественным. Дизеринг также находит применение в веб-дизайне, где этот полезный метод используется для сокращения числа цветов изображения, что уменьшает размер файла (и трафик) без ущерба для качества. Он также используется при уменьшении цифровых фотографий в формате RAW в 48 или 64 бита на пиксель до RGB в 24 бита на пиксель для редактирования.

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

В последнее время я читал статьи о лучших практиках code review и заметил, что эти статьи фокусируются на поиске багов, практически игнорируя другие компоненты ревью. Конструктивное и профессиональное обсуждение обнаруженных проблем? Неважно! Просто найди все баги, а дальше само сложится.

Так что у меня случилось откровение: если это работает для кода, то почему не будет работать в романтичных отношениях? Итак, встречайте новую электронную книгу, которая поможет программистам в отношениях со своими возлюбленными (обложка на иллюстрации слева).

Моя революционная книга обучит вас проверенным техникам по выявлению максимального количества недостатков в своём партнёре. Книга не затрагивает следующие области:

• Обсуждение проблем с сочувствием и пониманием.
• Помощь партнёру в устранении недостатков.

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

Как вам нравится такая книжка? Предполагаю, что она вам не очень по душе.

Я поискал по хабру перевод уроков с этого сайта, но нашлось только одно упоминание, да и то — в комментариях:



Потому и решил исправить положение, попытался дополнить и разнообразить примеры своими наработками, а заодно попрактиковался в переводе. Также, поскольку моей любимой ОС сначала была WinXP а теперь Ubuntu, постараюсь сделать кроссплатформенные примеры, захватив как можно больше нюансов настройки для этих платформ. В данной серии уроков рассматривается создание фрэймфорка, достаточного для начала разработки 2D игр.
Что из этого получилось

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

Дальше много картинок, gif-анимации и немного музыки.

То, что начиналось как приключение, закончилось одиссеей.

Задача по созданию тетрис-процессора размером 2 940 928 x 10 295 296

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

• PhiNotPi
• El'endia Starman
• K Zhang
• Muddyfish
• Kritixi Lithos
• Mego
• Quartata

Также мы хотим поблагодарить 7H3_H4CK3R, Conor O'Brien и многих других пользователей, вложивших свои труд в решение этой задачи.

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

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

Различные реализации игры «Жизнь» описывались на Хабре уже неоднократно. В этой статье, в качестве продолжения этой темы, рассматривается ещё один её вариант: в качестве игрового поля используется регулярная решётка на плоскости Лобаческого. Описываются общие методы использования плоскости Лобачевского в программах и необходимые для этого математические приёмы.
Как возникла плоскость Лобачевского, достаточно известно. В позапрошлом веке господа Гаусс, Лобачевский и Бойяи, проживавшие примерно в одно время в разных странах тогдашней Европы, задумались, что будет, если отменить пятый постулат Евклида и заменить его на противоположную аксиому. Оказалось, что не случится ничего плохого, и никаких противоречий не возникнет. Заметная часть последующего изучения неевклидовой геометрии была посвящена выяснению того, кто из них у кого украл идею этой самой геометрии.
Менее известно, что несмотря на «отрицательный» способ определения неевклидовой геометрии (вместо того, чтобы сказать, что через точку проходит ровно одна прямая, не пересекающая данную, мы говорим, что таких прямых может быть сколько угодно), мы, тем не менее, получаем систему теорем и формул, не менее стройную, чем та, что есть в евклидовой геометрии. И одновременно, у нас есть гораздо большее разнообразие геометрических фигур, в том числе, разбиений плоскости на правильные многоугольники.

Мы всё-таки смогли дойти до третьей части и добрались до самого интересного — организации асинхронных вычислений.

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

Теперь посмотрим, как можно управлять потоком исполнения (control flow) в случае обработки асинхронных задач.

• Параллелизм (часть 1)
  
  
  • Потоки: scheduling, сон
  • Синхронизация: Spinlock, семафоры, барьеры памяти
  • Атомарность: TAS, CAS
  
  
• Кооперативность (часть 2)
  
  
  • Корутины (coroutines)
  • Акторы
  
  
• Асинхронность (часть 3, текущая)
  
  
  • Event loop
    • select
  • Callbacks
  • Async Monad
  • Промисы (promises, обещания)
  • async/await — промисы + корутины
  
  

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

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

В этой мы посмотрим на ещё две модели, одна из которых не делает такого вида, а вторая смотрит на конкурентные вычисления с более абстрактной стороны.

• Параллелизм (часть 1)
  
  • Потоки: scheduling, сон
  • Синхронизация: Spinlock, семафоры, барьеры памяти
  • Атомарность: TAS, CAS
  
  
• Кооперативность (часть 2, текущая)
  
  • Корутины (coroutines)
  • Акторы
  
  
• Асинхронность (часть 3)
  
  • Event loop
    • select
  • Callbacks
  • Async Monad
  • Промисы (promises, обещания)
  • async/await — промисы + корутины
  
  

Привет, Хабр! Представляю вашему вниманию перевод статьи Substitution Processes (1962 год) авторства Эдсгера Дейкстры. Разделение на параграфы не оригинальное.

Введение

Машина определяет (по самой своей структуре) язык, а именно: свой язык ввода — и напротив, семантическое определение языка задаёт машину, способную понимать его. Другими словами, машина и язык — это две стороны одной и той же медали. Я собираюсь описать такую медаль. Я оставляю на вас решение того, какой же из этих двух аспектов предмета моего разговора, на ваш взгляд, самый важный, так как сам считаю этот выбор довольно смешным. Язык, наброски которого я собираюсь вам предоставить, является непозволительно трудным для человека, а машина, которую я собираюсь описать, является порочно неэффективной.

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

^{Длинный материал. Время чтения – около 40 минут.}



Доктор Ричард Хэмминг, профессор морской школы Монтерея в штате Калифорния и отставной учёный Bell Labs, прочёл 7 марта 1986 года очень интересную и стимулирующую лекцию «Вы и ваши исследования» переполненной аудитории примерно из 200 сотрудников и гостей Bellcore на семинаре в серии коллоквиумов в Bell Communications Research. Эта лекция описывает наблюдения Хэмминга в части вопроса «Почему так мало учёных делают значительный вклад в науку и так многие оказываются в долгосрочной перспективе забыты?». В течение своей более чем сорокалетней карьеры, тридцать лет которой прошли в Bell Laboratories, он сделал ряд прямых наблюдений, задавал учёным очень острые вопросы о том, что, как, откуда, почему они делали и что они делали, изучал жизни великих учёных и великие достижения, и вёл интроспекцию и изучал теории креативности. Эта лекция о том, что он узнал о свойствах отдельных учёных, их способностях, чертах, привычках работы, мироощущении и философии.

Под катом перевод статьи Carsten Sørensen «This is not an article — just some food for thoughts on how to write one». В ней рассказывается на что нужно обращать внимание при написании научных статей. Если вы пишите диссертацию в области информационных технологий, то наверняка найдете что-то интересное для себя. Впрочем, и авторы популярных статей тоже могут найти что-то полезное.

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

«Пусть тахорги в страхе воют,
Издавая визг и писк!
Ведь на них идет войною
Структуральнейший лингвист!»

• Очень жесткий правдоруб.
• Мог бы стать физиком-теоретиком (как Ричард Фейнман, который тоже родился 11 мая), но выбрал несуществующую на тот момент профессию — программист.
• Носит имя алгоритма поиска кратчайшего пути. Алгоритм был создан при решении железячной задачи «О нахождении оптимального пути передачи электрического тока всем существенным элементам цепи, минимизируя при этом расход меди».
• Непримиримый враг goto.
• Инициатор мема Considered harmful. «GOTO Statement Considered Harmful», "„GOTO Considered Harmful“ Considered Harmful", «„«GOTO Considered Harmful» Considered Harmful“ Considered Harmful?»
• Автор концепции семафора.
• Разработчик операционной системы THE (Technische Hogeschool Eindhoven).
• Стоял у истоков структурного программирования и распределенных вычислений.
• Не написал ни одной статьи на компьютере.

В обычной жизни Э.В.Дейкстра был чудаком: предпочитал простую ручку компьютеру, в его доме не было телевизора, он не пользовался мобильным телефоном, не смотрел кино. Когда его коллеги подготовили и издали к 60-летнему юбилею специальный сборник, Дейкстра ответил каждому из них личным благодарственным письмом, написанным от руки (61 адресат). Ученому его уровня и положения полагался секретарь, но Дейкстра отказался от этой привилегии и все предпочитал делать сам. Любил музыку и был хорошим пианистом.

Под катом несколько цитат Дейкстры, пара сокращенных эссе и список статей на русском языке.