Создание связи игрока с персонажем, раскрытие подробностей его личности, чтобы он был для игрока уникальным — сложная задача, и как решить её всего несколькими простыми движениями?

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

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

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

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

Часть 6. Sharpen

В этой части мы подробнее рассмотрим ещё один эффект постобработки из The Witcher 3 — Sharpen.

Sharpening делает изображение на выходе немного чётче. Этот эффект известен нам по Photoshop и другим графическим редакторам.

В The Witcher 3 у sharpening есть две опции: low и high. О разнице между ними я расскажу ниже, а пока давайте взглянем на скриншоты:


Опция «Low» — до


Опция «Low» — после

Какое отношение к легаси-коду имеют «Звёздные войны», группа «Тату» и сочетание «Ctrl-Alt-Del»? Как быть, когда приходишь в большой проект и сталкиваешься с пропастью непонятного старого кода? И как эффективнее донести до начальства, что трудозатраты на ликвидацию технического долга оправдывают себя?

Доклады Дилана Битти не обходятся без шуток, но эти шутки сопровождают вполне серьёзные рассуждения о главных вопросах разработки. Такое хорошо подходит для завершения конференции: когда зрители уже услышали много хардкора и больше не могут воспринимать слайды с кодом, самое время для более общих вопросов и яркой подачи. И когда нашу .NET-конференцию DotNext 2018 Moscow завершало выступление Дилана про легаси-код, зрителям оно понравилось сильнее всего.

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

Rise of the Tomb Raider (2015 год) — это сиквел превосходного перезапуска Tomb Raider (2013 год). Лично я нахожу обе части интересными, потому что они отошли от стагнирующей оригинальной серии и рассказали историю Лары заново. В этой игре, как и в приквеле, центральное место занимает сюжет, она предоставляет увлекательные механики крафтинга, охоты и скалолазания/исследований.

В Tomb Raider использовался разработанный Crystal Dynamics движок Crystal Engine, также применявшийся в Deus Ex: Human Revolution. В сиквеле использовали новый движок под названием Foundation, ранее разрабатывавшийся для Lara Croft and the Temple of Osiris (2014 год). Его рендеринг можно в целом описать как тайловый движок с предварительным проходом освещения, и позже мы узнаем, что это означает. Движок позволяет выбирать между рендерерами DX11 и DX12; я выбрал последний, по причинам, которые мы обсудим ниже. Для захвата кадра использовался Renderdoc 1.2 на Geforce 980 Ti, в игре включены все функции и украшательства.

Анализируемый кадр

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

Привет, Хабр! Сегодня для .NET-разработчиков у нас традиционный пост по следам DotNext 2018 Moscow: делимся десятью лучшими докладами конференции (по мнению её посетителей). Под катом — их видеозаписи, а также короткие описания и ссылки на презентации.

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

Приложения ASP.NET Core по-настоящему кросс-платформенны и могут запускаться в «никсах», а соответственно, и в Docker. Посмотрим, как их можно упаковать, чтобы развертывать на Linux и использовать в связке с Nginx. Подробности под катом!

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

Введение

Алгоритм был написан как часть работы на получение степени бакалавра и основан на статье Ma et al (2014). Целью работы было ускорение алгоритма и дополнение его новыми функциями. Я вполне доволен результатом, потому что мы сделали алгоритм достаточно быстрым, чтобы использовать его во время выполнения игры. После завершения бакалаврской работы мы решили превратить её в статью и отправить на конференцию Game-ON 2018.

Алгоритм

Для создания уровня игры алгоритм получает в качестве входных данных набор полигональных строительных блоков и граф связности уровня (топологию уровня). Узлы графа обозначают комнаты, а рёбра определяют связи между ними. Цель алгоритма — назначить каждому узлу графа форму и расположение комнаты таким образом, чтобы никакие две формы комнат не пересекались, и каждая пара соседних комнат могла соединяться дверьми.

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

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



Есть только два фактора, которые определяют любое текущее состояние игры: механика (правила) и игроки своими действиями.

Уровень ядра

Такт 1: определение состояния
Всегда есть некое текущее состояние системы (например, начало хода). Оно определяется на первом такте инициализирующей последовательностью, когда игроки «загружают» игру, раскладывая поле, выбирая фишки, распределяя начальные ресурсы и так далее. Затем оно меняется в зависимости от происходящего в игре.

Встречали ли вы в C# конструкцию типа using (var scope = new TransactionScope(TransactionScopeOption.Required))? Это значит, что код, выполняющийся в блоке using, заключается в транзакцию и после выхода из этого блока изменения будут зафиксированы или отменены. Звучит понятно, пока не начинаешь копать глубже. И чем глубже копаешь, тем «страньше и страньше» становится. Во всяком случае, у меня при более близком знакомстве с классом TransactionScope и вообще транзакциями .NET возникла целая уйма вопросов.

