Геймдизайнер — человек, который, помимо расписывания документов, также ставит задачи на исполнителей: программистов, художников, аниматоров. И для того, чтобы следить за их выполнением, нужно владеть и взять за привычку использование соответствующего инструментария — Jira или любой другой подобного рода доски. Ставить задачи в обход флоу, который позволяет трекать рабочий процесс, — не столько ошибка, сколько грубое нарушение. Однако и при четком следовании принятому на проекте флоу можно напортачить.
И для начинающих "писателей" документации и т.п. - если не горит, напишите и отложите на завтра.
Потом прочтите написанное, подходя к этому критически. Возможно, вам захочется это переписать :)
Пройдёмся по материалу:
0) Основная работа ГД.
Я считаю, что основная работа геймдизайнера основывается на трёх китах.
а) Придумать концепцию, сеттинг, фичи, основные механизмы и далее по нисходящей.
б) Написать хорошо понятную документацию для всех видов исполнителей. Таких как художники, программисты, дизайнеры уровней, разработчики персонажей/квестов и т.д.
в) Постоянно заниматься коммуникацией с исполнителями/тестерами и своевременно изменять основную документацию.
1) Непонятное ТЗ.
"Вы не следили за процессом и проглядели, что исполнители делают не то, что нужно."
Это должен делать PM, выступая буфером между заказчиком работы и исполнителями.
Если Вы совмещаете GM/PM - то вопросов нет, укажите это в материале.
Ну и разумеется, крайне желательно, что-бы исполнитель тоже проявлял разумную инициативу - если что-то непонятно или вызывает двоякое толкование - уточнял у заказчика.
2) Описание абилки робота.
Сравнение в примере некорректно, т.к. в первом описании ничего не говорится о том, что это абилка.
Правильнее, имхо, указывать:
а) Что это пассивная абилка.
б) Внутреннее название должно максимально отображать суть работы абилки, например "Щит с обратным уроном", "Вампиризм", "Хилка", "Усиленная атака", "Дальний прыжок" etc.
в) Опять же, имхо, если функционал может быть непонятен исполнителям, лучше в виде сноски под основными данными описать, как это будет выглядеть со стороны игрока.
Например: Вражеский мех атакует моего на 100 урона - 20 урона будет поглощенно щитом, 5 урона будет нанесенно атакующему. Нужно будет показать две иконки/индикатора рядом с уроном. Одна - показывающая поглощенный урон, вторая - урон вернувшийся к атакующему.
3) Таблицы.
Несомненно - читабельность таблиц важна.
Но в кокретном примере - Robot_V1, rank 1-2 - огромное кол-во ненужных строк, при условии, что разница между рангами только в максимальном здоровье.
В этом случае, лучше вынести просто в разные столбцы MaxHealthPoints_rank1, MaxHealthPoints_rank2 etc
4) Дополнительные умения ГД.
Знание программирования, как и дизайна уровней, нарративного дизайна, математики и прочего - несомненно полезно.
Но имхо, умение коммуникации, написание хороших документов, наличие логики и желания понимать, как в итоге проект работает изнутри - важнее.
5) "Копировать фичи бездумно."
Отличный навык - умение деконструкции. Особенно если внедрение новой фичи оценивается не только со стороны ГД, но и с подачи ГД - конечными исполнителями.
Ну и по факту уже принимается решение, стоит ли игра свеч :)
P.S. Спасибо за статью, нужно больше подобного материала для развития умений в геймдизайне.
Привет! Спасибо за комментарий)
Это должен делать PM, выступая буфером между заказчиком работы и исполнителями.Работа PM -следить за сроками, они не могут оценить насколько правильно выполняется задача, т.к. не обладают видением геймдизайнера - овнера фичи. Если исполнитель понял задачу определенным, неправильным образом - PM может не только понять её так же, но и вообще не вникаться в написанное.
Ну и разумеется, крайне желательно, что-бы исполнитель тоже проявлял разумную инициативу - если что-то непонятно или вызывает двоякое толкование - уточнял у заказчика.А еще желательно чтобы исполнитель сразу понимал всё правильно) Увы, мы не можем повелевать пониманием и поступками других людей. А вот приглядывать за ними время от времени - вполне.
описать, как это будет выглядеть со стороны игрока.Юзерстори - замечательная практика, которая действительно очень помогает в донесении видения до других людей) Но конкретно в этом кейсе я пытался показать разницу в описании одной и той же вещи, а не показать пример абсолютно правильного описания способности. Однако спасибо за дельные замечания)
Robot_V1, rank 1-2 - огромное кол-во ненужных строкНа нашем проекте эти строки - индексные, и служат для програмного считывания корректных для каждого уровня-ранга значений. Если ваш проект сделан иначе - замечательно, но я не вижу ничего принципиально плохого в том как представлено на примере) Плюс столбцов для каждого уровня-ранга - десятки, не вошедшие на скриншот. Обойтись двумя столбцами для здоровья там не получится.
С остальным полностью согласен) Спасибо за подробное чтение статьи и не менее подробный разбор!
Слушал этот доклад ещё на стриме
Очень странно выставлены акценты
Я думал, что геймдизайнер - это человек, который проектирует опыт игрока и саму игру, например придумывает механики, выставляет акценты и согласовывает планы с реальностью.
Соответственно и ошибки начинающих связаны с этим же: думать о сеттинге и сюжете, а не о механиках, ставить слишком амбициозные планы, проектировать игру без прототипирования и тестирования механик, ставить своё видение выше интересов игрока и всё такое. Короче, всё, что связано непосредственно с дизайном самой игры.
Тут же говорят в основном о раздаче команд подчинённым, как будто речь не о геймдизайнере, а о менеджере или начальнике отдела разработки и арт-отдела. А о самых важных вещах только маленькое упоминание в конце доклада, как будто это не так важно и тут не о чем особо говорить, хотя мы понимаем, что от тестирования и фидбека успех игры зависит намного больше, чем от того, что табличка гдд будет неправильно раскрашена.
Привет! Спасибо, что еще и смотрел доклад)
Всё описанные в статье ошибки основаны на моем личном опыте и общении с моими коллегами. То, что геймдизайнер проектирует опыт игрока и саму игру, механики, сеттинг и прочее - однозначно правильно. Однако, если ты приходишь в индустрию на позицию с опытным людьми, то твою первоначальную работу курируют они, и тебе просто не дадут не обдумывать механики, пропускать этап прототипа и строить слишком амбициозные, не реализуемые планы. Всё эти ошибки можно совершить только на свежем проекте, над которым не работают достаточно опытные люди.
В любом случае, проблем с креативом и придумываем механик после одного замечания "а как это работать будет?" я не наблюдал. А вот оплошностей в том, что тебе ещё и менеджерить других людей надо - полно.
Часто - начинающие ГД концентрируются на своих личных хотелках.
Часто - не умеют их описать или правильно оформить.
Часто - не умеют общаться с командой.
Часто - быстро теряют уверенность и желание, когда что-то начинает идти не так. А это будет, если в наличии верхние пункты.
Ну и бывает, что проект рушится, как карточный домик. Ведь начинающему ГД дали слишком много воли, но увы, недостаточно контролировали его работу.
Спасибо за статью, было интересно почитать. Действительно в составлении тасков, таблиц и ГДД масса казалось бы очевидных нюансов, которые надо все-же иногда повторять.