Привет, Хабр.

Эта статья будет в немного «пятничном» формате, сегодня мы займемся NLP. Не тем NLP, про который продают книжки в подземных переходах, а тем, который Natural Language Processing — обработка естественных языков. В качестве примера такой обработки будет использоваться генерация текста с помощью нейронной сети. Создавать тексты мы сможем на любом языке, от русского или английского, до С++. Результаты получаются весьма интересными, по картинке уже наверно можно догадаться.



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

1 ноября 2018 года Московская Область без объявления войны (объявленной парой лет ранее), ввела финансовые санкции. Против собственников территорий, предоставляющих плацдарм для распространения борщевика Сосновского. Ура!

Мне, правда, интересно, кто будет платить за титаническую плантацию борщевика между Шереметьево и ниткой Аэроэкспресса. Плантацию, встречающую гостей и жителей Москву сразу по прилёту в белокаменную. Там растут просто миллионы штрафа.

Что же такое борщевик Сосновского и почему с ним надо бороться. Как это делать. Как это делать не нужно. А так же научные и псевдонаучные факты в нескучно-популярном изложении.

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

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

UPD. Извиняюсь, но собственный перевод этой статьи на Хабре уже делал PatientZero. Прочитать его вариант можно здесь, но почему-то статья прошла мимо меня (поиском пользовался, но что-то пошло не так). А так как пишу в блог, посвященный геймдеву, решил оставить свой вариант перевода для подписчиков (некоторые моменты у меня оформлены по-другому, некоторые — намеренно пропущены по совету разработчиков).

Всем привет! Давно ничего не писал, но сейчас захотелось рассказать про очень удобную штуку, о которой многие не знают. Это Event System в Unity. Многие, для задач в которых EventSystem очень удобен, используют обычный Raycast. Я расскажу про то, как пользоваться частью функционала EventSystem (его на самом деле очень много) и как этот инструмент позволяет быстро решать многие задачи связанные с обработкой событий интерфейсов и объектов. Как всегда с репозиторием с примерами. Если вам интересно — добро пожаловать под кат!

Год назад у нас в компании был один проект — мобильный шутер War Robots с относительно медленными, но красочными и напряженными боями. Игра продолжает развиваться, у нее десятки миллионов установок и игроков по всему миру, постоянно выходят апдейты. В какой-то момент мы захотели сделать динамичный шутер на Unity со скоростями, сравнимыми с Overwatch, CS:GO или Quake. Но реализовать задуманное для мобильных платформ (в первую очередь iOS и Android) на основе War Robots при текущих архитектуре и подходах было практически нереально.

Мы понимали, как это сделать в теории — есть много статей, презентаций на YouTube, детально рассказывающих о том, как написать шутер, как работать с сетью, какие возникают проблемы и как их решать. Здесь нет Rocket Science, все эти подходы придумали еще 30 лет назад и за это время они особо не поменялись. НО: у нас не было практики.

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

Сколько уже было мануалов "Как сделать игру на Unity за 3 часа", "Делаем Counter-Strike за вечер" и т.п.? Низкий порог входа — это, несомненно, главный плюс и минус Unity. Действительно, можно накидать “ассетов”, дописать несколько простых “скриптов”, обмотать синей изолентой и это даже будет как-то работать. Но когда проект обрастает игровыми механиками, сложной логикой поведения, то проблемы при подобном подходе нарастают как снежный ком. Для внедрения новых механик требуется переписывание кода во многих местах, постоянная проверка и переделывание префабов из-за побившихся ссылок на компоненты логики, не говоря уже об оптимизации и тестировании всего этого. Разумеется, архитектуру можно продумать изначально, но на практике это всегда недостижимая цель — дизайн-документ довольно часто меняется, какие-то части выкидываются, добавляются абсолютно новые и никак не связанные со старой логикой поведения. Компоненты в Unity — это шаг в правильном направлении в виде декомпозиции кода на изолированные блоки, но особенности реализации не позволяют достичь необходимой гибкости, а самое главное, производительности. Разработчики придумывают свои фреймворки и велосипеды, но чаще всего останавливаются на ECS (Entity Component System). ECS – одно из решений, продолжающее идею компонентной модели Unity, но придающее ей ещё больше гибкости и сильно упрощающее рефакторинг и дальнейшее расширение приложения новым функционалом без кардинальных изменений в текущем коде.

Привет! Я пишу статьи, посвященные архитектуре в игровой разработке. В этой статье я хочу разобрать паттерн Команда (Command). Он многогранен, и может быть применен по-разному. Но я покажу, как сделать мой любимый трюк — машина времени для отладки изменений гейм стейта.

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

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

Хотите узнать как это сделать? Прошу под кат.

Люблю офис по утрам. Когда темно-тихий опенспейс незаметно и в привычных знакомых заботах понемногу заполняется светом и шумом начинающегося дня. Постепенно наползают по-утреннему радостные и довольные девелоперы, дизайнеры, тестировщики. Оживают приветами рабочие чаты. Приходят менеджеры в окружении свиты из s&s, hr и прочих хипстерящих. Раздаются и получаются весьма искренние пожелания доброго утра у кофемашин. Тихий и пустой поначалу офис, как двигатель, постепенно выходит на рабочую мощность, и в свете и гуле начинается рабочий день.

