Ошибки начинающего геймдизайнера

Ошибки начинающего геймдизайнера

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

Сам я геймдизайнер в компании Pixonic уже на протяжении 2,5 лет. За это время, конечно, успел набить собственные шишки, а некоторые моменты подметил из общения с коллегами, в чем ошибаются поначалу многие.

Итак, поехали.

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

В чем оно заключалось?

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

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

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

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

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

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

Начнем с первой из них.

Ошибки начинающего геймдизайнера

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

Но вот ты читаешь собственный ГДД, и тебе самому все понятно — значит, точно сделают так, как ты попросил.

Не факт.

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

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

Следующая ошибка напрямую вытекает из этой.

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

Длинные и сложные предложения — настоящий бич геймдизайнера.

И самый наглядный и плохой пример здесь — скобки.

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

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

Ошибки начинающего геймдизайнера

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

Либо — то же предложение, но четко структурированное и поделенное на более простые составляющие. Для большей наглядности здесь они отмечены bullet-point’ами. Этот прием тоже можно использовать в написании документа, чтобы сделать его более наглядным и читабельным. Однако пользуйтесь им без фанатизма, ведь если оформлять весь документ одним большим списком, он тоже не будет отличаться удобством.

Ошибки начинающего геймдизайнера

Следующая связанная с этим ошибка — плохая структура документа в целом.

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

Раскладывайте смысловые единицы своих документов по полочкам. Делите документ на разделы, описывайте отдельно визуал и функционал. Функционал разделяйте на характеристики и механики. Визуал — на текстуры, модели, анимации, FX. Так ваш документ станет не только более читабельным, но и поможет исполнителю найти ту часть, которая нужна именно ему.

Не гонитесь за объяснением «здесь и сейчас». Если вам пришло в голову уточнение, которое не соответствует общему назначению раздела или параграфа документа, сделайте себе пометку о том, что надо расписать это отдельно.

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

Ошибки начинающего геймдизайнера

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

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

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

И, кроме того, — поддерживайте актуальность вашего документа.

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

Ошибки начинающего геймдизайнера

Следующий большой блок — работа с задачами.

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

Ошибки начинающего геймдизайнера

Первая ошибка, связанная с задачами, — постановка задач на код самому.

Почему это ошибка?

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

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

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

Ошибки начинающего геймдизайнера

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

Так делать не стоит. Документ — это, в первую очередь, справочник о функционале фичи, и пролистывать его весь для исполнителя — большая морока.

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

Ошибки начинающего геймдизайнера

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

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

Ошибки начинающего геймдизайнера

Первая ошибка — отсутствие цветовой индикации.

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

Ошибки начинающего геймдизайнера

Несколько самых простых и самых банальных советов:

  • Чередуйте оформление строк. Это делает документ более читабельным и позволяет без дополнительных усилий проследить, какое значение соответствует какой строчке. Цвета при этом лучше подбирать ненавязчивые — например, белый и светло-серый.
  • Выделяйте ключевые параметры отдельным цветом.
  • Логично разделяйте столбцы. Например, можно выделить цветами только строку наименования параметра, но разделить ее по характеристикам: все, что касается скорости, — одним цветом, уровни — другим, и т. д.

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

Ошибки начинающего геймдизайнера

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

Главное — без фанатизма. Найдите золотую середину и придерживайтесь ее.

Ошибки начинающего геймдизайнера

Следующий момент связан непосредственно с расчетами.

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

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

Ошибки начинающего геймдизайнера

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

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

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

Ошибки начинающего геймдизайнера

