Всем привет! Меня зовут Гриша, и я основатель CGDevs. Сегодня хочется продолжить тему математики в геймдеве. В предыдущей статье были показаны базовые примеры использования векторов и интегралов в Unity проектах, а сейчас поговорим о матрицах и аффинных преобразованиях. Если вы хорошо разбираетесь в матричной арифметике; знаете, что такое TRS и как с ним работать; что такое преобразование Хаусхолдера – то вы возможно не найдёте для себя ничего нового. Говорить мы будем в контексте 3D графики. Если же вам интересна эта тема – добро пожаловать под кат.

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

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

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

Привычный хаос в названиях коммитов. Знакомая картина?

Наверняка вы знаете git-flow. Это отличный набор соглашений по упорядочиванию работы с ветками в Git. Он хорошо документирован и широко распространен. Обычно мы знакомы с правильным ветвлением и много говорим об этом, но, к сожалению, уделяем слишком мало внимания вопросу наименования коммитов, поэтому часто сообщения в Git пишутся бессистемно.

Меня зовут Ержан Ташбенбетов, я работаю в одной из команд Яндекс.Маркета. И сегодня я расскажу читателям Хабра, какие инструменты для создания осмысленных коммитов мы используем в команде. Приглашаю присоединиться к обсуждению этой темы.

Часть 1. Введение

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

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

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


Есть много составляющих, необходимых для создания даже простой 3D-игры, не говоря уж о таком проекте, как Watch Dogs.

У меня есть только общее представление о том, что нужно рассмотреть в этой статье, но это будет зависеть от того, какие темы вызовут интерес. Тем не менее, основная идея заключается в том, чтобы создать общее описание того, что происходит внутри современной игры, не отпугнув при этом никого из читателей — я буду предполагать, что у вас нет знаний математики и программирования. Если вы знаете разницу между ЦП и графической картой, и отличаете оперативную память от жёсткого диска, то этого будет вполне достаточно, а остальное я объясню.

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

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

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

Хотите делать быстрее и качественней остальных? Не хотите тратить тонны усилий впустую?

Сделайте прототип игровой механики. 90% начинающих разработчиков этого не делают (!)

Что это? Зачем? И с чем его едят?

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

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

Главная проблема — как понять насколько интересно играть в мою игру?
Очень важно сделать это максимально быстро.Как?
Сделать игровой прототип и сделать правильно.

С чем «есть» игровой прототип я не скажу, но чай при прочтении определенно не повредит.

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

Для записи трёхмерных поворотов программисты графики используют кватернионы. Однако в кватернионах сложно разобраться, потому что изучают их поверхностно. Мы просто принимаем на веру странные таблицы умножения и другие загадочные определения, и используем их как «чёрные ящики», поворачивающие векторы так, как нам нужно. Почему $$ и $$? Почему мы берём вектор и превращаем его в «мнимый» вектор, чтобы преобразовать его, например $$? Да кому это интересно, если всё работает, правда?

Существует способ описания поворотов под названием ротор, который относится к области и комплексных чисел (в 2D), и кватернионов (в 3D), и даже обобщается до любого количества измерений.

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

Кроме того, для визуализации и понимания трёхмерных роторов не нужно использовать четвёртое пространственное измерение.

Было бы здорово, если бы начали вытеснять использование и изучение кватернионов, заменяя их роторами. Заменить их очень просто, а код останется почти таким же. Всё, что можно делать с кватернионами, например, интерполяцию и устранение блокировки осей (Gimbal lock), можно сделать и с роторами. Но понимать мы начинаем гораздо больше.

… А точнее как НЕ создать героя, который будет похож на "тысячи таких же".

Навеяно статьей о монстрах в играх.

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

В одних героев мы верим, а в других — нет.

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

Огромное количество мыльных опер вызывает только смех, хотя вроде как рассказывают о реальных человеческих чувствах, которые всем нам должны быть хорошо знаком. А над историями из Starcraft, Warcraft, The last of us, Mass Effect, The Witcher было пролито немало слез.

Почему?

Здравствуйте, коллеги.

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

Противники, одни из ключевых фигур, без которых та или иная игра может потерять свой смысл, а когда эти враги еще и монстры, то как раз они и создают ту атмосферу, которую вкладывают создатели. Тяжело представить Silent Hill без пирамидаголового, Outlast — без Криса Уокера и так далее, принцип понятен. Монстры — это собирательный образ врага в игре, это может быть не только уродливый демон или гигантские пауки, даже злобный сосед, как Hello Neighbor, является монстром, несмотря на облик человека.

Дойдя до этой части, читатель спросит:

“ А о чем собственно речь?

Не так давно мимо нас пробегала неплохая статья об ужасном состоянии производительности современного ПО (оригинал на английском, перевод на Хабре). Эта статья напомнила мне об одном антипаттерне кода, который встречается весьма часто и в общем кое-как работает, но приводит к небольшим потерям производительности то тут, то там. Ну, знаете, мелочь, пофиксить которую руки никак не дойдут. Беда лишь в том, что десяток таких «мелочей», разбросанных в разных местах кода начинают приводить к проблемам типа «вроде у меня последний Intel Core i7, а прокрутка дёргается».

Я говорю о неверном использовании функции Sleep (регистр может отличаться в зависимости от языка программирования и платформы). Итак, что же такое Sleep? Документация отвечает на этот вопрос предельно просто: это пауза в выполнении текущего потока на указанное количество миллисекунд. Нельзя не отметить эстетическую красоту прототипа данной функции:

void Sleep(DWORD dwMilliseconds);

Всего один параметр (предельно понятный), никаких кодов ошибок или исключений — работает всегда. Таких приятных и понятных функций очень мало!


Что же могло пойти не так? То, что программисты используют эту замечательную функцию не для того, для чего она предназначена.

Хочу представить вашему вниманию перевод статьи Concurrency vs Multi-threading vs Asynchronous Programming: Explained.

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