Алиасинг (aliasing) — это, возможно, наиболее фундаментальный и самый широко обсуждаемый артефакт 3D-рендеринга всех времён. Однако в игровом сообществе его часто недопонимают. В этой статье я подробно расскажу о теме сглаживания (антиалиасинга, anti-aliasing, AA) в реальном времени, особенно о том, что касается игр, и в то же время буду излагать всё достаточно простым языком.

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

Эту программу можно скачать здесь.

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

В этой статье я хочу обсудить шаблон проектирования «сущность-компонент-система» (Entity-Component-System, ECS). По этой теме можно найти много информации в Интернете, поэтому я не буду глубоко вдаваться в объяснения, а больше расскажу о моей собственной реализации.

Часть 1: Реализация шаблона Entity-Component-System на C++

Начнём сначала. Полный исходный код моей реализации ECS можно найти в репозитории на github.

Entity-Component-System, в основном используемый в играх — это шаблон проектирования, обеспечивающий огромную гибкость в проектировании общей архитектуры программного обеспечения^[1]. Такие большие компании, как Unity, Epic или Crytek используют этот шаблон в своих фреймворках, чтобы предоставить разработчикам очень богатый возможностями инструмент, с помощью которого они могут разрабатывать собственное ПО. Прочитать более широкое обсуждение по этой тематике можно в этих постах ^[2,3,4,5].

После публикации моей статьи о том, какой была бы Земля, будь она в два раза больше, у читателей появился вопрос: «А что насчёт тороидальной Земли»? Вопрос не самый оригинальный, эту тему уже обсуждали в онлайне и проводили её моделирование. Но я люблю всё делать сам, так что я попытался провести свой собственный анализ.

Может ли существовать тороидальная планета?

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

Вступление

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

В данной статье мы постарались не только описать такой подход к организации кода, как Singleton (в народе называемый паттерном проектирования), но и рассмотреть наиболее комфортные и правильные подходы к обработке событий и поговорить об удобности кода в целом.

Перевод статьи Синди Шридхаран.

В этой статье автор собирается:

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

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

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

Так как оптимизация такого старого оборудования носит комплексный характер, статья будет состоять из нескольких глав:

— Firefox
— Дополнения к браузеру
— Драйверы
— WindowsXP
— BIOS
— Советы по аппаратной части

Можно ли предсказать эволюцию или она действует наобум

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

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

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

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

Часть 1. Линейные структуры

Массив

Когда вам нужен один объект, вы создаёте один объект. Когда нужно несколько объектов, тогда есть несколько вариантов на выбор. Я видел, как многие новички в коде пишут что-то типа такого:

// Таблица рекордов
int score1 = 0;
int score2 = 0;
int score3 = 0;
int score4 = 0;
int score5 = 0;

Это даёт нам значение пяти рекордов. Этот способ неплохо работает, пока вам не потребуется пятьдесят или сто объектов. Вместо создания отдельных объектов можно использовать массив.

// Таблица рекордов
const int NUM_HIGH_SCORES = 5;
int highScore[NUM_HIGH_SCORES] = {0};

Будет создан буфер из 5 элементов, вот такой:



Заметьте, что индекс массива начинается с нуля. Если в массиве пять элементов, то они будут иметь индексы от нуля до четырёх.

Для вычисления урона от атаки в таких настольных ролевых играх, как Dungeons & Dragons, используются броски урона. Это логично для игры, чей процесс основан на бросках кубиков. Во многих компьютерных RPG урон и другие атрибуты (сила, очки магии, ловкость и т.д.) вычисляются по похожей системе.

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

1. Простые корректировки — среднее значение и дисперсия
2. Добавление асимметрии — отбрасывание результатов или добавление критических попаданий
3. Полная свобода в настройке случайных чисел, неограниченная возможностями кубиков

В этом туториале мы воссоздадим эффект 3D-принтера, используемый в таких играх, как Astroneer и Planetary Annihilation. Это интересный эффект, показывающий процесс создания объекта. Несмотря на внешнюю простоту, в нём есть множество далеко не тривиальных сложностей.

Элиезер Шломо Юдковский — американский специалист по искусственному интеллекту, исследующий проблемы технологической сингулярности и выступающий за создание Дружественного ИИ. В неакадемических кругах больше известен как автор фанфика «Гарри Поттер и методы рационального мышления» под эгидой Less Wrong.

Меня всегда удивляли умные люди, верящие в вещи, кажущиеся мне абсурдными. К примеру, генетик и директор Национальных институтов здоровья Фрэнсис Коллинс верит, что Иисус восстал из мёртвых. Теоретик ИИ Элиезер Юдковский верит, что машины… Но лучше я дам слово ему самому. В 2008 я брал у него интервью на Bloggingheads.tv, но ничего хорошего из этого не получилось, поскольку я решил, что он был последователем гуру сингулярности Рэя Курцвейла. Но Юдковский ни за кем не следовал и никогда не учился в колледже. Он упрямый и оригинальный теоретик интеллекта, как человеческого, так и искусственного. Его работы (к примеру, эссе, помогшее мне понять, или давшее иллюзию понимания, теоремы Байеса) источает высокомерие самоучки, острые грани которого не были зашлифованы формальным образованием – но в этом есть часть его очарования. Даже когда он раздражает вас, Юдковский забавен, свеж, провокационен. Для подробностей его биографии смотрите его личный сайт или сайт Института исследования машинного интеллекта, в основании которого он участвовал. И почитайте это интервью с бонусом в виде комментариев от его жены Брийены.