Что за класс TransactionScope? Как только мы используем конструкцию using (var scope = new TransactionScope()), все в нашей программе сразу становится транзакционным? Что такое «управляющий ресурсами» (Resource Manager) и «управляющий транзакциями» (Transaction Manager)? Можно ли написать свой управляющий ресурсами и как он «подключается» к созданному экземпляру TransactionScope? Что такое распределенная транзакция и правда ли, что распределенная транзакция в SQL Server или Oracle Database — это то же самое, что и распределенная транзакция .NET?

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

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

Введение

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

Я начинал карьеру как 3D-художник ещё в эпоху первой PlayStation, а позже стал программистом графики. Хотел бы я прочитать эту статью перед тем, как впервые начал создавать 3D-модели для игр. Рассмотренные в ней фундаментальные основы пригодятся многим художникам. Хотя бОльшая часть информации из этой статьи не повлияет значительно на продуктивность вашей ежедневной работы, она даст вам базовое понимание того, как графическая карта (graphics processing unit, GPU) отрисовывает создаваемые вами меши.

От количества полигонов в меше обычно зависит скорость его рендеринга. Однако несмотря на то, что количество полигонов часто коррелирует с частотой кадров в секунду (FPS), вы можете обнаружить, что даже после снижения количества полигонов меш по-прежнему рендерится медленно. Но поняв, как рендерятся меши в целом, вы сможете применить набор техник для повышения скорости рендеринга.

Гарет Харвуд — технический арт-директор Playground Games

Действие Forza Horizon 4 происходит в прекрасной Британии, заполненной мгновенно узнаваемыми местами и достопримечательностями, в том числе и моделью города Эдинбурга в версии Playground Games.

В большинстве игр с открытым миром особое внимание нужно уделять скорости потоковой передачи данных, иForza Horizon 4 с её детализированным и пёстрым городом не стала исключением. Для отрисовки зданий Эдинбурга необходимы были новые возможности сборки ресурсов, рендеринга, а также функционал движка, позволяющий загружать модели при движении со скоростью 300 миль в час.

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


Внимание, под катом скриншоты 16+!

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

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

«Я не подходила ни под одно из описаний симптомов апноэ, — рассказала она мне по телефону. – Я женщина, у меня нет лишнего веса. Никому не приходило в голову проверить меня, кроме одного доктора, у которого была сходная история болезни».

Линн, живущая в сельской местности Аризоны, провела дома пульсоксиметрию, измеряющую уровень кислорода в крови, а потом прошла исследование сна. Ей поставили диагноз апноэ, заболевания, из-за которого пациенты внезапно перестают дышать во сне на некоторое время, и которое чаще всего преследует мужчин с лишним весом. Ей выдали СИПАП-машину (аппарат для искусственной вентиляции лёгких постоянным положительным давлением) с маской – это устройство задувает воздух в дыхательное горло, чтобы воздушные пути оставались открытыми – и отправили домой.

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

«Бум, бум, бум», стреляет дробовик, целясь… похоже, что в никуда? На земле лежит плазмаган, а справа летит призрак, но перед игроком нет врагов, а призрака хоть и можно убить, игрок в него не целится. И это мировой рекорд в Spelunky (сверяется со своими записями) по набору наибольшего количества денег? А часть, от которой люди в восторге, включает в себя стрельбу из дробовика в пустое пространство? Хм.

TL;DR

Я создал демо, показывающее, как реализовать прогнозирование на стороне клиента физического движения игрока в Unity — GitHub.

Введение

В начале 2012 года я написал пост о как-бы-реализации прогнозирования на стороне клиента физического движения игрока в Unity. Благодаря Physics.Simulate() тот неуклюжий обходной способ, который я описал, больше не нужен. Старый пост до сих пор является одним из самых популярных в моём блоге, но для современного Unity эта информация уже неверна. Поэтому я выпускаю версию 2018 года.

Что-что на стороне клиента?

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

Привет!

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



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

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

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

Поэтому мы делаем вот что в ИТ:

1. Устанавливаем режим feature freeze. Любой следующий релиз в феврале. Хотфиксы — только если это major bug, причём, желательно, несколько сразу.
2. Больше касс на каждый инстанс. Нужны как физические места под новые кассы, так и сами терминалы на случай замены. Причём в каждом магазине должен быть как минимум один энергонезависимый.
3. Где-то в октябре собираем все сломанные системные блоки с розницы (они их обычно складывают у себя на складах в подсобках и берут оттуда горячую замену) и собираем из трёх поломанных два работающих. Они нужны на временные магазины и на замену. Закупаются новые расходники, в частности, мыши и клавы.

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

Сегодня, в девятой части перевода руководства по JavaScript, будет сделан обзор возможностей, которые появились в языке благодаря стандартам ES7, ES8 и ES9.

→ Часть 1: первая программа, особенности языка, стандарты
→ Часть 2: стиль кода и структура программ
→ Часть 3: переменные, типы данных, выражения, объекты
→ Часть 4: функции
→ Часть 5: массивы и циклы
→ Часть 6: исключения, точка с запятой, шаблонные литералы
→ Часть 7: строгий режим, ключевое слово this, события, модули, математические вычисления
→ Часть 8: обзор возможностей стандарта ES6
→ Часть 9: обзор возможностей стандартов ES7, ES8 и ES9