Всем привет! Данная статья — об игровых интерфейсах и порядку работы с ними. Она предназначена в первую очередь для тех, кто работает в игровой индустрии и в том или ином виде влияет на разработку интерфейса, но при этом сам не является UI/UX специалистом. Проект-менеджеры, продюсеры, геймдизайнеры, программисты, работающие с GUI, художники — я писал этот текст, думая о вас, ребята.

[В туториале около 50 МБ изображений, в том числе анимированных GIF]

Чтобы рассказать часть сюжета игры или увлечь игрока, разработчики часто используют катсцены. В некоторых играх создают специально отрендеренные анимированные сцены с моделями высокой детализации, в других же применяют настоящие внутриигровые модели. Благодаря использованию внутриигровых моделей можно сэкономить много средств и времени, потому что вам не придётся создавать новые модели, риги и анимации исключительно для катсцен. Но даже если вы используете уже готовые модели, то это не означает, что нужно жертвовать спецэффектами или драматизмом! В Unity есть мощный инструмент, позволяющий создавать захватывающие катсцены — Unity Timeline!

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

Приступаем к работе

Скачайте проект-заготовку и готовый проект отсюда.

Откройте файл Starter Project и загрузите сцену Main. Она будет нашим фундаментом. В ней есть герой, стоящий на башне и глядящий на мир:


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

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

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

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

Можно сказать, что девиз почти всех инди-разработчиков — это «Большие мечты при ограниченных ресурсах». Когда я начал работать над первой игрой Motion Twin для Steam Dead Cells, эта фраза стала и моим девизом.

Меня зовут Тома Вассёр, в течение целого года я был единственным художником Dead Cells. Я занимался дизайном и анимациями каждого аспекта игры. В одиночку мне пришлось создавать графический стиль, персонажей, монстров, анимации, спецэффекты (FX) и большинство фонов Dead Cells… Пока, к счастью, мне на помощь не пришёл мой злой брат-близнец Генель Массе. Количество художников Dead Cells удвоилось.

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

7–8 апреля в Контуре был открытый хакатон — 27–часовой марафон по программированию. Разработчики, тестировщики, дизайнеры и проектировщики интерфейсов собрались, чтобы штурмовать задачи. Только темой стали не рабочие проблемы, а игры.

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

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

Не знаю, что я сделал, но это со мной селфятся?

Это вторая часть истории (вперемешку с рассказом о моих ошибках и их решениях) о том, как я (где-то два года в свободное время) разрабатывал мобильное приложение (под iOS/Android), которое бы мотивировало мою дочь решать примеры по математике. В итоге, получилось приложение, позволяющее ребёнку зарабатывать деньги своим умом.

Первую часть читайте тут.

План второй части

• О написании кода
• О контроле версий
• Об озвучке
• Об иконке
• О сборке под Android и о размере
• О сборке под iOS и о размере
• О названии и продвижении
• Статистика
• О чём жалею
• Что понял
• Ссылки

Мелочи в программировании, которые упрощают мне жизнь

• Ещё с Mono продолжаю использовать //TODO (в комментариях) для отметок мест, которые нужно доработать. Потом, все эти места можно удобно мониторить на закладке Task List (вызывается Ctrl+\, T):

Это первая часть истории (вперемешку с рассказом о моих ошибках и их решениях) о том, как я (где-то два года в свободное время) разрабатывал мобильное приложение под iOS и Android, которое бы мотивировало мою дочь решать примеры по математике, чтобы она достигла автоматизма в основах арифметики (склад числа 10 или табличка умножения). В итоге, получилось приложение, позволяющее ребёнку зарабатывать деньги своим умом.

Использовал я движок Unity и язык C#, а также дополнительный набор софта вроде обязательного Photohsop или Audacity (для создания звуков).

План рассказа (часть первая)

• Предыстория
• О монетизации
• Почему Unity
• О Scriptable Objects
• О плагине Anima2D
• О Lean Localization
• Об iTween
• О Unity Analitics
• О Visual Studio
• Ссылки

