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

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


2D Свёрточная нейронная сеть

К написанию статьи меня подтолкнула вот эта новость (+исследование) про изобретение генератора мемов учеными из Стэнфордского университета. В своей статье я попытаюсь показать, что вам не нужно быть ученым из Стэнфорда, чтобы делать с нейросетями интересные вещи. В статье я описываю, как в 2017 году мы обучили нейронную сеть на корпусе из примерно 30 000 текстов и заставили ее генерировать новые интернет-мемы и мемы (коммуникационные знаки) в социологическом смысле слова. Описан использованный нами алгоритм машинного обучения, технические и административные трудности, с которыми мы столкнулись.

Многие наверняка слышали о режимах смешивания (blend modes), которые присутствуют в большинстве популярных программ для работы с изображениями и видео. Там это — важный инструмент создания контента, давно уже ставший неотъемлемой их частью.

А что же в играх?

Допустим, появилась необходимость использовать Color Dodge смешивание для системы частиц или UI-художник сделал красивую графику для игрового интерфейса, но некоторые его элементы используют какой-нибудь Soft Light. А может, вам понадобилось подвергнуть трёхмерный объект Divide-смешиванию, чтобы получить эффект прямиком из кинокартин Линча?



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

В данной статье я расскажу об алгоритме смешивания текстур, который позволяет привести внешний вид ландшафта ближе к естественному. Этот алгоритм легко может быть использован как в шейдерах 3D игр, так и в 2D играх.

Статья рассчитана на начинающих разработчиков игр.

Нейронные сети совершили революцию в области распознавания образов, но из-за неочевидной интерпретируемости принципа работы, их не используют в таких областях, как медицина и оценка рисков. Требуется наглядное представление работы сети, которое сделает её не чёрным ящиком, а хотя бы «полупрозрачным». Cristopher Olah, в работе «Neural Networks, Manifolds, and Topology» наглядно показал принципы работы нейронной сети и связал их с математической теорией топологии и многообразия, которая послужила основой для данной статьи. Для демонстрации работы нейронной сети используются низкоразмерные глубокие нейронные сети.

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

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

Рассмотрим принцип работы сети на примере

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

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

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

Конечно же, преимущества процедурных карт бессмысленны без большой вариативности механик и контента — однообразный hack-and-slash здесь не подойдёт. Поэтому все roguelike, выдержавшие испытание временем, имеют глубокий геймплей.

Этот пост является результатом моей работы над генерацией карт для Cogmind.

Доброго времени суток. Предлагаю Вашему вниманию перевод статьи про шум Перлина (вот этой). Ссылки на эту статью уже мелькали на хабре (тут), но перевод статьи мне не попался. Так что надеюсь кому-либо он может оказаться полезен.

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

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

Для создания функции шума Перлина, вам нужны две вещи, функции шума и функция интерполяции.

Знакомство с систему двухмерных тайловых карт Unity даёт отличную возможность экономии времени инди-разработчиков и игровых студий на прототипирование и создание качественных 2D-игр.

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

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

В этой статье мы воспользуемся простой тайловой 2D-игрой, чтобы узнать следующее:

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

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


На изображении ниже показан набор тайлов (тайлсет), на основании которого сгенерирован мир из видео. Мир снабжён примечаниями, которые помогут представить его в настоящей среде.

Буквально только что наткнулся на статью из песочницы о grid-tiling'е и решил написать свой аналог.
Мой метод распределения переходов несколько отличается от упомянутой в той статье.
Начало данной системы положено в небезызвестной игре WarCraft III.

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

Чем выгодно отличается шум Перлина, легко можно заметить, если сравнить картинки.

Обычный шум (из той самой статьи):


Шум Перлина:


И увеличением количества октав первую картинку ко второй никак не приблизишь. Я не буду описывать достоинства шума Перлина и область его применения (потому что статья о программировании, а не о применении), а постараюсь объяснить как он реализован. Думаю, это будет полезно многим программистам, ведь хакерские исходники Кена Перлина мало объясняют даже при наличии комментариев.

Итак, вы хотите попытаться создать игру, но немного напуганы. Не волнуйтесь, я тоже был напуган.

Я боялся использовать объекты, например. Они были такой большой страшной вещью, которую я откладывал на потом. Но сейчас я использую их все время.

Я собираюсь показать вам все шаги, через которые я прошел, при создании моей ролевой игры в JavaScript.

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

Это последняя статья из цикла о процедурно генерируемых с помощью Unity и C# картах мира. Осторожно, под катом 7 МБ картинок.

Это третья статья из цикла о процедурно генерируемых с помощью Unity и C# картах мира. Цикл будет состоять из четырех статей.

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

Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.

Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.

Именно так, «делался», без уточнения способа производства.

Как же поступят наши программисты?

В последние несколько лет мои переживания по поводу российского рынка ИТ только усиливались. Все началось с кризиса рубля 2014 года (а может, и раньше), и с тех пор меня не покидает ощущение, что многие российские компании, особенно провинциальные, завязали себе глаза, заткнули ватой уши и все еще пытаются сделать вид, что ничего не происходит. Я много общался с разными компаниями, с HR, с разработчиками, и составил список неутешительных тезисов о том, что представляет собой как программистский рынок, так и культура разработки в целом, ведь это вещи взаимосвязанные. По моим субъективным оценкам, эти тезисы справедливы для ~60% российских компаний, хотя, казалось бы, те другие 40% компаний, которые мы знаем и любим, должны были заставить задуматься. Но я очень подозреваю, что это эти 60% просто надеются на русский “авось”, и подвергаются так называемой willful blindness, а иногда и намеренно мутят воду. Итак, по-честному, что же происходит?

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

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

Доброго времени суток!
В этой статье я расскажу, как повысить производительность многопоточного (и не только) C#-приложения, в котором часто создаются объекты для «одноразовой» работы.
Немного про многопоточность, неблокирующую синхронизацию, использование встроенного в VS2012 профилировщика и небольшой бенчмарк.

Часть вторая

В части первой этой статьи я рассказал, почему для игры M.E.R.C. мы выбрали процедурную генерацию уровней, и описал требования к ней. Также я описал процесс генерирования структуры процедурного уровня и соединения множества фрагментов для создания целостного уровня. Во второй части статьи мы обсудим решение проблем освещения и NavMesh в Unity и создание NPC на основании темпа.

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

В этой статья мне хотелось бы рассказать о том, как была ускорена отрисовка монстров при создании игры Alien Massacre. Данное решение подойдет для любых проектов, которые испольуют спрайтовую анимацию.

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

• 1 Необходимо обеспечить отрисовку большого числа анимированных объектов на сцене. Ведь мы хотим, чтобы игрок отстреливался от полчищ монстров.
• 2 Прогресс анимации должен быть различен для каждого из объектов. Ведь мы не хотим, чтобы мобы ходили строем.

Решение «из коробки»

Безусловно, первое решение было простым: все сделать с помощью уже встроенного в UnityEngine компонента Animator. Посмотрим, что из этого получается.