Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан
Следовать ли за тем, куда ведет прототип
Всякий раз, когда вы сделаете понравившийся вам цифровой прототип, перед вами встанет выбор: использовать ли оставшееся время на обдумывание идеи для итерирования успешного прототипа или исследовать какие-то совершенно иные направления? Возможно, куда безопаснее итерировать успешный прототип, но я грешу выбором в пользу дальнейших поисков, особенно на ранней стадии идеации. Неопределенность, связанная с такого рода решениями, – неотъемлемая часть того, что делает творчество одновременно пугающим и захватывающим. Вам предстоит самим искать правильный баланс для вашего стиля работы.
Я часто видел, как люди отказываются от хорошо показавших себя прототипов, и обычно они делают это из эгоизма. Им не нравится то, что они сделали, потому что это не соответствует их ожиданиям относительно того, какой, по их мнению, должна быть игра. Возможно, они считают ее недостаточно крутой или инновационной, хотя у игры был бы потенциал стать такой, если немного над ней поработать. Они отказывались от прототипа, даже несмотря на то что их плейтестеры отлично проводили время за игрой и хотели поиграть еще или их трогала общая концепция игры.
Остерегайтесь этого. Да, эго необходимо творческим людям: это источник творческого видения. Однако оно может легко сорвать или заблокировать процесс разработки, если оно неразумно мотивировано. Во время формирования идей мы должны согласовывать наше видение с нашей открытостью новым направлениям и задумкам. Это требует усилий, но единственный способ развить эту важнейшую творческую мышцу – постоянно над ней работать.
Результаты идеации: создание прототипа
Под результатом в игровой индустрии понимают то, что разработчики проекта предоставляют заинтересованным сторонам (людям, управляющим и/или финансирующим проект, англ. stakeholders) в рамках процесса разработки. Наши прототипы – первые результаты, которые мы создадим в течение нашего продакшена.
Лучший способ предоставить прототип в качестве результата – создать исполняемый файл. Этот файл позволит вам поиграть в прототип при его запуске, и среди разработчиков программного обеспечения создание этого файла обычно называют билдом – сборкой. Создание билда – важная часть процесса разработки. Детали варьируются от одного игрового движка к другому, и обычно движок, с которым вы работаете, предложит документацию по созданию билда (хотя не каждый движок может его сделать). По ряду причин лучше отдавать билды, а не проектные папки, и неважно, отправляете ли вы свою работу издателю игр, руководителю проекта, коллеге или преподавателю. С билдом проще и удобнее иметь дело – в пару кликов вы можете запустить игру. С точки зрения размера файла билды всегда меньше проектных папок.
Хотя я никогда не выбрасываю проектные папки своих старых прототипов, я храню также и архив билдов. Когда позже мне хочется взглянуть на старый прототип для вдохновения или исследования, проще найти и запустить билд, чем загружать проектный файл (если старый билд все еще работает).
Документы по сборке
Для каждого собранного билда надо составлять некоторую документацию, которая будет полезна как тем, кому мы отправим билд, так и нам самим, если мы снова вернемся к этой сборке. В профессиональных проектах документация может занимать несметное количество страниц, подробно описывая всю проделанную работу. Для прототипов будет достаточно предоставить следующее.
Описание управления пригодится всем, кто попытается поиграть в прототип, особенно если в нем этому управлению не обучают.
Выработайте привычку вести список любых приобретенных сторонних ассетов, какими вы пользуетесь. Вероятно, вы не станете публиковать свои прототипы, а будете использовать некоторое ограниченное количество материалов, защищенных авторским правом, разрешенных для личной работы и в научных кругах, но неизвестно, какой из ваших прототипов окажется успешным, и тогда авторские права станут проблемой. Помните, что найденные ассеты могут использоваться в коммерческих целях только в том случае, если у них есть соответствующая лицензия, например Creative Commons или Open, или если они подпадают под действие доктрины добросовестного использования. Это совсем не весело – рыться в проектной папке в поисках лицензии на то, что вы нашли в интернете. Если вы будете вести список сторонних ассетов и ресурсов по ходу дела, то позже сэкономите себе драгоценное время.
Полезными будут дополнительные инструкции – например, чтобы сообщить игроку, открытый ли у прототипа финал или в нем есть некая цель, которой можно достичь.
С самого начала проекта ведите титры вашей игры. В титры надо занести всех, кто выполнил даже небольшой объем работы над проектом, за исключением особых и тщательно оговоренных случаев. Несправедливое исключение вклада некоторых людей в игры стало большой проблемой в игровой индустрии, и каждый ответственный гейм-дизайнер должен работать над ее решением. Международная ассоциация разработчиков игр подготовила стандарт Crediting Standards Guide, по которому вы можете ознакомиться с основными правилами оформления титров и включения в них участников разработки[29].
Синдром завышенных ожиданий
Возможно, вы слышали о синдроме завышенных ожиданий – когда творческих людей так переполняют возбуждение и высокие ожидания от своих следующих проектов, что их просто расплющивает грузом ответственности. Синдром завышенных ожиданий часто возникает, когда новый проект больше и потенциально лучше, чем любой из тех, над которым вы работали раньше, будь то ваша первая профессионально сделанная игра или университетский дипломный проект.
Синдром завышенных ожиданий похож на проблему «чистого листа», которую мы обсуждали в главе 1. Вас словно парализует от бесконечного количества вариантов того, что и как