Наконец, еще несколько общих идейных ошибок:

  • Еще раз, это важно: Не следить за фичей — ошибка. Если вы все расписали, со всеми обсудили и поставили задачи, это не значит, что ваша работа на этом закончена. Вы должны регулярно следить за тем, как ведется работа, что делается именно то, что вы просили. Лучше своевременно это отследить, чем потратить время вообще не на то, что было нужно.
  • Копировать фичи бездумно. Порой начинающему геймдизайнеру хочется позаимствовать фичу из успешного проекта без понимания того, что именно фича там делает. Даже если она кажется вам очень крутой, в первую очередь спросите себя: нужно ли вам это? Что заставляет ее работать в игре-референсе? Будет ли она работать так же на вашем проекте? Проведите реверс-инжиниринг этой фичи и разберитесь, что заставляет ее тикать в изначальном проекте. И только после этого принимайте решение. Как правило, даже если вы вставите в свою игру любимую фичу, она все равно перетерпит доработки.
  • Неуверенность в ГДД. Это проходит с опытом, но в начале карьеры действительно составляет проблему. Как геймдизайнеру, вам необходимо расписывать документацию, ведь это ваша работа. Но вы не уверены, что делаете это хорошо. Из-за этого подсознательно у вас получаются обтекаемые определения. Однако ГДД их не терпит: это точный справочный материал. В нем должно быть четко описано, как должна работать фича. Если у вас нет уверенности в том, что вы пишете, проверьте, нужно ли это писать вообще, или распишите как гипотезу с точными возможными исходами, которые вы хотите проверить.
  • Отсутствие фидбека от игроков. Внутри компании легко может образоваться своеобразная эхо-камера, а мнения игроков-то спросить и забыли. И вот вы выпускаете продукт, а он никому не нравится. Старайтесь этого избежать. Проводите опросы. Задавайте наводящие вопросы в комьюнити. Проводите A/B-тесты. Фидбек от пользователей — двигатель нашей работы.

Вот, собственно, и всё о чем я хотел бы поговорить. Большое спасибо за то, что прочитали статью — надеюсь, она вам понравилась. Также выражаю большую благодарность Анне Рубан за помощь в адаптации презентации в формат статьи, и всем моим коллегам из отдела ГД в Pixonic — за советы и обсуждения на этапе подготовки материала.

2222
12 комментариев

И для начинающих "писателей" документации и т.п. - если не горит, напишите и отложите на завтра.
Потом прочтите написанное, подходя к этому критически. Возможно, вам захочется это переписать :)

4
Ответить

Пройдёмся по материалу:

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. Спасибо за статью, нужно больше подобного материала для развития умений в геймдизайне.

3
Ответить

Привет! Спасибо за комментарий)
Это должен делать PM, выступая буфером между заказчиком работы и исполнителями.Работа PM -следить за сроками, они не могут оценить насколько правильно выполняется задача, т.к. не обладают видением геймдизайнера - овнера фичи. Если исполнитель понял задачу определенным, неправильным образом - PM может не только понять её так же, но и вообще не вникаться в написанное.
Ну и разумеется, крайне желательно, что-бы исполнитель тоже проявлял разумную инициативу - если что-то непонятно или вызывает двоякое толкование - уточнял у заказчика.А еще желательно чтобы исполнитель сразу понимал всё правильно) Увы, мы не можем повелевать пониманием и поступками других людей. А вот приглядывать за ними время от времени - вполне.
описать, как это будет выглядеть со стороны игрока.Юзерстори - замечательная практика, которая действительно очень помогает в донесении видения до других людей) Но конкретно в этом кейсе я пытался показать разницу в описании одной и той же вещи, а не показать пример абсолютно правильного описания способности. Однако спасибо за дельные замечания)
Robot_V1, rank 1-2 - огромное кол-во ненужных строкНа нашем проекте эти строки - индексные, и служат для програмного считывания корректных для каждого уровня-ранга значений. Если ваш проект сделан иначе - замечательно, но я не вижу ничего принципиально плохого в том как представлено на примере) Плюс столбцов для каждого уровня-ранга - десятки, не вошедшие на скриншот. Обойтись двумя столбцами для здоровья там не получится.
С остальным полностью согласен) Спасибо за подробное чтение статьи и не менее подробный разбор!

1
Ответить

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

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

1
Ответить

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

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

4
Ответить

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

1
Ответить

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

2
Ответить