Всем привет, меня зовут Евгений Демиденко. Последние несколько лет я занимаюсь разработкой автоматизированной системы тестирования игр в Pixonic. Сегодня я хотел поделиться нашим опытом разработки, поддержки и использования такой системы на проекте War Robots.

Для начала разберемся, что же все-таки мы автоматизируем этой системой.

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



Приведу немного цифр. Сейчас для War Robots написано более 600 UI-тестов и порядка 100 core-тестов. Только на этом проекте мы произвели около миллиона запусков наших тестовых сценариев, каждый из которых занимал порядка 80 секунд. Если бы эти сценарии мы проверяли вручную, то потратили бы минимум по пять минут на каждый. Кроме того, мы запустили более 700 тысяч бенчмарков.

Из платформ мы используем Android и iOS ― всего 12 устройств в парке. Разработкой системы и ее поддержкой занимаются два программиста, а написанием и анализом тестов ― один QA-инженер.

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


Snail Иниго Килеза была полностью создана при помощи raymarching. Другие примеры подвергнутых raymarching-у сцен можно найти на Shadertoy.

В этой статье мы сначала расскажем о фундаментальных понятиях и теории raymarching, а затем покажем, как реализовать простейший raymarcher в игровом движке Unity. Далее мы продемонстрируем, как на практике встроить raymarching в настоящую игру на Unity, позволив объектам с raymarching-ом перекрываться обычными GameObjects.

Полный код можно найти в этом репозитории Github.

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

Код Serbench находится на GitHub.

Начало проекта

Этот бенчмарк проект начался со статьи “Serializers in .NET v.2” на GeeksWithBlogs.net. В статье было рассмотрено довольно много имеющихся под .NET сериализаторов. Но, чтобы превратить эту статью и соответствующий код в настоящий бенчмарк, надо было сделать несколько улучшений.

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

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

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

Часть 1: обработка вершин

Часть 2: растеризация и трассировка лучей

Часть 3: текстурирование и фильтрация текстур

Вспомним пройденное

Ранее мы рассматривали ключевые аспекты перемещения и обработки объектов в сценах, их преобразования из трёхмерного пространства в плоскую сетку пикселей, а также способы наложения текстур на эти объекты. В течение многих лет такие операции составляли основную часть процесса рендеринга, и мы можем увидеть это, вернувшись в 1993 год и запустив Doom компании id Software.


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

Теней не было, потому что они не входили в задачу программистов: PC того времени представлял собой процессор на 66 МГц (то есть на 0,066 ГГц!), жёсткий диск на 40 МБ и 512-килобайтную графическую карту с минимальными 3D-возможностями. Перенесёмся на 23 вперёд: в знаменитой перезагрузке серии мы видим совершенно другую историю.


Для рендеринга этого кадра использовалось множество технологий, он может похвастаться такими этапами, как screen space ambient occlusion, pre-pass depth mapping, фильтры размытия боке, операторы тональной коррекции, и так далее. Расчёт освещения и затенения каждой поверхности выполняется динамически: они постоянно изменяются в зависимости от условий окружающей среды и действий игрока.

Для начала нужно ответить на вопрос что же такое подземелье?

Не буду углубляться в эту тему, а просто использую определение из третьего издания руководства мастера подземелий (ДМ) D&D:

Понятие «подземелье» очень расплывчато. Подземелье обычно находится под землёй, но могут существовать и надземные «подземелья». Некоторые ДМ называют подземельями любые места, где происходит приключение. Здесь мы будем называть подземельем замкнутое, чётко заданное пространство, состоящее из соединённых определённым образом мест встреч с врагами.

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

Это может показаться очевидным, но хорошее подземелье в CRPG должно соответствовать игре. Например, мне нравятся огромные переплетённые спагетти-подземелья из Daggerfall:


Они соответствуют игре, потому что в Daggerfall игрок движется быстро, есть такие способы перемещения, как полёты, взбирание, плавание и телепортация (слава богу, что есть телепорты), а встречи с врагами редки и скоро заканчиваются. Благодаря камере с видом от первого лица движение кажется очень удобным, в классическом стиле Doom.

Если бы такой дизайн использовали в Final Fantasy IX с её медленным движением, медленными пошаговыми боями, постоянными случайными врагами и фиксированной камерой, то это было бы невыносимо. То же самое относится к играм, где движение привязано к сетке карты, например, к Legend of Grimrock, или где перемещается большая группа персонажей, например, к Baldur’s Gate.

КДПВ

Хабр, приветствую!

Описанное ниже ни в коем случае не tutorial или best practice. Я решил всего лишь агрегировать и задокументировать свои достижения в поставленном вопросе.

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

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

От переводчика

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

Если вы побродите по форуму DOTS, то можете встретить там подобные посты о том, как автор написал библиотеку, способную рендерить миллион анимированных спрайтов, и всё равно получает только 60fps. Я создал собственный рендерер спрайтов DOTS, который достаточно хорош для нашей игры, но он не способен справиться с миллионом. Мне стало любопытно.

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

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

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

Эта статья взята из книги Practical Game AI Programming, написанной Микаэлем Даграка и опубликованной Packt Publishing. Эта книга позволяет узнать, как создать игровой ИИ и с нуля реализовать самые современные алгоритмы ИИ.

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

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

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

Помните созданный нами класс Position? Вообще-то в Unity уже имеется встроенный класс, выполняющий точно такие же функции, но с немного более качественным управлением — его проще объявлять и обрабатывать. Этот класс называется Vector2Int. Поэтому перед началом мы удалим из MapManager.cs класс Position и заменим каждую переменную Position на переменную Vector2Int.


Это же надо проделать в нескольких местах скрипта DungeonGenerator.cs. Теперь давайте приступим к остальной части алгоритма.

