Здравствуйте. На этой неделе я, Илья @meenauh Осташко, буду рассказывать о котлах, в которых варится гейм-дизайнер.

За неделю поговорим о UX, интерфейсах, прототипировании, работе на стыке профессий и поиграем в игру.

Основной темой этой недели будет «ближе к телу». Буду рассказывать подробно, чем я занимался и занимаюсь. Даже делиться текущими задачами.

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

Спасибо предыдущему ведущему @DeimosAlife за проведённую неделю и давайте пожелаем ему скорейшего выздоровления.

В индустрии я 4 года. Начинал тестировщиком мобильных слотов в Creara Games, но приходилось выполнять немного задачи младшего гейм-дизайнера

Проектировать интерфейсы, верстать их на XML и даже программировать анимацию на том же XML, писать тексты, придумывать контент.

Потому через полгода мне гордо вручили звание гейм-дизайнера и посадили на новый проект. Точнее такой же проект, только новый.

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

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

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

Из-за обстоятельств я принял решение переехать в славный город Пермь. Через 1.5 месяца поисков я попал в одну из студий Game Insight.

Проект был Dragon Warlords и я был единственным гейм-дизайнером. Тут тебе и core loop, и UI, и баланс, и монетизация, и даже level design.

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

Спустя почти 2 года я перешёл в достаточно крупную пермскую компанию AlternativaPlatform, где уже работаю год.

Попробовал на вкус 7-летний проект Tanki Online и сейчас разрабатываю его римейк tankix.com, которая скоро выходит в ОБТ.

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

Ну, и закончу рассказ о себе фотографией рабочего места: pic.twitter.com/J4FzrEuIY0

Периодически нужно проверять, кто читает андерхуд, так что вот периодический тест на состав аудитории:

Сегодня я хотел бы поговорить о том, что гейм-дизайнер — это в первую очередь «дизайнер».

На мой взгляд, задачей современного гейм-дизайнера является не просто придумать механику, которая сделает игроку fun.

А сделать такой User Experience в игре, чтобы игроку было удобно, приятно и интуитивно понятно всё (или почти всё ;) ).

На разных этапах жизни игрока и сеттинг, и управление, и core loop, и баланс, и мета-гейм влияет на то, какой опыт получает игрок.

И понятие «дизайнер» тут гораздо шире рамок игровой индустрии. Фундаментальные принципы дизайна общие для любой индустрии.

Я обращусь к @jnd1er, который определил 6 принципов: видимость, обратная связь, ограничители, соответствия, однородность, возможность

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

Обратная связь — это любая информация, которая подтвердит игроку о совершённом действии или его невозможности.

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

Соответствия — это сопоставимость управления и предполагаемого действия.

Однородность — это когда элементы выполняют свои функции. Одна и та же кнопка в разных местах не должна делать кардинально разные вещи.

Возможность — свойство предмета, которое позволяет интуитивно понять, как использовать предмет. Кнопка должна выглядеть кнопкой.

Подробно о каждом: goo.gl/Wk77C, а вообще лучше прочитать goo.gl/qpvk9B

Норман определяет понятие human-centered design, к которому я и призываю гейм-дизайнеров.

Можно делать игру «для души», можно делать игру ради денег, можно для того и другого. Но делать игру нужно в первую очередь для игроков.

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

У таких проектов должны быть божественные лиды, которые смогут эффективно настроить коммуникацию.

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

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

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

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

@gdunderhood ru.wikipedia.org/wiki/%D0%92%D0…

@gdunderhood рассуждал близко к твоему: ценность = fun / усилия.
Напр. игра дает море фана, но ценой кучи сил, убитых на плохой UX/GD или др

Вернёмся к «ближе к телу»: расскажу вам историю про поток. Иногда я слышу печальные истории, когда кто-нибудь пытался успеть сделать всё.

Вот недавно мне пришла простая, как я подумал, задача — ТЗ на экран настроек графики.

В этот момент я работал над комплексной задачей по переработке интерфейса и ещё какими-то вещами по балансу.

Решил, что задача-то нетрудная и сделаю быстро. При этом я на какое-то время выпал из процесса написания ТЗ, так как много написал заранее.

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

