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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не факт.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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