Ошибки начинающего геймдизайнера
Эта статья — о наиболее распространенных ошибках в начале карьеры. Здесь мы разберем, что делает ваш геймдизайн-документ хуже, на что стоит обращать внимание при постановке задач, а также — почему так важно следить за всем процессом разработки фичи, а не проверять уже готовый результат. И, наконец, затронем, почему софт-скиллы так важны в данной пр…
Пройдёмся по материалу:
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 - огромное кол-во ненужных строкНа нашем проекте эти строки - индексные, и служат для програмного считывания корректных для каждого уровня-ранга значений. Если ваш проект сделан иначе - замечательно, но я не вижу ничего принципиально плохого в том как представлено на примере) Плюс столбцов для каждого уровня-ранга - десятки, не вошедшие на скриншот. Обойтись двумя столбцами для здоровья там не получится.
С остальным полностью согласен) Спасибо за подробное чтение статьи и не менее подробный разбор!