Вопросы по ТЗ разбирали в 3 итерации. Переписывал раз 5. Перерисовывал мокапы раза 2.

При том, что мне нужно было только проработать UX экрана, так как входные данные и элементы на нём уже были известны. Без новых элементов.

А циклично ли прокручивается список параметров каждой настройки? Как применить настройки? Как вернуть первоначальные?

А что с Alt+Enter? А как назвать каждый параметр? А где писать предупреждение, что будет лагать на максимальных настройках?

Я учёл только базовый функционал и не проработал UX. Потому, что я не закончил текущие задачи, а внезапно начал делать «по-быстрому».

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

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

Что нам говорит Норман: если объект хочется нажать — это возможность. А соответствие — это когда кнопка слева и объект действия тоже слева.

Соответственно, ошибки тоже разные. Ошибка возможности: если объект выглядит как подпись, а на него надо нажмать, то игрок не поймёт этого.

А ошибка соответствий (грубо) — это когда нужно нажимать пробел для выстрела, а левую кнопку мыши для прыжка.

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

Какие задачи я выполняю в течение недели? Сейчас, в преддверии ОБТ, особенно жарко, и больше приходится тестировать и перепроверять.

Проверка и исправления текстов и иконок; перепроверка правильного забитого боевого баланса; проверка цен на предметы и на улучшения.

Проверки по платёжке (соответствие стран валютам, методам, количество платной валюты в пакетах, и т.д.); проверка, вся ли стата собирается.

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

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

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

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

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

Давайте побудем гейм-дизайнерами. Задача: оповестить игрока при авторизации о том, что сервер полный и выдать сообщение об этом.

Предлагайте свои идеи, как это сделать. Подумайте над краевыми ситуациями и попытками «сломать» систему.

@gdunderhood так и выводить статус сервера еще до авторизации, если сервер один. Чтоб игрок не клацал по кнопкам зря.

@gdunderhood имел в виду снижение доли "нервного F5" в нагрузке. От обычного спасёт инкрементальная задержка сообщения с анимацией?

@gdunderhood если мобильная игра, то при отсутсвии соединения можно сохранять статусы прямо на устройстве, а потом отсылать самые последние

@gdunderhood тогда только очередь и примерное время ожидания. И матч3 какой-нибудь, чтоб ждать было не скучно.

@gdunderhood всё зависит от игры, вот например в доте показывается крутилка, время ожидания и мини игра угадай с чего собирается айтем

@gdunderhood Задержки 3-6-10 секунд. Анимация должна меняться, как если бы клиентская часть прилагала больше усилий, а не просто ожидала.

Я написал «оповестить игрока». Это явно касается визуальной части задачи, которая направлена на определённый кейс.

@gdunderhood авторизовать его, поставить в очередь и на ожидании включить мини игру типа пакмана)))

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

На первом вертикальном мониторе у меня Slack | Terminal и CommanderOne | Рабочий браузер (почта, bamboo, стата, JIRA) | Личный браузер

На втором (горизонтальном): Workflowy и Atom | Confluence | «рабочие» программы (Axure RP / Photoshop / IDEA / Unity)

Тема сегодня будет «User Experience», в которой я порассуждаю про core loop, flow и другие штуки, которые формируют опыт игрока.

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

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

Игроку дозволено при верно введённых данных клацать на кнопку, но запрос отправляется только раз в Х секунд (сообщение отображается).

Необходимо было вспомнить про автовход после регистрации, да и вообще про автовход и учесть этот момент.

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

К примеру, у нас в компании, все элементы уже нарисованы. И новые экраны я уже собираю сам с готовыми элементами.

Если нужен новый элемент интерфейса, то дизайнер интерфейсов его рисует и отдаёт мне. Макеты с ними я уже делаю сам. А порой и в Unity тоже.

User Experience — любой опыт, который переживает пользователь.

UX направлен целиком на обеспечение комфортного пользования продуктом.

И зачастую о нём говорят вместе с UI (User Interface), концентрируя внимание на интерфейсах.

Потому, как он включает в себя и внешний вид, и структурирование информации, и продумывание взаимодействия с продуктом.