Предыстория и колорадские жуки

Мой предыдущий опыт — это несколько лет в 3D и, с недавних пор, разработка нескольких инди-игр на пару с программистом, где я выступал в основном только в роли дизайнера и художника (очень редко пописывая какие-то элементарные скрипты на C#). Хотя, с программированием знаком не понаслышке (колупал Basic в школе и баловался с C/C++ в универе).

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

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

На рынке есть куча инструментов для ревью кода с готовыми сценариями использования, рекомендациями и правилами. GitHub, Phabricator, FishEye/ Crucible, GitLab, Bitbucket, Upsource — список можно долго продолжать. Мы в Badoo тоже в своё время с ними работали: в своей предыдущей статье  я рассказывал нашу историю ревью кода и о том, как мы пришли к изобретению собственного «велосипеда» — решения Codeisok.

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

Именно поэтому другую часть айсберга можно и не заметить.

Промышленный музей в Бад-Кёзене, Германия — заводик XVIII века по выкачиванию из недр минерализованной воды для последующей добычи из нее соли. Энергию вырабатывает водяное колесо на реке, соленую воду выкачивает насос и подает на градирню.

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



На заднем плане — градирня, на переднем — качающиеся опоры деревянной линии передачи энергии.

В видео опоры качаются начиная с 1:10

Об экспериментах с компьютерной голографией писалось неоднократно. [1, 2, 3] Мне эта тема просто любопытна. Я как-то экспериментировал с бит-реверсивной перестановкой (bit-reversal permutation) изображений и случайно обнаружил голографические свойства. Но обо всем по порядку.

В этой статье хочу рассказать о подходе к сборке Unity-проектов на android и ios через Gitlab на собственных сборщиках с macOS.

Я работаю в небольшой gamedev компании, и задача автоматизации сборки появилась из-за следующих проблем:

• 5 распределенных команд должны собирать проекты из любой точки мира
• должны поддерживаться разные версии юнити
• сборщик должен обеспечивать как минимум 5 сборок в неделю от каждой команды
• сертификаты должны храниться централизованно, а не у разработчиков
• собранные билды должны быть доступны по ссылке в любой точке мира
• проекты должны проверяться на наличие обязательных библиотек (рекламные sdk и коды, локализация, сохранения)
• конфигурирование сборки для команд должно производиться в одном месте

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

Привет Хабр! Я хочу рассказать как сделать шейдер для отрисовки щита космического корабля в Unity3D.


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

Заинтересовавшихся прошу под кат. (Осторожно! Внутри тяжелые картинки и гифки).

Фрагмент официального постера к игре A Blind Legend.

Объёмный бинауральный звук из наушников создает эффект присутствия и заставляет мозг игрока дорисовывать «графику». Аудиоквесты, звуковые RPG и «слепые» шутеры продаются в GooglePlay, iTunes и Steam по цене от 2$ до 20$. Тем любопытнее, что в России звуковые игры и интерактивные аудиокниги — пустующая ниша, где пробуют себя единицы. Что это за невидимый рынок, кому он нужен и как к нему подступиться — выясняла автор GeekBrains Мария Лисянская.

Всем привет! Решил поделиться своим опытом по добавлению игры в Google Play Console и настройке Play Games Plugin для Unity.

Начнем мы с настройки Unity.

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

Чем больше узнаёшь в своей области знания, тем чётче понимаешь, что никто не может знать всего.

По какой-то причине (за что, господи, за что?) моей областью стала разработка игр. Каждый, кто работает в этой сфере, скажет вам: никогда не добавляй сетевой многопользовательский режим в уже готовую игру, никогда, пьяный ты клоун.

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

Проблема №1: ресурсы

Первый вопрос, который у меня возник: как сказать клиенту, что для рендеринга объекта нужно использовать такой-то меш?

Сериализировать весь меш? Не стоит, у клиента он уже есть на диске.

Передавать имя файла? Не-а, малоэффективно и небезопасно.

Ну ладно, может быть, просто строковый идентификатор?

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

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