С выходом Roslyn разговоры о том, что скоро кода можно писать будет меньше вспыхнули с новой силой. Сегодня я расскажу немного о другом подходе как писать меньше кода и соответственно делать меньше ошибок — расскажу о Fody. На хабре упоминание нашёл только вскользь в рамках решения како-то проблемы. Для того, чтобы заинтересовать читателя, ещё не решившего стоит ли тратить своё время на данный текст отмечу, что популярный NotifyPropertyWeaver переехал на Fody и с помощью Fody можно делать всякие там классные AOP.

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

На рынке существует множество продуктов для обмена сообщениями, которые поддерживают паттерн Publisher-Subscriber, например Azure Service Bus, RabbitMQ или Apache Kafka.

Недавно мною были опубликованы две NuGet библиотеки для быстрой и удобной настройки event-based communication с использованием Azure Service Bus и RabbitMQ. В этой короткой how-to статье описаны шаги для использования последней.

В этой статье разбираются вопросы оптимизации UI-элементов проектов, сделанных в ​Unity​. На основании информации из официальной документации и личного опыта я постарался наглядно объяснить принципы работы UI-элементов. Также здесь вы найдёте практические советы, которые помогут улучшить производительность вашего проекта в том, что касается пользовательского интерфейса.

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

Введение

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

По традиции начну с предыстории. За время работы в игровой индустрии я разрабатывал различные проекты, с разной сложностью и побывал и в лагере гейм-дизайна, и в лагере программистов (где нахожусь и по сей день). Ни для кого не секрет, что любое приложение требует большого числа различных конфигурационных данных и настроек. В классическом, относительно Unity3d виде, такие настройки выносятся в видимую часть инспектора, где вводятся какие-то цифры и т.п. Я думаю, что говорить об удобстве такого подхода не стоит, это даже если исключить, факт, того, что на время настройки, сцена, в которой находится MonoBehaviour класс блокируется для изменений другими разработчиками. Поэтому после череды разного рода мытарств в прошлом, я решил, написать что-то простое и эффективное, что облегчит всем жизнь и упростит работу с такими данными, чем и хочу поделиться с вами.

Примечание: весь описанный ниже код применим к версии Unity 2018.3+ и использует компилятор Roslyn (версия языка C# 7+).

Docker — инструмент автоматизации развертывания и управления приложениями в среде виртуализации на уровне операционной системы. Docker позволяет развертывать приложения в переносимых контейнерах и управлять такими контейнерами. Распространяется компанией Docker как свободное программное обеспечение.

Мы поговорили с Никитой Цукановым aka kekekeks о том, в чем преимущества Docker и как его использовать для развертывания серверных приложений и управления ими.



— В чём актуальность контейнерной виртуализации приложений, как она упрощает развертывание приложений и управление ими?

Корпоративные ИТ-команды очень часто сталкиваются с трудностями в развертывании приложений. Вполне «нормальна», к сожалению, ситуация, когда между разработчиками приложений и ИТ-администраторами отсутствует диалог, когда только один человек в компании знает, какие кнопки надо нажать, чтобы приложение развернулось, а администратор сам ничего сделать не может — потому что существует один-единственный человек, у которого есть сакральные знания о том, как нужно развертывать проект. Случается и такое, что нужно запустить, например, четыре разные версии (иногда почти одинаковые, но все же разные) на разных конфигурациях, на разных машинах, а потом это все поддерживать.

У меня довольно большой опыт подобных проектов, и я выделяю следующие основные проблемы с развертыванием приложений. Первая: очень длинная инструкция по развертыванию, очень сложный процесс развертывания, никто не понимает, что в каком порядке нужно развертывать. Вторая: одно приложение необходимо тиражировать для работы с разными клиентами. Третья: несколько серверных приложений должны работать на одном и том же сервере, и их окружение несовместимо между собой, к примеру, вы решили использовать у себя Linq2Excel, но он требует установки Access Database Engine, 32- и 64-битные версии которого не могут быть установлены одновременно.

В первый раз я услышал о CQRS, когда устроился на новую работу. В компании, в которой работаю и по сей день, мне сразу сказали что на проекте, над которым я буду работать используется CQRS, Event Sourcing, и MongoDB в качестве базы данных. Из этого всего я слышал только о MongoDB. Попытавшись вникнуть в CQRS, я не сразу понял все тонкости данного подхода, но почему-то мне понравилась идея разделения модели взаимодействия с данными на две — read и write. Возможно потому что она как-то перекликалась с парадигмой программирования “разделение обязанностей”, возможно потому что была очень в духе DDD.

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

Сразу хочу уточнить что я работал только со связкой CQRS + Event Sourcing, и никогда не пробовал просто CQRS, так как мне кажется что без Event Sourcing он теряет очень много бенефитов. В качестве CQRS фреймворка я буду использовать наш корпоративный Paralect.Domain. Он чем-то лучше других, чем то хуже. В любом случае советую вам ознакомиться и с остальными. Я здесь упомяну только несколько фреймворков для .NET. Наиболее популярные это NCQRS, Lokad CQRS, SimpleCQRS. Так же можете посмотреть на Event Store Джонатана Оливера с поддержкой огромного количества различных баз данных.

Начнем с CQRS

Что же такое CQRS?
CQRS расшифровывается как Command Query Responsibility Segregation (разделение ответственности на команды и запросы). Это паттерн проектирования, о котором я впервые услышал от Грега Янга (Greg Young). В его основе лежит простое понятие, что вы можете использовать разные модели для обновления и чтения информации. Однако это простое понятие ведет к серьёзным последствиям в проектировании информационных систем. (с) Мартин Фаулер