Я всегда начинаю с того, что задаю много вопросов и провожу активные исследования. За свою карьеру я успел поработать над множеством сиквелов уже существовавших франшиз. Лучшее, что ты можешь сделать в этом случае — полностью освоить жанр игры и изучить мир. Среди прочих проектов, мне приходилось с головой нырять в Halo, StarWars, Hellboy и Division. Хорошие гейм-дизайнеры — это хорошие исследователи.

Naughty Dog мастерски реализовала The Last of Us: Left Behind, и прежде чем браться за этот проект, мне нужно было хорошо подготовиться. Если вы не играли в Last of Us, то сыграйте! Это одна из самых потрясающих историй и несравненный пример развития персонажей. Другие разработчики очень многому могут научиться у создателей этой игры. Из-за сильного упора на повествование Naughty Dog называет свои дизайн-документы миссий «набросками глав». Мне кажется, это очень милый штрих. Это заставляет больше думать о повествовании при создании контента и придавать дизайну более сюжетную структуру.

Предупреждение — в статье содержатся спойлеры Last of US и Last of Us DLC.

Скриншот из Queen's Wish. Учтите, что я использую игровой арт, который мне нравится. Это необходимо, потому что потом придётся смотреть на него годами, и я не хочу сойти с ума.

Неделю назад я опубликовал в блоге пост «Почему все мои игры выглядят так отстойно» (оригинал). Он оказался ужасно популярным, его прочитало множество людей. Некоторые поддерживали меня. Другие потратили драгоценное время своей жизни на то, чтобы сообщить мне, что я ужасный тупица.

Спасибо всем! Когда пытаешься привлечь внимание к инди-игре, то плохой славы не бывает.

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

Я получил много вопросов. Хороших вопросов. Почему я не могу позволить себе арт-директора? Сколько стоит графика? Почему бы не сделать то или это? Поэтому я решил написать ещё один пост. Я хочу ответить на хорошие вопросы.

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

Видите ли, я самый большой жмот на рынке инди-игр.

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

Я уже 25 лет зарабатываю на жизнь написанием инди-игр. У нас с женой есть небольшой семейный бизнес. Мы создаём низкобюджетные ролевые игры в ретро-стиле с отличным сюжетом, дизайном и геймплеем.

Но все они выглядят как куча навоза.

Первая моя игра, выпущенная в январе 1995 года, тоже выглядела ужасно. Она достигла финансового успеха (очевидно, среди слепых людей), благодаря чему мне удалось профинансировать много других ужасно выглядящих игр и создать себе солидную репутацию.

Благодаря этой репутации мы провели на Kickstarter успешную кампанию по сбору средств на Queen's Wish: The Conqueror — потрясающую RPG, которая тоже будет выглядеть чудовищно. Мы надеемся, что она станет фундаментом для дальнейшего создания ужасно выглядящих игр.

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

Самое главное заключается в том, что я хочу защитить право инди-разработчиков быть странными. Если у инди-разработчика появится безумная, творческая идея, и он испугается её реализовать, но подумает: «Это можно и сделать; по крайней мере, я не настолько сумасшедший, как Джефф Вогель», то я буду считать свою миссию выполненной.

Итак, если вам интересно, почему мы пишем игры, которые выглядят и ВСЕГДА будут выглядеть как куча навоза, то продолжайте чтение.

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

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

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

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

NB! Значительная часть статьи — это копипаста из конфы проекта без особой обработки. Это сделано специально, чтобы показать настоящие воркфлоу и рабочие материалы, а не их вылизанные для публичного доступа версии.

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

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

О чем будет в этой статье

Я хочу раскрыть на конкретных примерах следующие моменты:

1. Почему второй слой разработки?
2. Отзывчивость интерфейса
3. Микроанимации
4. Визуальная логика

Рассмотрим на примере в том числе и этого проекта

На Reddit я видел множество дискуссий, комментариев и вопросов о том, чем определяется успех игры. Насколько важно качество? Действительно ли единственным определяющим аспектом является большая известность игры на рынке до её выпуска? Помогают или вредят демо-версии? Если показатели игры при выпуске оказались плохими, то какова вероятность их исправления? Можно ли хотя бы приблизительно предсказать объёмы продаж игры до её выпуска?

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

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

Сначала примечания по данным:

• Один из важнейших источников данных — количество обзоров в Steam. Есть достоверные свидетельства того, что оно сильно коррелирует с количеством проданных копий, часто упоминаются соотношения «50 продаж на один обзор в Steam», но диапазон значений довольно широк. Похоже, большинство игр Steam попадает в интервал от 25 до 120 продаж на один обзор на Steam, но случаются и выбросы. Кроме того, игры с очень малым количеством обзоров с большей вероятностью в этом отношении будут выбросами. Моя игра — единственная, по которой у меня есть чёткие цифры продаж. Можете прочитать мой длинный пост о её релизе на Reddit, но самое важное для нас то, что я продал 1587 копий за первую неделю и 3580 копий за первый квартал.
• Общее количество игр в выборке: 115.
• Я выбирал игры полуслучайно, из разделов Popular Upcoming и All Upcoming. Это склоняет выборку больше в сторону популярных игр, и я сделал так намеренно: мне хотелось иметь разнообразную выборку, но чтобы в ней не доминировали полностью игры с нулевыми продажами.
• Игры упорядочены по дате выпуска, которая находится в интервале от 26.10.18 до 20.12.18.

Хорошо известно, что Джон Ромеро — геймдизайнер Doom и Quake. Но о том, что он делал до этих суперхитов, знают куда меньше. Какой путь привёл к таким успешным играм? С чего всё началось, как от любительского перешло к профессиональному, что служило источниками вдохновения?

Конечно, ранние игры Ромеро не могут похвастаться мощью Doom. Но поскольку его карьере больше трёх десятилетий, проследить за такой с самого начала — это целый экскурс в историю, показывающий, как игровая разработка в 80-х отличалась от наших дней. В каких условиях люди создавали классические игры, которые востребованы до сих пор? Чем сегодняшние условия отличаются?

О том, как шла работа над Doom, Ромеро сам расскажет на нашем фестивале TechTrain в Петербурге. А мы пока что расскажем о том, что этому предшествовало.

На этой неделе я начал работать над новой темой: генерацией подземелий и пещер. Я использовал разбиение пространства для генерации комнат, алгоритмы генерации лабиринтов для генерации коридоров и клеточные автоматы для придания пещерам более естествненного внешнего вида.

Разбиение пространства

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

Способов разбиения пространства тоже очень много: разделение на сетки, двоичное разбиение пространства, разбиение пространства деревом квадрантов, диаграммы Вороного и т.д. Я решил использовать двоичное разбиение пространства, потому что оно хорошо подходит для генерации прямоугольных комнат. Этот метод получил популярность благодаря статье на RogueBasin.

Единственная сложность этого алгоритма — выбор позиции разделения. Если мы не наложим ограничение на позицию разделения, то будем получать странные разбиения пространства:


Такого поведения можно избежать несколькими способами. Один из них — ограничить позицию разделения двумя соотношениями длин сторон, например, в интервале от 30% до 70% или от 40% до 60%. Другой способ — использовать вместо равномерного распределения нормальное или биномиальное, благодаря этому повысится вероятность разделения по центру стороны, а не по краям. Эти способы устраняют проблему, но сложно понять, как конкретно параметры влияют на окончательный результат.

Привет, Хабр! Представляю вам перевод статьи "What Does a Game Designer do?" автора Kai Wüest. Kai Wüest — продюсер из Исландии, работавший раньше тестировщиком, а затем — геймдизайнером.

День в роли геймдизайнера

Легендарный геймдизайнер. Человек, миф, легенда, стоящая за игрой. Источник вдохновения для юных мечтателей, желающих однажды работать в игровой индустрии. Но чем занимается геймдизайнер на самом деле? И как вам стать одним из них?

Раньше облака в играх рисовались обычными 2D спрайтами, которые всегда повернуты в направлении камеры, но последние годы новые модели видеокарт позволяют рисовать физически корректные облака без заметных потерь в производительности. Считается, что объемные облака в игры принесла студия Guerrilla Games вместе с игрой Horizon Zero Dawn. Конечно, такие облака умели рендерить и раньше, но студия сформировала что-то вроде промышленного стандарта на исходные ресурсы и используемые алгоритмы, и в настоящее время любая реализация объемных облаков так или иначе этому стандарту соответствует.

UPD. Картинка обновлена. Изменения описаны в конце статьи.

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

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

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

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

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

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

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

Сама по себе способность есть ни что иное, как набор действий. Минимальный интерфейс способности состоит из одного метода: «применить», но не всё так просто и о сложностях под катом.