То, чем по идее должны заниматься дизайнеры интерфейсов (UX/UI), продумывая расположение элементов, доступность, форму, цвет, etc

Я считаю, что в играх UX шире, чем всё вышесказанное, и что гейм-дизайнер должен это понимать.

Всё, что есть в игре так или иначе влияет на опыт игрока: механика, управление, баланс, метагейм, etc

Вот запускается мобильная игра и начинает докачивать ресурсы. Что делать игроку?

Интересно ли ему ждать окончания или смотреть на бегущий прогресс-бар с количеством оставшихся мегабайт или процентов до конца загрузки?

Дизайнер ли интерфейсов будет определять, как с первой секунды после запуска игры занять игрока?

Скачайте и посмотрите игру HIT (play.google.com/store/apps/det…). Посмотрите, как реализована стартовая закачка ресурсов.

И вот игрок попадает в игру. Обучение! Вам нужно придумать, как провести игрока через все основные механики и научить «правильно» играть.

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

Управление — первый и ключевой момент в игре, который стоит прояснить для игрока. Не понимая, как управлять игрой, он не сможет в неё играть

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

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

Игровой цикл (Core Loop) — набор действий игрока, которые он совершает снова и снова для достижения поставленных целей.

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

Собрал ресурсы → Нанял армию → Пошёл в бой. Действия, которые игрок выполняет в игре постоянно изо дня в день (если речь про GaaS).

GaaS — Game as a Service (игра-сервис). Ключевое понятие для F2P-игр, которые стремятся удержать игрока как можно дольше.

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

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

Почитать подробнее про GaaS можно в статье Ильи Еремеева: goo.gl/r60pyy

Подробно про циклы почитайте у @m_katkoff: goo.gl/FV5G1a

Так вот гейм-дизайнер придумал для своей игры определённый игровой цикл и в течение всего обучения он должен ввести в него игрока.

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

Закончиться обучение должно концом полноценного игрового цикла и оставить у игрока сильное желание вернуться в игру снова или играть дальше.

Что дальше? Баланс? Баланс влияет на то, насколько справедливой игрок будет считать игру в тот или иной момент.

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

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

С метагеймом сложнее, так как он происходит в голове игрока и напрямую повлиять на них не получится.

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

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

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

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

Почитать про метагейминг можно у @eriknance: sixprizes.com/2013/01/31/all…

Статья старая и Эрик — игрок в покемонов со стажем. Так что это всё совпадение и я не выискивал статью специально из-за покемонов.

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

Тема сегодняшнего дня: Интерфейсы в играх.

Я не знаком ни с одним гейм-дизайнером, который хотя бы раз в жизни не занимался интерфейсами (если только не дизайнер уровней).

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

Не все компании/студии/инди-команды могут позволить себе такую роскошь, как UX/UI-дизайнер. Потому этим занимается тот, кто близок к UX.

Либо это гейм-дизайнер, либо тот, кто выполняет задачи, похожие на задачи гейм-дизайнера.

Не у всех получается, кто-то учится в процессе, но факт остаётся фактом и с ним нужно смириться — нужно сечь тему.

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

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

Опять же потому, что я в таких компаниях не работал. Ну и повторюсь, что вся неделя — моё личное мнение и никакого менторства ;)

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

А кое-где потом получать от них графику и собирать их в игре. Сначала собирал в XML, а потом подучился и теперь могу их собирать в Unity.

В общем, к делу: формируя core loop игрока, вы зачастую следом рисуете карту экранов, по которым игрок будет перемещаться.

Основные экраны, которые являются частью игрового цикла, нужно стараться размещать в доступности 1 клика с основного экрана.

Таким образом игроку будет легче ориентироваться в игре и он маловероятнее забудет зайти в важное место.

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

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

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

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

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

Много игр стремятся к упрощению интерфейсов и лаконичности. Тексты заменяются иконками, а некоторые кнопки жестами.

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

Вся эта лаконичность и простота объединена в принципе KISS (keep it simple, stupid). Зачастую, первое требование в вакансиях UX/UI-дизайнера

Задачи игрока должны решаться как можно меньшим количеством действий. Да и цели гейм-дизайнер должен ставить прозрачные.

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

