Введение

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

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

Самцы светлячков вида Luciola cruciata синхронизируют вспышки на берегу реки в Японии

Когда бессвязные аплодисменты толпы внезапно превращаются в единый пульс, когда все начинают хлопать в унисон – кто решил, что так будет? Не вы, и не кто-то другой. Сверчки издают звуки синхронно; метрономы, поставленные рядом, качаются одновременно; некоторые светлячки мерцают в темноте вместе. По всем США энергосеть работает на частоте 60 Гц, и все её неисчислимые притоки переменного тока синхронизируются сами по себе. Наша жизнь зависит от синхронизации. Нейроны в мозге активируются синхронными волнами, чтобы управлять нашим телом и разумом, а клетки водителя ритма сердца синхронизируются, создавая биение.

Сейчас все говорят про сообщества. Это модно, классно, но мало кто знает, что с ними делать и как их создавать. Собрать всех в чатик и сказать «теперь вы сообщество» недостаточно. Я расскажу про механику создания внутренних сообществ, про культуру и воспитание участников и про то, как сообщества могут помогать закрывать потребности организации.

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

C++ Enterprise Edition

Что такое "enterprise edition"

Удивительно, но за все время моей работы в IT, я ни разу не слышал, чтобы кто-то говорил "enterprise edition" относительно языка программирования, кроме как для Java. Но ведь приложения для корпоративного сегмента люди пишут на многих языках программирования, и сущности, которыми оперируют программисты, если не идентичны, то схожи. И для c++ в частности, я бы хотел заполнить пробел enterpr'айзности, хотя бы рассказав об этом.

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

А еще там разбирается характер персонажей на примере сторонников теории плоской Земли.


Сценарий фильма «Апокалипсис сегодня» (1979) по мотивам книги Джозефа Конрада «Сердце тьмы» (1899)

Инопланетяне являются почти настолько же основным столпом научной фантастики, как и межзвёздные полёты. Если задуматься, то пожалуй даже более влиятельным — Идеи о чуждой жизни обосновались в фантастике даже до межзвёздных полетов, с работами Герберта Уэллса и Эдгара Берроуза.

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


В 9 из 10 таких произведений «инопланетянин» по замыслу создателей — это типичный человек, только со странными выростами на голове, и\или неестественным цветом кожи (Наиболее хрестоматийный пример такого безобразия — сериал Star Trek). В худшем случае запредельной лени инопланетянин будет просто человеком, без каких-либо внешних отличий вообще. Это если инопланетянин подразумевается как персонаж которому можно сочувствовать, в случае если этот инопланетянин задумывается как враг, то его внешность и поведение часто больше напоминают какое-нибудь разъяренное дикое животное, чем разумное существо. Рычание или бритвенно-острые когти в полметра длиной не обязательны, но крайне приветствуются.

Где-то примерно до середины или конца 90х такая ситуация имела весьма практичное объяснение: Чтобы сделать персонажа, не похожего на человека, необходим большой бюджет и много денег на создание аниматронных кукол (А результат всё равно мог получиться неудовлетворителен по убедительности). Далеко не все проекты обладали таким количеством денег и времени, тем более телевизионные сериалы, поэтому загримированный актер оставался наиболее дешевым, практичным и эффективным способом сымитировать инопланетянина.

В 2016 году я начал работу над хобби-проектом по реверс-инжинирингу игры Duke Nukem II и воссозданию с нуля его движка. Проект имеет название Rigel Engine и выложен в open source (его страница на GitHub). Сегодня, более чем два с половиной года спустя на моём движке уже можно пройти весь shareware-эпизод оригинальной игры с практически идентичным оригиналу игровым процессом. Вот видео с прохождением первого уровня:


Что же он может делать? Rigel Engine работает как полная замена оригинального двоичного файла DOS (NUKEM2.EXE). Можно скопировать его в каталог игры и он считает из него все данные, или же указать путь к данным игры как аргумент командной строки. Движок собирается и выполняется под Windows, Mac OS X и Linux. Он основан на SDL и OpenGL 3/OpenGL ES 2, а написан на C++ 17.

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

Помните очаровательного котика, которые чихал в заставке советского мультфильма? Мы помним, и нашли его — вместе с ворохом другой рисованной фантастики. В детстве она пугала и обескураживала, поскольку поднимала серьезные, взрослые темы. Настала пора пересмотреть старые мультфильмы, чтобы узнать, о каком будущем мечтали в той стране.