Вам любопытно, как работает юнит-тестирование в Unity? Не знаете, что такое юнит-тестирование в целом? Если вы ответили положительно на эти вопросы, то данный туториал будет вам полезен. Из него вы узнаете о юнит-тестировании следующее:

• Что это такое
• Его польза
• Достоинства и недостатки
• Как оно работает в Unity при использовании Test Runner
• Как писать и выполнять юнит-тесты, которые будут проходить проверку

Примечание: в этом туториале предполагается, что вы знакомы с языком C# и основами разработки в Unity. Если вы новичок в Unity, то изучите сначала другие туториалы по этому движку.

Что такое юнит-тест (Unit Test)?

Прежде чем углубляться в код, важно получить чёткое понимание того, что такое юнит-тестирование. Если говорить просто, то юнит-тестирование — это тестирование… юнитов.

Юнит-тест (в идеале) предназначен для тестирования отдельного «юнита» кода. Состав «юнита» может варьироваться, но важно помнить, что юнит-тестирование должно тестировать ровно один «элемент» за раз.

Это статья-перевод Стэнфордского семинара. Но перед ней небольшое вступление. Как образуются зомби? Каждый попадал в ситуацию, когда хочется подтянуть друга или коллегу до своего уровня, а не получается. Причём «не получается» не столько у тебя, сколько у него: на одной чаше весов находится нормальная зарплата, задачи и так далее, а на другой — необходимость думать. Думать неприятно и больно. Он быстро сдаётся и продолжает писать код, совершенно не включая мозг. Ты представляешь, насколько много сил нужно потратить, чтобы преодолеть барьер выученной беспомощности, и просто не делаешь этого. Так образуются зомби, которых вроде бы можно вылечить, но вроде бы и никто этим заниматься не станет.

Когда я увидел, что Лесли Лэмпорт (да-да, тот самый товарищ из учебников) приезжает в Россию и делает не доклад, а сессию вопросов-ответов, я немного насторожился. На всякий случай, Лесли — всемирно известный учёный, автор основополагающих работ в распределённых вычислениях, а ещё вы его можете знать по буквам La в слове LaTeX — «Lamport TeX». Вторым настораживающим фактором является его требование: каждый, кто придёт, должен (совершенно бесплатно) заранее прослушать пару его докладов, придумать по ним минимум один вопрос и только тогда уже приходить. Решил посмотреть, что там Лэмпорт вещает — и это великолепно! Это в точности та штука, волшебная ссылка-таблетка для лечения зомбятины. Предупреждаю: от текста может знатно подгореть у любителей сверхгибких методологий и нелюбителей тестировать написанное.

После хаброката, собственно, начинается перевод семинара. Приятного чтения!

В преддверии 22-летия Duke Nukem вчера мы писали об истории игры. Сегодня поговорим о дизайне уровней официальных релизов основной серии игр Duke Nukem, не спин-офф и тем более не сторонних модификаций. По тексту тут и там разбросаны цитаты из нашего интервью с легендарным дизайнером Duke Nukem Ричардом Греем Levelord'ом, которое мы взяли у него специально для этого поста. Если вы заметили неточности или уверены, что мы пропустили что-то важное — пишите об этом в комментариях и мы добавим информацию в статью.

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

Мы запускаем цикл статей в которых подробно расскажем о каждой профессии через опыт людей. В первом выпуске обсуждаем Python-разработчиков. Свои истории рассказали Артем Сухаренко и Данила Лобанов. Они пришли в профессию совсем недавно, но успели набраться опыта в других сферах. А экспертом выступил Алексей Петренко — декан факультета Python в Geekbrains.

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

[Первая часть]

Разобравшись с основами, в этой части статьи мы реализуем такие эффекты, как контуры объектов, bloom, SSAO, размытие, глубина резкости, пикселизация и другие.

Контуры

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

Diffuse материала

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

uniform struct
  { vec4 diffuse
  ;
  } p3d_Material;

out vec4 fragColor;

void main() {
  vec3 diffuseColor = p3d_Material.diffuse.rgb;
  fragColor = vec4(diffuseColor, 1);
}

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

Доброго дня!

Немного об авторе: меня зовут Мария, начинающий гейм дизайнер. С этой статьи начинаем цикл статей по применению теории гейм дизайна в жизни. В этой статье попытаемся разобрать механику игры на примере Northgard от студии Shiro Games (находящуюся на стадии раннего доступа на момент написания статьи – прим.автора). Игра была анонсирована в Стиме 22 февраля 2017 года и представляет собой стратегию, с пошаговым завоеванием земель.

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