Т.е. кнопки должны нажиматься. Если не нажимаются, то нужно как-то показать почему. И не нужно забывать про звуковое сопровождение.

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

Необходимо помнить об общепринятых конвенциях — привычные всем элементы и их поведение.

Крестик в углу окна, свайп для переключения экранов, прицел в шутерах.

Если пользователь потерялся (хотя нельзя такого допускать), то поспешите ему напомнить, куда он собирался.

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

Но в данном случае нужно помнить о принципе «одно основное действие на экран».

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

С этим принципом игроку проще понимать как работают разные системы в игре и проще ими пользоваться.

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

После старта игры не вываливайте на игрока весь интерфейс, а открывайте его постепенно во время знакомства с новой механикой.

Если в игре обучение, которое ведёт за ручку, то лишние элементы интерфейса будут отвлекать от сути и раздражать своей заблокированностью.

А если в игре есть нежелательные действия, которые игрок может совершить случайно, нужно делать «защиту от дурака».

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

В целом, получился немного сумбурный тред (простите!), который свёлся в очередной раз к одному правилу —делайте проще и понятнее.

В дополнение можно почитать goo.gl/Mubtf

goo.gl/ALSaaQ

goo.gl/rxjx9C

Подборки интерфейсов в играх: playpeep.tumblr.com

И 6 бордов на пинтересте из вот этого поста @galyonkin: goo.gl/ZeL51E

Тема на сегодня: Прототипирование

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

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

Прототипирование интерфейсов, прототипирование новых механик на готовых инструментов, прототипирование новых проектов.

Я занимался первыми двумя типами на проектах, а третьим пытаюсь заниматься в соло дома на Unity.

Моя мечта — стать Rapid Prototyper. Человеком, который придумывает новые механики, тестирует и предлагает рабочий прототип компании.

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

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

Механика проговорена, проиграна в голове и на словах, прописана — всё понятно (хотя так только кажется).

Мы представляем, как игрок после сессии core-геймплея, выходит на основной экран и открывает красивые сундуки с желанными наградами.

Начинаем поиск референсов и вспоминаем сокровища из Dota 2 и бустеры из Hearthstone.

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

Экран получения сундука (либо после матча/битвы, либо уже в лобби), экран хранилища этих сундуков, экран его открытия и получения плюшек.

Задача прототипирования — проверить UX и недочёты в логике. Удостовериться, что игроку будет всё понятно и удобно.

Рефы найдены и сохранены. Идём рисовать карту экранов/переходов в виде блок-схемы.

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

Карта экранов и переходов может измениться в процессе проектирования конкретных экранов.

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

Конец матча означает, что игроку нужно ещё посмотреть таблицу результатов. Т.е. нужно учесть, есть ли место под сундук там.

Если игрок обязательно выходит в лобби после битвы, то лучше показывать его награду поверх лобби там: pic.twitter.com/vncGoIYDfi

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

Хорошо, если ничего не мешает на экране получения сундука разместить кнопку «Открыть» и сразу же дать возможность получить содержимое.

Если после открытия сундука, есть ещё другие — нужно перейти на экран хранилища и дать возможность открыть ещё.

Если сундук можно купить, то после открытия нужно сразу перейти на экран покупки.

Радостный игрок, который открыл неплохой сундук и получил классную награду, может захотеть купить ещё сундук.

Если есть возможность показать, что может выпасть в сундуке — показывайте. Опять же, придётся учесть место и под это pic.twitter.com/ZyIh7ajrun

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

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

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

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

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

Интерфейсы можно прототипировать на кубиках, если это новые экраны, либо на готовых спрайтов, если элементы уже нарисованы.

Несколько инструментов для создания мокапов дальше по треду:

Moqups: app.moqups.com. Очень лёгкий и быстрый способ собрать интерфейс на кубиках.

Fluid UI: fluidui.com. Популярный сервис, который быстро позволяет набросать карту экранов и проиграть её на мобилке.

AxureRP: axure.com. Огромная платная тулза для создания больших прототипов. С интерактивностью, вот этим всем.

balsamiq.com

invisionapp.com

pixate.com

atomic.io

proto.io

