Сейчас я расскажу, как выглядит процесс разработки на Unity в маленькой gamedev компании и как мы его улучшаем и автоматизируем. Всё-таки 2020 год на дворе, хватит уже мышкой водить…

Привет! Меня зовут Евгения Голева, я выступила на TeamLeadConf с докладом про обратную связь и хочу поделиться с вами его вольной расшифровкой. Мне удалось под соусом совсем другого проекта научить инженеров давать обратную связь гораздо лучше, чем они делали это раньше. Для этого пришлось не только долго и тщательно объяснять «зачем и как», но и организовать множество подходов к снаряду под бдительным контролем и с мягкой поддержкой. Путь был непростым, усеян граблями и велосипедами, и я надеюсь, что некоторые неочевидные мысли и методы пригодятся тем, кто хотел бы привить культуру здорового фидбэка своей команде.

В моей студии 15 человек, половина из которых — программисты. Студия специализируется на разработке интернет-магазинов, так что программисты для нас — основной ресурс.

От программистов всегда требуются три вещи

• Быстрее сдавать проекты.
• Укладываться в собственную оценку трудозатрат.
• Расти и развиваться

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

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

Это первая статья из трёх. Вторая часть описывает фреймворк для распознавания изображений (Image Recognition) — AirTest, а третья и завершающая посвящена Poco — фреймворку UI автоматизации при помощи написания кода.

AirTest IDE разработан компанией NetEase и предназначен для "hard-to-automate" приложений, таких как, к примеру, игр. Собственно на них и делается основной упор разработчиками, хотя это не мешает использовать AirTest и для любых других приложений.

AirTest IDE работает под Windows, MacOS X и Linux и содержит в себе 2 фреймворка: AirTest и Poco. Данная разработка была представлена Xin Liu на Android Game Developer Summit 2018. Для написания тестов используется Python 2.7 и Python 3.3+. Такие важные вещи как поддержка запуска тестов сразу на большом количестве устройств, открытость исходного кода и бесплатность приложения, а также легкое написаное тестов — это те преимущества, которые выделяются разработчиками. Приложение может быть использовано как на Windows, так и на MacOS и позволяет автоматизировать приложения со следующих OS: Windows, iOS, Android.

AirTest Project на GitHub содержит 4 проекта: Airtest, Poco, iOS-Tangent, multi-device-runner.
Стоит также упомянуть, что NetEase предоставляет свою ферму физических устройств для автоматизированного тестирования, которая называется AirLab.

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

В мобильных играх много разных интерфейсов, включая HUD и огромное количество экранов для меты. UX-дизайнеры их проектируют, UI-дизайнеры отрисовывают, а чтобы всё это оказалось в движке существуют специально обученные люди — технические UI-дизайнеры. Ну или по-простому верстальщики. Частично их работа заключается в том, чтобы кропотливо из PSD-макета перенести все в префаб, чиселку за чиселкой. Еще они занимаются UI-анимациями, заливают спрайты, делают верстку адаптивной, расставляют ключи локализаций и так далее.

И мы поставили себе несколько целей:

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

Вот как это происходило.

Жил на свете такой человек – Стивен Кови. Однажды он решил написать книгу о личной эффективности. Теперь эту книгу знают все, она называется «Семь навыков высокоэффективных людей». Она считается классикой, постоянно переиздается во всех мыслимых странах мира, за годы существования продано несколько десятков миллионов экземпляров. Сам Стивен Кови настолько разобрался в личной эффективности, что его личными консультациями не преминули воспользоваться несколько президентов, в т.ч. США.

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

Но я не про книгу хочу поговорить, а про неожиданное открытие, которое сделал Стивен Кови, когда ее писал. Он это явление назвал «социальный аспирин».

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


Посмотрите или прочитайте доклад Алексея Катаева на Saint TeamLead Conf, если не знаете, по каким формальным признакам определить классная ли у вас команда. Если хотите уметь измерять технический долг в часах, а не оперировать категориями «совсем чуть-чуть», «сколько-то», «ужасно много». Если ваш продакт-менеджер считает, что команда из трех человек за месяц сделает 60 задач — покажите ему эту статью. Если ваш руководитель обвешал разработку метриками и предлагает вам принимать меры на основе результатов вроде: «34% считают, что в команде есть проблема с планированием», этот доклад для вас.

Еще один рабочий день подошел к концу. И вот, сидя перед монитором с кружкой теплого чая и читая любимый Хабр, кто-то ищет развлекательные посты, кто-то хочет узнать что-то новое и полезное. Есть люди которым интересно как работают другие команды и какая у них организация. А есть те кто весь день задается вопросом — почему меня окружают клинические идиоты.

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

