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

Для начала нам нужно ответить на вопрос: что же такое класс? Определение этого термина в играх достаточно расплывчато, и правильных ответов можно дать несколько. В таких RPG, как Dungeons & Dragons классы определяются правилами и представляют собой список способностей, которые может иметь персонаж игрока.

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

Поэтому при обсуждении классов мы говорим не только о стандартных классах и расах из RPG, но и об армиях в Starcraft, персонажах Street Fighter и даже машинах из Mario Kart. Кажется странным засовывать их всех в одну категорию, но у них у всех есть нечто общее: выбор, который игрок делает за пределами игры, определяет его возможности в игровом процессе.

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

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

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

Противники, одни из ключевых фигур, без которых та или иная игра может потерять свой смысл, а когда эти враги еще и монстры, то как раз они и создают ту атмосферу, которую вкладывают создатели. Тяжело представить Silent Hill без пирамидаголового, Outlast — без Криса Уокера и так далее, принцип понятен. Монстры — это собирательный образ врага в игре, это может быть не только уродливый демон или гигантские пауки, даже злобный сосед, как Hello Neighbor, является монстром, несмотря на облик человека.

Дойдя до этой части, читатель спросит:

“ А о чем собственно речь?

Цикл статей “ монстропедия “ ч.2

Зачастую разработчики прибегают к простым решениям для создания иллюзии разнообразия противников в игре. Перекрасить монстра, поменять цвет пламени, натянуть новую шкурку на старую тварь и добавить шипов/рогов/зубов/лап, но известная фраза гласит “старого пса не научишь новым трюкам”

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

Вы разработчик, что делать?

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

Задачи о размещении объектов

Электронные таблицы для этой части можно скачать здесь: (SuperTank) (телепорты, часть 1) (телепорты, часть 2)

SuperTank: задача решена!

В первой статье серии мы рассказали о примере задачи для игры под названием SuperTank. Во второй её части, мы познакомились с основными концепциями моделирования решений и я рассказал о решении простого примера с помощью инструмента «Поиск решений» в Excel.

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

Мы занимаемся поиском, а не итерациями

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

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

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

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

Позвольте начать эту статью, вкратце указав, о чем в ней не будет идти речь. Это не утомительный справочник по каждому монстру в Zelda: A Link to the Past и не всеобъемлющий обзор методов создания каждого класса противников. Это, скорее, статья о том, как на примере игры Zelda: A Link to the Past создавать противников, исходя из их функций.

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

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

В прошлом году я сделал короткий доклад на GDC о важности понимания того, на каком наследии прошлого основана ваша игра. Видео доклада опубликовано здесь (моя часть начинается с 28:50):

Ссылка

Три страйка — и ты выбываешь.

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

… на самом деле это неправда. Бьющий не выбывает после третьего страйка. Он выбывает, только когда кэтчер ловит мяч.

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

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

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

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

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

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

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

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

Диздок упоминают в разговорах, о нём шепчутся на форумах, примеры его ищут и зелёные новички, и бывалые разработчики. Случается, что под тусклым светом уличного фонаря происходит сделка. Фигура в тёмном капюшоне украдкой передаёт ссылку на «Месть курочки Рябы». Конечно, таинственный гонец не имеет злого умысла, но деяние совершено…

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

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

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

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

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

Меня всегда интересовал геймдев. Несколько лет назад я сделал шаг и окунулся в этот мир. Меня поражал успех Энгри Бердс (Angry Birds), взлёт и падение Зинги (Zynga), и одна мысль мне не давала спать — «Как же они сделали такие классные игры?».

Прошло немало времени, накопился ящик опыта, в закромах образовались какие-то отрывочные записи и комментарии. Я решил все структурировать и систематизировать, стараясь ответить на один из краеугольных вопросов — «Почему же пользователь вернётся в игру?».

Введение

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

I Вступление

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

За свою многолетнюю ИТ практику мне пару раз посчастливилось поучаствовать в проектах, затрагивающих тему автоматизации техпроцесса самого что ни на есть производства информационных систем. По разным причинам команде нужен был свой уникальный продукт, позволяющий выполнять подобные задачи. Например, в одном интересном проекте на платформе 1С, организуя процесс управления разработкой и внедрения ПО, требующий оперативности принятия мер (если что-то пойдет не так), помимо общепринятых активностей, мы создали подсистему, автоматизирующую сбор замечаний пользователей, непосредственно в самом продукте, так сказать на острие атаки. Прямо в свой рабочей среде, да что там среде, прямо на форме с конкретными данными, пользователи самолично могли создавать сообщения для разработчиков: об ошибках, замечаниях, предложениях и т.п. А там на обратном конце коммуникации, в глубоком тылу, программисты в системе управления разработкой, помимо описания ошибки, оперативно могли увидеть: сборку продукта, место локализации базы данных, форму, и наконец сами данные, с которыми связано возникновение ошибки. Это позволило разработчику прямо из задачи по устранению ошибки переходить в продуктивную среду и видеть воочую все то, что лицезрел пользователь, создавая сообщение. Согласитесь, что это очень удобно.

Одна из самых волшебных вещей — это превратить интерфейс в игровой объект. Вот, например, оцените:


^{Пацан из Fallout 3NV носит на руке точно такое же системное меню, как и мы}

А в Deus Ex всё, что мы видим на экране, выводится прямо на наш зрительный нерв. Это не интерфейс игры, это допреальность нашего персонажа:



Интерфейс игры – это привычная условность, и если её устранить, получится чуть меньше недоверия тому, что мы видим на экране. Ну и это просто безумно красиво.