Пять ночных кошмаров современного геймдизайнера

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

1. Все придумано до нас

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

Библия и Уголовный Кодекс говорят, что воровать – это плохо. Но если речь идет об идеях игростроительства, то НЕ украсть хорошую концепцию будет очень трудно (точнее, доказать, что это ты сейчас придумал, а не подсмотрел на референсных скриншотах). Как только перед геймдизайнером встает какая-то задача, то первое, о чем ему следует подумать – это «а где такое уже могло быть реализовано?». В таком мышлении нет ничего постыдного: как у программистов есть уже написанные кем-то библиотеки для решения нетривиальных задач, так и у геймдизайнеров есть сотни тысяч игр, набитых мудростью и опытом мирового сообщества.

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

2. Beauty vs Function

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

И вот вы создаете новый экран, привычно размещаете на нем кнопки и… понимаете, что можете повесить на них всего две функции. Можно еще одну добавить, но она имеет слабое отношение и к этому экрану, и к своим «коллегам». Но даже если так – что делать дальше?

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

Как правило, решение находится где-то посередине: изобретаются новые типы экранов («стандарт» с четырьмя кнопками, «поп-ап» с тремя, «подтверждение» с двумя и так далее) или достигается дешевый и сердитый компромисс – например, нижняя часть интерфейса растягивается ровно так, как того требует функционал.

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

3. Святая недосказанность

Чем крупнее команда разработки, тем меньше шансов, что геймдизайнер знает архитектуру проекта настолько глубоко, чтобы общаться с программистами на их языке и затачивать документацию не только под свои желания, но и под их возможности. Даже самый дотошный дизайн-документ вряд ли получится назвать законченным на все 100% — рано или поздно программист придет к геймдизайнеру и начнет задавать дополнительные вопросы. Кстати, возьмите на заметку: если программист, ознакомившись с документацией, не уточняет детали и выполняет задачу «как есть», то впоследствии вы наверняка столкнетесь с невозможностью что-то подкрутить, добавить или изменить.

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

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

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

4. Опоздавшие к релизу

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

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

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

5. Единственный спаситель

А бывает так, что наоборот – по техническим, гуманитарным, юридическим или финансовым причинам фичу необходимо переделать вот прямо сейчас. Нет времени объяснять, садись и думай, как из платформера про пони сделать авиасимулятор времен Первой Мировой. Срок сдачи документации – «вчера». И считайте, что вам повезло, если от пони с крылышками вам удастся сохранить хотя бы физику летной модели.

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

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

TL;DR

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