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

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

Человек работающий и музыка

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

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

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

Я люблю графические отладчики. Обычные я тоже люблю, но графические — больше. Они дают ощущение сродни заглядыванию за кулисы театра во время выступления: «ага, вот эта декорация крепится так, а этот луч света падает отсюда, а у этого шкафа нет задней стенки...». Графический отладчик пробрасывает мостик понимания между текстовым кодом приложения и полученной красивой картинкой.

Но индустрия не балует нас обилием подобного инструментария. Есть графические отладчики от Intel, NVidia и AMD, но они не работают на чипах конкурентов и предназначены не столько для разработки\отладки, сколько для бенчмарков и хвастовства своими видеокартами. Они неплохо рассказывают ЧТО и КОГДА произошло, но плохо объясняют ПОЧЕМУ и КАК ИСПРАВИТЬ.

В другом лагере находится мой любимый RenderDoc, о котором я уже писал. Прекрасная утилита, написанная ребятами из Crytek для себя и людей. Открытый код, поддержка всех вендоров, DirectX11 (с планами на Вулкан и DirectX12), куча мелких полезных мелочей.

Вторым представителем когда-то был PIX — утилита для анализа производительности DirectX9. Задумывалась она как инструмент для разработки под XBox (само название это аббревиатура от Performance Investigation for XBox), но хорошо работала и для десктопных приложений. До того момента, пока не умерла (с выходом DirectX 10/11 и новых версий Windows). Microsoft, у которого в очередной раз маркетологи победили инженеров, объявил единственным инструментом для графической отладки Visual Studio, в которой именно для этих целей было много лишнего, многого не хватало, а кое-что было и вовсе невозможно. Студия — прекрасный инструмент для программирования, но далеко не столь хорошая вещь для изучения, профилирования и отладки графического кода (тем более чужого).

Всё это уныние продолжалось несколько лет, пока инженеры Microsoft не одержали временную победу и в январе 2017 года Microsoft объявила о запуске беты полностью обновлённой версии PIX для DirectX 12!

Давайте же посмотрим, что мы получили.

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

Библиотека UX Pin

«Web Design Trends 2017»
Очередной выпуск из серии изданий о современных трендах. Описываются и препарируются практики от таких ведущих компаний, как Paypal, Adidas, Starbucks, Facebook, Spotify, Fitbit, Google и Dropbox – всего 61 пример, с подробным разбором для каждого.

→ Скачать

«Interaction Design Best Practices»
Шесть глав о том, как создавать отзывчивый дизайн, с которым пользователю легко взаимодействовать. В качестве иллюстраций к теоретическому материалу приводятся кейсы от крупных IT-компаний (MailChimp, Mint, Apple, KickStarter, Google, AirBnB, Netflix).

→ Скачать

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



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

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

Finite State Entropy (FSE) – алгоритм энтропийного кодирования, чем-то похожий и на алгоритм Хаффмана, и на арифметическое кодирование. При этом он взял лучшее от них обоих: работает так же быстро, как хаффмановский, и со степенью сжатия как у арифметического кодирования.

FSE принадлежит семейству кодеков ANS (Asymmetric Numeral Systems),  изобретённых Яреком Ду́дой. На основе его исследований Ян Колле разработал оптимизированный вариант алгоритма, впоследствии названный FSE.

В заметках Яна Колле непросто разобраться, поэтому я изложу объяснение в несколько ином порядке, более удобном для понимания, на мой взгляд.

Другие статьи цикла:
Хроники лаборатории: как мы молотый кофе считали софтом для анализа клеточных структур
Компот из кофейных сухофруктов. Знакомимся с каскарой — лучшим другом велосипедиста

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

На Хабре/Гиктаймсе уже не раз обсуждался кофе и все, что с ним связано. Я решил написать пост, посвященный этому напитку и различным эффектам кофеина с медицинской точки зрения. Если хватит времени — возможно это будет цикл статей с экспериментами над людьми, computer vision и прочим непотребством. Увидим. А пока, товарищи кофеиноманы и им сочувствующие, добро пожаловать под кат.

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

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

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

Дэвид Хэнссон, создатель Ruby on Rails, признался в своём твиттере, что не написал бы сортировку пузырьком на доске. Дэвид подсматривает код в интернете всё время:

Около месяца назад я обнаружил себя разговаривающим по видеосвязи с Joel Spolsky (автор известного блога «Joel on Software», со-основатель Stack Overflow — прим. перев.). Даже сейчас кажется абсурдным писать подобное. Долгое время, на протяжении всей своей карьеры, я регулярно читал Joel Spolsky, и во многом сходился с ним во взглядах на разработку. И вдруг общаюсь лицом к лицу.

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

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