А правильно ли поставлен вопрос? И кто виноват?

Давайте разбираться

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

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

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

О важности игрового прототипа мы говорили в предыдущей статье.

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

Приступаем.

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

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

Этот документ разделён на пять частей:

1. Как звук влияет на производительность
2. Разбираемся с параметрами импорта
3. Рекомендуемые мной параметры для PC и консолей
4. Рекомендуемые мной параметры для мобильных платформ
5. Предостережения и замечания

Оптимизация параметров импорта звука Unity — один из простейших способов оптимизации. В случае небольшого проекта у вас может уйти меньше часа для достижения значительных улучшений во времени загрузки, занятой ОЗУ и других аспектах производительности. Надеюсь, это руководство окажется полезным для вас. Информация актуальна для Unity версии 2018.3

Всем привет!

Пришла зима, а с ней и задача проверить теплоизолирующие свойства построек загородной резиденции дачи. А тут ещё оказалось, что на известном китайском сайте появились вполне доступные тепловизионные модули. Не собрать ли себе экзотическую и, возможно, даже полезную вещь — самодельный тепловизор? Почему бы и нет, вроде и Raspberry где-то валялась… Что из этого вышло — расскажу под катом.

Введение

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

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

Что же такое «игровой ИИ»?

Игровой ИИ в основном занимается выбором действий сущности в зависимости от текущих условий. В традиционной литературе по ИИ называет это управлением "интеллектуальными агентами". Агентом обычно является персонаж игры, но это может быть и машина, робот или даже нечто более абстрактное — целая группа сущностей, страна или цивилизация. В любом случае это объект, следящий за своим окружением, принимающий на основании него решения и действующий в соответствии с этими решениями. Иногда это называют циклом «восприятие-мышление-действие» (Sense/Think/Act):

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

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

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

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

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

В Unity3D с выходом версии 2018 появилась возможность использовать нативную (для Unity) ECS систему, сдобренную многопоточностью в виде Job System. Материалов в интернете не особо много (пара проектов от самих Unity Technologies да пара обучающих видео на ютубе). Я попробовал осознать масштаб и удобность ECS, сделав небольшой проект не из кубов и кнопок. До этого у меня не было опыта проектирования ECS, так что два дня ушло на изучение материалов и перестроение мышления с ООП, день ушел на восхищение подходом, и еще один-два дня — на разработку проекта, борьбу с Unity, выдергивание волос и курение семплов. В статье содержится немного теории и небольшой пример проекта.

Введение

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

Объяснение

Что же такое hitbox и hurtbox? Разве это не одно и то же?

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

Hitbox — это невидимый прямоугольник (или сфера), определяющий, куда попадает атака.

Hurtbox — это тоже невидимый прямоугольник (или сфера), но определяющий место, в которое игрок или объект может ударить с помощью Hitbox.


На этом изображении из Street Fighter IV красный прямоугольник — это hitbox, а зелёный — hurtbox

Для трассировки лучей (ray tracing) настали удивительные времена. Компания NVIDIA реализует ускоренное с помощью ИИ шумоподавление, Microsoft объявляет о нативной поддержке в DirectX 12, а Питер Ширли продаёт свои книги по свободной цене (pay what you want). Похоже, что трассировка лучей наконец получила шанс быть принятой при дворе. Возможно, говорить о начале революции ещё слишком рано, но уже определённо стоит начать изучать и накапливать знания в этой области.

В этой статье мы напишем с нуля в Unity очень простой трассировщик лучей с помощью compute shaders. Скрипты мы будем писать на C#, а шейдеры — на HLSL. Весь код выложен на Bitbucket.

В результате у нас получится отрендерить нечто подобное:

Первый прототип (например, игры в новой для вас нише) часто делается «на коленке» из палок и самизнаетечего. Причем палки, как правило, тоже из этого самизнаетечего. И на то есть несколько причин.

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

Забегу вперед и расскажу, что сейчас DAU в наших проектах около 1,5 млн. Но так было не всегда.

Как в блогах, так и в журналах есть множество статей о том, как собрать NAS своими руками.
И с первого взгляда кажется, что при наличии прямых рук, свой NAS по всем пунктам бьёт покупное решение.
"Фигак, фигак и в продакшн", — и вот уже быстро, дёшево и качественно реализованное хранилище радует вас высокой производительностью и надёжностью.