Их реально много, каждый выберет своё и под свои задачи. Я по большей части использую Moqups и AxureRP (если компания платит).

Про прототипирование новых механик на готовых инструментах → в новом треде.

Продолжим: прототипирование новых механик на готовых инструментах.

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

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

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

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

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

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

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

В пазлах и match3-играх одна маленькая механика может вылиться в десятки интересных уровней.

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

Скорее всего никто вам не даст нормальных инструментов и гейм-дизайнеру придётся возиться со скриптами (+новый скилл).

В моём опыте была игра с 3 заклинаниями: лечение союзников, урон противнику и сокращение входящего урона союзникам.

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

Слабость (увеличение входящего урона), Яд (периодический урон), Берсерк (увеличение исходящего урона), Вампиризм, etc

Меняя условия действия, цель, время действия и периодичность, я могу тут же протестировать игру с множеством заклинаний.

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

Покрутив те же самые компоненты я смог добавить похожие эффекты юнитам и башням.

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

Маленькие и быстрые юниты, которые отравляют цель при ударе.

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

Самое удобное, что не приходится отвлекать программистов (ну, разве что ненадолго). И это весело!

Постепенно новые механики могут начать требовать обновлённого дизайна уровней под новые сущности.

Если же у вас есть программист, который может быстро и в черновом варианте прототипировать новые системы, то можно стать всемогущим.

Про прототипирование игр → в новом треде.

Продолжим вчерашнюю тему: прототипирование новых игр.

Тут я, наверное, буду категоричен: без прототипа никуда. Без него не доказать базовые вещи, на которых будет расти ваша игра.

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

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

Если «клон, но лучше», то без прототипа никак не проверить (только поверить), чем и насколько он лучше.

Первый прототип должен полностью охватывать core-механику. Чуть более поздний прототип должен охватывать весь core loop.

Задача первого core-геймплейного прототипа — fun и понятность. Т.е. можно легко вникнуть, поиграть и получить удовольствие.

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

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

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

Задача: добиться простоты и лёгкости в обращении с игрой. Устранить узкие места в цикле и заложить основы для мета-геймплея в будущем.

Второй этап покажет, куда игра приведёт игрока. Если и не показать high-end, то хотя бы показать в какую мета-игру можно будет играть.

Если ККИ, то нужно показать из чего может формироваться колода. Если РПГ, то во что будет превращаться персонаж и почему это интересно.

Т.е. второй прототип закрывает проблемы core loop и строит основу для мета-геймплея в будущем.

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

Не нужно бояться выбрасывать из игры дорогие вам идеи, если опытным путём была доказана их несостоятельность. Прототип на то и прототип.

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

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

Если есть команда и налажена коммуникация — работать с программистами будет гораздо эффективнее.

Очень важный момент — моральная готовность программистов. Им следует понимать принципы прототипирования и делать всё быстро (пусть грязно).

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

Статья десятилетней давности, которая в принципе до сих пор актуальна: goo.gl/5vDRK4

gamesfromwithin.com/prototyping-yo…

brianvanbruggen.com/?page=rapid_pr…

Наверное, лучшие прототипировщики — это инди гейм-дизайнеры-программисты, которые в одиночку уже сделали несколько игр.

И лекция про прототипирование из курса по гейм-дизайну от @IanSchreiber: gamedesignconcepts.wordpress.com/2009/07/02/lev…

Она же на русском в переводе от @shestovt: goo.gl/XNI1oD

@gdunderhood Большая часть теории сводится к "выберите то, без чего ну никак, и проверьте играбельность с минимальными приложением сил" )

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

@gdunderhood потому что надеюсь попасть в индустрию

@gdunderhood интересно почитать об этой специальности, выписываю себе важную информацию

@gdunderhood мечтаю сделать игру. Набираюсь теории.

@gdunderhood делаю игры, набираюсь уму разуму. Может и в индустрию занесет однажды.

@gdunderhood делал игры, не пошло. Но вдруг снова придётся.

@gdunderhood интересно мышление ГД чтобы можно было с вами компетентно ругаться)

@gdunderhood чтобы сравнить свою работу и то, что делаю ведущие андерхуда. Пока непонятно.

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