int main()
{
    unsigned i = 0xDEADBEEF;
    std::cout << "address of i is " << std::hex << &i;
    std::cin.get(); //Чтобы процесс не завершился
    return 0;
}

Затем попробуем найти физический адрес и просмотреть значение по этому адресу.

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

От экрана дизайнера к экрану игрока

Карты разрабатывались дизайнером уровней в 2D с помощью редактора Doom Editor (DoomED). LINEDEFS описывали замкнутые секторы (SECTORS в исходном коде), а третье измерение (высота) указывалась посекторно. Первый уровень Doom E1M1 выглядит так:



После завершения работы над картой она нарезается методом двоичного разбиения пространства (Binary Space Partitioning, BSP). LINEDEF рекурсивно выбирались и их плоскости превращались в секущие плоскости. То есть LINEDEF разрезались на сегменты (SEGS) до тех пор, пока не оставались только выпуклые подсектора (SSECTOR в коде).

Интересный факт: И DoomED, и iBSP писались на… Objective-C на рабочих станциях NextStep. Пятнадцать лет спустя тот же язык почти в той же операционной системе выполняет игру на мобильном устройстве! [прим. пер.: в 2010 году Doom вышел на iPhone] Я немного поработал веб-археологом и мне удалось найти исходный код idbsp. На него стоит посмотреть.

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

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

Все программное обеспечение разбито на три группы:

• Программное с открытым исходным кодом
• Бесплатное программное обеспечение с ограниченным функционалом
• Программное обеспечение бесплатное в течении пробного периода

Привет, Хабр!

Меня зовут Артём Титов, я lead gameplay programmer в Larian Studios.
Мы очень давно хотели поделиться с вами нашим опытом создания и разработки компьютерных игр, но долго не могли решить, с чего бы начать. Долго размышляя, мы пришли к выводу, что первая статья должна быть не технической, а скорее личной — и для этого я перевёл вам запись в блоге одного из наших сотрудников, сделанную около года назад. Его история даёт очень хорошее представление не только о нашей студии со стороны игр, что мы создаём, но и детально показывает личный аспект жизни рядового сотрудника студии, проходящей через падения и взлёты. Я постарался сделать наиболее точный перевод, но тем не менее полностью от англицизмов и слэнга избавиться не смог.

Итак под катом история моего коллеги длиной в 10 лет.

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



Во многих процедурных генераторах карт, в том числе и некоторых моих предыдущих проектах, для генерирования карты высот используются функции шума (midpoint displacement, фракталы, diamond-square, шум Перлина и т.д.). Здесь я их не применял. Вместо неё я использовал структуру графов для моделирования элементов, определяемых ограничениями геймплея (высота, дороги, течение рек, места квестов, типы монстров) и функции шума для моделирования того, что не ограничивается геймплеем (форма побережья, расположение рек и деревьев).

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



Лектор – Софья Геннадьевна Кисельгоф, младший научный сотрудник Международной научной лаборатории анализа и выбора решений НИУ ВШЭ. Преподаватель департамента математики экономического факультета. На факультете компьютерных наук читает курс Operations Research and Game Theory. Защитила кандидатскую диссертацию на тему «Обобщенные паросочетания при предпочтениях, не являющихся линейными порядками». Софья Геннадьевна проводила исследование механизма зачисления абитуриентов в российские вузы в результате которого была построена модель, описывающая поведения абитуриента при выборе вуза.

Под катом – подробная стенограмма лекции.

Сегодня День защитника Отечества! Всех сопричастных с праздником! Бойцам несущим службу в Вооруженных силах РФ — неизбежного дембеля. А для тех, кто не служил или только собирается отдать долг Родине, под катом любопытный рассказ про умные железяки. Не исключено, если вы шарите в технике, компьютерах и ПО, вам посчастливится не только оттрубить в штабе писарем, но и к чему-нибудь из описанного ниже прикоснуться. Ну и надеюсь, что меня не загребут за разглашение всяческих там государственных секретов.

В 1998 году Looking Glass Studios выпустила стелс-игру Thief: The Dark Project. В то время аппаратное 3D-ускорение только зарождалось, поэтому в процессе разработки оно не использовалось, игра рендерилась только программно.

Я был основным автором базовой технологии рендеринга Thief (хотя я и не писал рендереры объектов и персонажей), а также связанных с ней элементов. Тот же движок рендеринга, модифицированный другими людьми для использования аппаратного 3D-ускорения, также использовался для рендеринга System Shock 2 и Thief 2.

Движок был написан примерно в одно время с Quake (хотя игра вышла намного позже), и общий внешний вид сильно напоминает Quake. Многие технологии были скопированы из Quake или вдохновлялись им, но часто их работа немного или значительно отличалась.