Мозговой штурм с помощью транспонирования

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


Ячейки, с которыми я работаю, выстроены в столбцы и строки. Давайте возьмём пример из простой игры:


Строки — это классы персонажей: воин, маг, вор.

Столбцы — это типы действий: нападение, защита, особое действие.

Матрица содержит весь код для обработки каждого из типов действий для каждого типа персонажа.

Как выглядит код? Обычно подобные структуры упорядочивают в такие модули:

1. Fighter будет содержать код для обработки ударов мечом, снижения урона с помощью брони и особого мощного удара.
2. Mage будет содержать код обработки фаерболов, отражения урона и особую атаку заморозкой.
3. Thief будет содержать код для обработки атак кинжалом, избегания урона уклонением и особую обезоруживающую атаку.

Иногда бывает полезно транспонировать матрицу. Мы можем упорядочить её по другой оси

Попробуем представить химию без Периодической системы Менделеева (1869). Сколько же элементов надо было держать в голове, причём в произвольном порядке… (Тогда — 60.)

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

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

В то время, когда видеоигры ещё находились в эпохе Pac-Man, аниматоры студии Disney Фрэнк Томас и Олли Джонсон перечислили в своей книге 1981 года «The Illusion of Life: Disney Animation» то, что сегодня считается базовыми правилами анимации — 12 основных принципов.

1. Сжатие и растяжение (Squash & stretch)
2. Сценичность (Staging)
3. Подготовка, или упреждение (Anticipation)
4. Использование компоновок и прямого фазованного движения (Straight ahead & pose to pose)
5. Сквозное движение (или доводка) и захлест действия (Follow-through & overlapping action)
6. Смягчение начала и завершения движения (Slow in & slow out)
7. Дуги (Arcs)
8. Дополнительное действие (Secondary action)
9. Привлекательность (Appeal)
10. Расчёт времени (Timing)
11. Преувеличение, утрирование (Exaggeration)
12. Профессиональный рисунок (Solid drawing)

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

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

При разработке сайтов, выходящих за рамки условного бутстрапа, рано или поздно возникают вопросы, связанные с производительностью анимаций. Особенно важными они являются в дизайнерских сайтах, вроде тех, что попадают в каталоги Awwwards, FWA, CSS Design Awards и.т.д. При этом часто задача создания анимаций и последующей оптимизации, если она будет нужна, ложится на плечи не очень опытных разработчиков, которые даже не знают с чего начать. Обычно все это выливается в тормозящие сайты, которыми невозможно пользоваться, и последующее негативное отношение ко всему классу таких проектов. В этой статье мы постараемся разобрать, где находится граница приемлемой производительности анимаций, какие узкие места часто встречаются и куда смотреть в инструментах разработчика в первую очередь.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Long Names Are Long" автора Bob Nystrom.

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

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

Использование языка Dart в Google постепенно набирает обороты, и я много занимался подобными code review. Для разработчика языка это очень увлекательный процесс. Я получаю из первых рук представление о том, как люди используют Dart, что действительно полезно для его развития. У меня есть более четкое представление о том, какие ошибки являются общими, и какие функции интенсивно используются. Я чувствую себя как этнограф, ведущий дневник о жизни туземцев.

Но, в любом случае, дело не в этом. Черт бы его побрал, дело даже не в Darts. То, о чем я хожу поговорить, — это то, что я вижу во многих кодах, и что сводит меня с ума: излишне длинные имена.

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

Сложно оценить героя, не поняв его "статы" и "абилки". Что он может и на что способен — вот следующий уровень сложности, на который нам придётся нырнуть. Мало с помощью точного имени отразить внутреннее святилище объекта, ещё следует убедиться, что это таки святилище, а не конюшни из геттеров.

Об этом — в статье.

Дисклеймер. Автор не является сторонником использования многозадачных операционных систем для микроконтроллеров.

Есть проблема:

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

Под катом попытка решения проблемы с использованием странных на первый взгляд инструментов: Android-смартфон, markdown, Epsilon Notes, динамическая книга, Termux, git, bitbucket, Хабр.

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

Я решил создать виртуальную машину (VM), учитывая то, что на тот момент у меня не было идей, мне показалось, что это прекрасная мысль. Если вы заинтересовались, то вперёд под кат!

Источники вдохновения

Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!

Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.

Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).

Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!

TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).