@gdunderhood чтобы понять, что делают настоящие ГД

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

@gdunderhood Узнать что движет самопризнанного ГД. Может найду себя и подружусь с ним.

@gdunderhood Чтобы доказать, что геймдизайнеров не существует

@gdunderhood я занимаюсь ui/ux. Подписался потому что люблю игры. That's it.

@gdunderhood Просто потому что люблю игры и интересуюсь всем что за занавесом.

@gdunderhood делаю игру. Нужны референсы, интересные ссылки и так далее:)

О каких темах из сферы гейм-дизайна вы хотели бы поговорить, обсудить и узнать больше? Так-то мы совсем ничего охватили на этой неделе.

@gdunderhood люблю игры, интересуюсь гейм-дизайном, надеюсь, что найду здесь какую-нибудь полезную информацию, причем по-русски

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

И уровни гейм-дизайнеров разные. Что у нас, что за рубежом. А ещё же есть США, где этому обучают, как само собой разумеещемуся.

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

У нас же как-то этими гейм-дизайнерами становятся. Специализация неформальная есть, но вроде как от тебя ждут большего :)

Периодически нужно проверять, кто читает андерхуд, так что вот периодический тест на состав аудитории:

В принципе 3 категории разделились почти поровну с лёгким перевесом тех, кто не из индустрии. На самом деле, это даже хорошо!

Финальный день подходит к концу, хочется поговорить о людях в нашей индустрии.

О том, как разные люди в неё попадают и становятся гейм-дизайнерами. Или не становятся.

Вот когда-то давно (когда гейм-дизайнеров не было :D) программисты и художники занимались гейм-дизайном. С одной стороны было неплохо.

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

«История компьютерных игр»: goo.gl/VP36iD

Мне кажется, что объём работ по гейм-дизайну прекрасно распределялся между другими участниками команды.

Не было массового GaaS. Не было необходимости собирать тонну аналитики и знать о каждом шаге игрока (не факт, что это было хорошо).

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

Основной (как считается) скилл «придумывание механик» прокачивается простым игранием в игры. Разнообразные и даже неинтересные.

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

По итогам этой недели, надеюсь, выяснили, что гейм-ДИЗАЙНЕРАМ нужно и в UX. Тут сразу много способов прокачаться.

И играть в игры с хорошим UX, пользоваться приложениями, и вообще замечать вещи в мире, пользоваться которыми приятно и понятно.

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

Возможно, лучшим UX-ером стал бы персонаж Sylar из сериала Heroes. Его способность: goo.gl/yGie8P

Или нет.

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

Гейм-дизайнер знает свою игру лучше других и аналитика — помощь в проверке тех или иных вещей. Обязательный навык для гейм-дизайнеров GaaS.

Да, гейм-дизайнеру нужно «уметь считать». Всё равно тут или там придётся понимать, что такое баланс и как его достичь.

Программировать — необязательный навык (#тыжнепрограммист). Но хорошо понимать базовые принципы и алгоритмы для общего развития.

И понимание, что такое программирование (и даже зная какой-нибудь скриптовый язык), общаться с программистами и объяснять станет проще.

Очень, просто архиважный навык гейм-дизайнера — умение доносить мысли и идеи до команды. В вакансиях часто пишут эту строчку — ЭТО ВАЖНО.

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

Немного менее осязаемый навык — общение с аудиторией. Причём не только вежливо извиниться за что-нибудь (если нет КМа).

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

И в целом уже говорили ранее об «общих» навыках, которые скорее про кругозор: экономика, история, кино, архитектура, психология, etc

Для всего этого важными чертами ГД должны быть адаптация и гибкость. Нужно уметь подстроиться под любые условия и любую систему.

Учитывая это всё, я бы сказал, что стать гейм-дизайнерам «проще всего» тестировщику, так как он знает игру вдоль и поперёк.

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

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

На этом я завершаю свою неделю. Спасибо всем за внимание и ваши вопросы! Простите за длинные треды!

С вами был Илья @meenauh Осташко. Добавляйтесь, задавайте вопросы и давайте общаться. Все спасибо ещё раз!

Архивы всех авторов с начала времён на сайте: gdunderhood.ru