Крис Авеллон об иерархии игровых разработчиков и вырезанных элементах Pillars of Eternity

Как поживаете, Крис? Как дела с поиском названия студии? Я видел немало достойных вариантов, особенно на RPG Codex.

Неплохо. С семьёй тоже всё хорошо. В прошлом году я беспокоился о здоровье матери (у неё рак, а лечить его довольно дорого), но в конце концов она получила должный уход и пошла на поправку, а я немного расслабился. С ней теперь, похоже, всё хорошо, а я стараюсь как можно больше времени проводить с семьёй. Моя десятилетняя племянница заявила, что хочет разрабатывать игры — надо бы взглянуть, как у неё там дела. Наверное, будет много драконов. Очень много.

У меня довольно большой список названий для студии — три страницы, не меньше. Некоторые остались со времён Interplay, когда мы бились над той же задачей, хотя многие вряд ли пригодны в реальных условиях (например, Colostomy Bag Food Fight). Всегда готов рассмотреть новые идеи — пишите в мой твиттер.

С работой хорошо. В прошлом месяце закончил работать над Torment: Tides of Numenera (пришлось сделать несколько правок в графической новелле), да и с Prey теперь тоже покончено. Сейчас я работаю над Divinity, но вам лучше побеседовать со Свеном, поскольку я не уверен, что могу раскрыть какие-то подробности.

Что касается новых проектов, то некоторые объявят уже совсем скоро, но вы наверняка узнаете об этом раньше — мне иногда кажется, что Кодекс знает обо мне больше, чем я сам. Я работаю над множеством интересных игр. Со мной как-то даже связался глава Fig и предложил поработать над Pillars of Eternity 2, но я вежливо отказался.

Помимо System Shock Reboot, у меня немало общих проектов с бывшими работниками Obsidian, которые покинули студию как относительно недавно, так и очень, очень давно. Интересно вновь встретиться с ними.

О многих других проектах я пока не могу говорить.

Крис Авеллон, Тим Кейн и Алексис Кеннеди на Reboot Develop 2017.

Рад, что всё хорошо, и желаю здоровья вашей матушке.

Что касается Кодекса, то мы можем быть... весьма дотошными, но в этом ведь нет ничего плохого? К слову, Roguey заметила, что в проекте System Shock Reboot вы значитесь старшим сценаристом — один из самых высоких ваших постов за последнее время. Не могли бы вы рассказать, чем там занимаетесь? Одна из целей на Kickstarter обещает «аудиодневники и новых членов команды». Ваша работа?

Этим я и занимаюсь. Что касается должности, то Джейсон Фейдер (управляющий разработкой System Shock Reboot), с самого начала установил иерархию и чётко обозначил мои обязанности, чему я был несказанно рад. Кстати, мы уже работали с Джейсоном над дополнениями к Fallout: New Vegas, и я рад встретить его снова.

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

Почему вы испытали облегчение, когда вам чётко обозначили обязанности?

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

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

Нередко случается, что за одно направление отвечает несколько человек (как было, например, в Black Isle), и я ни разу не видел, когда бы от этого была польза (если только они не работают над разными вещами в пределах одного отдела). Когда два человека отвечают за одно и то же, это приводит к путанице в команде, да и сами руководители не всегда могут поделить обязанности. Я не говорю, что такой подход априори обречён на провал, но... когда за одну работу отвечают двое, на это должны быть веские причины.

На странице Kickstarter-кампании System Shock Reboot говорится о «правильном» перезапуске/переиздании. Нам хотелось внести некоторую ясность. Обычно под переизданием подразумевают улучшенную версию оригинальной игры, однако перезапуском чаще всего называют отказ от прошлых наработок. В чём суть и «правильность» перезапуска?

Это не переиздание, а перезапуск. Это значит, что на меня свалилось больше работы, чем я думал (с переизданием я бы давно закончил). Если бы мы выпускали переиздание, всё равно пришлось бы внести некоторые правки, начиная со всяких мелочей и заканчивая вопросами половой принадлежности SHODAN, а также противоречиями в хронологии событий на станции.

«Правильный» перезапуск означает, что никто не покушается на основы вселенной System Shock, более того, мы постоянно консультируемся с разработчиками оригинальной игры (спасибо им за терпение). Стоит отметить, что за прошлые годы перед нами открылось много новых возможностей, повествовательных и игромеханических, реализовать которые раньше было невозможно, либо крайне затруднительно.

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

Джордж Сальгадо и Крис Авеллон в документальном фильме «Дорога к Вечности».

Ситуация с Pillars of Eternity 2 кажется несколько странной. Почему Obsidian сами не предложили вам поработать с ними?

Трудно сказать. Возможно, он [прим. пер. — глава Fig] посчитал, что для успешного сбора средств на Pillars of Eternity 2 необходимо моё участие, в чём я сильно сомневаюсь. Я даже не знаю, будет ли Obsidian сотрудничать с Fig. Но раз уж они спросили меня, то наверняка.

В интервью RPG Codex Эрик Фенстермейкер рассказал, что было несколько вариантов сюжета Pillars of Eternity, предложенных разными сценаристами, но победил именно его. По слухам, одним из этих сценаристов были вы. Так ли это?

Да, кажется, я сам несколько раз говорил об этом. Предложения вносили не только сценаристы, а почти все желающие.

Я предложил несколько правок сюжета и игрового мира (а также свой вариант сценария), но в окончательный вариант мало что попало — он, по большей части, отражает видение игры творческим директором проекта. Как, впрочем, и должно быть. Я читал интервью с творческим директором Pillars of Eternity Эриком Фенстермейкером. Правда это или нет (я не могу говорить за всех), но я слышал, что первоначальный вариант сценария команда разработчиков встретила весьма «прохладно». Второй вариант понравился им больше, но без особых восторгов, что довольно грустно. Не менее грустно и то, что такой сценарий в конце концов утвердили. Подобное нередко случается, когда работаешь с чужими игровыми сериями, но не со своими же.

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

• Ты даёшь игроку способность Х.
• Создаётся событие или задание, в котором эта способность используется и демонстрирует пользу для игрового процесса.
• Она обосновывает необходимость путешествия из точки Б в точку В, в процессе которого благодаря использованию способности Х игрок сталкивается с новыми сюжетными событиями.
• Игрок обретает способность Y, которая в корне меняет расстановку сил в грядущих сражениях с монстрами...
• ...и так далее, и тому подобное.

Я также расставляю акценты на отдельных событиях, чтобы читатель понимал, что важно, а что нет — это помогает людям (включая меня) не зацикливаться на деталях.

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

Я советую писать черновик сценария так, как игроки пересказывают сюжет, пытаясь показать, что он круче всего, что было до этого. Как там начинается стандартная игровая байка? Если сюжет хорош, вы рано или поздно услышите: «Чувааак, ты должен в это сыграть! Я не буду палить тебе сюжет, но ты просто не можешь пройти мимо!» Большинство написанных мною сценариев начиналось с пары абзацев на сюжетную линию.

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

Часть разработчиков Icewind Dale: Стивен Боккес, Джош Сойер, Скотт Уорнер, Крис Авеллон, Джон Дейли, Реджинальд Арнедо.

А ваше мнение было столь же «прохладным»? Полагаю, вы не ответите на этот вопрос из-за связывающих вас обязательств, но люди скорее всего подумают, что вам сюжет [Pillars of Eternity] не понравился.

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

Не стоит спекулировать — на это нет причин. Что было, то прошло, а творческий директор наверняка лучше знает, что хорошо для проекта.

Думаете это справедливо? Улисс, Стоик и Скорбящая мать — всех так или иначе «порезали» (Улисса вырезали совсем), поскольку, если верить слухам, вы описали их излишне подробно. По словам Эрика Фенстермейкера, вы вложили в Стоика и Скорбящую мать немало сил и времени. Вы говорили, что стараетесь получить одобрение руководства на каждом этапе разработки. Как же так вышло? Стало ли это результатом недопонимания? Согласны ли вы с правками или предпочли бы сохранить свою версию, будь у вас такая возможность (я говорю не только об Улиссе в Pillars of Eternity, но и в Fallout: New Vegas)?

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

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

В интервью RPG Codex Фенстермейкер рассказал о причинах правок:

Поскольку вы не можете прокомментировать ситуацию с Pillars of Eternity, скажите: уделяете вы должное внимание ограничениям, в том числе и озвучению, при разработке своих персонажей? В Torment и KOTOR2 многие персонажи были весьма немногословны, но игры от этого никак не пострадали.

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

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

В конце концов, я стремился исправить все проблемы и двинуться дальше, ведь работы предстояло немало. Я сделал всё, что в моих силах, а уже команда разработчиков Pillars of Eternity окончательно решила, что лучше подходит для их игры (что, в принципе, нормально, так и должно быть). Проблема в том, что мне ничего не сказали.

Если говорить о реализации, то многие из команды разработчиков Eternity (продюсеры и творческие руководители) обещали как следует проследить, чтобы всё сделали в лучшем виде.

Когда проект задержался — а такое не редкость и я никого не виню — стало очевидно, что времени работать над персонажами уже не осталось, поэтому пришлось бросить дополнительные силы на их проработку, подчас удвоить их. В результате на многих свалилась куча работы, которую пришлось сделать, чтобы наверстать упущенное. Действительно полезные идеи (например, нанять редактора, которого позднее таки наняли для Tyranny) отвергались, а вместо того, чтобы расширить штат, людей снимали с других проектов. Я слышал, что это не прошло для Tyranny даром (и я не удивлён), но думаю, в Paradox и по сей день не осознают всю серьёзность нанесённого ущерба (издатели вообще не особо любят, когда оплаченные ресурсы перебрасывают на другие проекты).

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

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

Если честно, не вижу какой-то особой закономерности в озвучении персонажей Pillars of Eternity. Во время игры мне нередко казалось, что озвученные строки выбирались случайным образом. Мне это не нравилось (можете считать меня предвзятым, поскольку игроки едва ли это заметили). Я провёл некоторое время за версиями без озвучения, но когда я, наконец, услышал голоса персонажей, они разительно отличались от тех, какими я представлял их согласно тексту. И дело даже не в актёрах. Некоторые персонажи, ранее казавшиеся мне клёвыми, разонравились. Другие же, напротив, будто переродились, так что это палка о двух концах.

На примере Pillars of Eternity я осознал, что частично озвученный текст — не лучшая затея, с чем все дружно согласились и внесли в официальную политику партии.

Возможно, ситуация несколько улучшилась с выходом расширений, в которые я не играл. Помню, как мне хотелось узнать закономерность озвучения персонажей PoE1, и я понимал, что какой бы она ни была, скорее всего, в Tyranny будет то же самое. Я плохо знаком с процессом озвучения Tyranny, а те, кого я спрашивал, хранят молчание (не потому, что злятся, а просто не помнят).

Лично я предложил бы поискать иной выход, который сэкономил бы уйму времени и сил, даже если бы пришлось вернуться к стилистике озвучения Baldur's Gate и Torment. Ещё одно преимущество «открывашек» в духе Torment и BG в том, что они могут поведать о персонаже нечто не попавшее в его ознакомительное описание (которое может не совпадать с открывающим текстом). Сейчас, когда я знаю об ограничениях озвучения персонажей, я бы посоветовал разработчикам вообще не озвучивать Скорбящую мать, поскольку это отлично сочетается с эффектом «шепчущего разума», который предполагает наличие телепатических способностей. Почему не использовать сильные стороны игрового мира, которые к тому же экономят ресурсы студии? И все остались бы в выигрыше. Кроме того, я не помню, чтобы Стоик разговаривал в сценах сновидений, которые вырезали из игры. Так или иначе, это не обсуждалось, поскольку к тому моменту разработка подошла к этапу, когда всё уже распределили и осталось составить план, как это воплотить на практике. Для себя же я поставил цель написать спутников в духе Planescape и попытаться выделить их на фоне шаблонного фэнтези.

Например, для сцены сна из 12 экранов можно было нарисовать одну фоновую картинку и разбить её на 12 частей. Кое-что из вырезанного не требовало вообще никаких усилий (например, оружие у Скорбящей матери в стиле Planescape или особое снаряжение Стоика) — это скорее вопрос отсутствия желания, нежели времени.

Я согласен, что не стоит уравнивать проработку всех персонажей. Важно лишь 1) сохранить соотношение обычного текста к озвученному, 2) озвучивать только важные для каждой категории персонажей строки и 3) если у персонажа меньше текста (ED-E, Рекс, Псина и так далее), то этому должно быть логическое объяснение.

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

Кевин Сондерс и Джордж Зайц реализовали классную идею в Neverwinter Nights: Mask of the Betrayer — для каждого спутника они написали несколько строк, случайно выбираемых при входе в игровую область. Этот текст раскрывает характер персонажа и влияние игрока на игровой мир.

Кстати, меня раздражает не только само сочетание озвученного и неозвученного текста, но и встревающие в диалог неозвученные персонажи (как в разговоре с Ваэлем, если с вами Кана и Эдер).

Если у некоторых персонажей KOTOR2 и не было озвучения, то оно симулировалось, сохраняя целостность атмосферы. И даже когда мы знали, что не озвучим каждую строчку Torment (не забывайте, что в то время сама идея чего-то подобного казалась абсурдной — пока не вышла KOTOR1, заставившая всех пойти по своим стопам, независимо от объёма текста), мы написали «открывашку» для большинства значимых персонажей и озвучили ключевые моменты. Не думаю, что нам удалось быть абсолютно последовательными, но в игре это не ощущалось (опять же, я предвзят, поэтому если вы не согласны — добро пожаловать в комментарии).

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

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

Помимо проблем с распределением обязанностей, многое сводилось к приоритетам, расставленным руководителями проектов. Будучи одним из них, как вы определяли, что оставить, а что вырезать из игры?

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

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

• Первая категория: наполнение, без которого невозможно играть.
• Вторая категория: наполнение, отсутствие которого бросится в глаза, играть можно, но не так хорошо, как могло бы быть.
• Третья категория: наполнение, улучшающее общее впечатление от игры, отсутствие которого игроки вряд ли заметят (говорящие приборы в «Блюзе старого мира», например).

Обычно всё игровое наполнение распределяется так: 50% в первую категорию и по 25% в оставшиеся. Это избавляет от геморроя позднее, и когда необходимо что-то вырезать, ты уже знаешь что. Если в процессе отрезания от игры кусочков вы остаётесь наедине с наполнением первой категории, значит всё летит к чертям.

Разработчики Fallout: New Vegas.

Стоит ли разделять дизайнеров и сценаристов, ставя над ними разных руководителей? Спрашиваю потому, что у Planescape: Torment и KOTOR2, двух игр, которые ценят прежде всего за сценарий и повествование, не было отдельной команды сценаристов.

Зависит от студии и жанра. Думаю, это неплохая идея для ролевых игр.

Я как-то спрашивал, не хотите ли вы вновь стать главным разработчиком, а вы ответили, что могли бы примерить эту роль снова, но предпочли бы возглавить проект в целом, поскольку у вас это лучше получается.

Руководитель проекта стоит над всеми, включая главного разработчика. Иногда один человек занимает сразу несколько должностей (не обязательно старшего разработчика, он может быть главным художником, программистом и так далее). Бывает и так, что один работает за троих — тогда обычно и начинаются проблемы. Так случилось с Planescape: Torment и другими проектами — с похожим результатом.

Сейчас Тим Кейн руководит разработкой проекта, и него есть главный разработчик, который отчитывается перед ним лично.

О каких проектах речь? Не припоминаю ни одного проекта, над которым вы работали именно в этой должности. Torment или KOTOR2? В титрах KOTOR2 нет руководителя проекта, а в случае с Torment руководителями проекта до его выхода значились Гвидо Хенкель и Кеннет Ли. Оба в титрах оказались продюсерами. Или вы имеете в виду проекты, которыми де факто руководили?

Фактически разработкой Planescape: Torment руководил я, по крайней мере, какой-то её частью (сначала им руководил Гвидо Хенкель). У нас долгое время не было руководителя, и со временем эта роль пала на меня как на первого приступившего к разработке.

Идеальная иерархия по-вашему выглядит как-то так?

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

И в каких проектах вы применяли такую иерархию разработчиков?

Впервые я экспериментировал с ней в работе над расширениями Fallout: New Vegas.

Сколько и каких ролей может совместить один дизайнер, не замедляя разработку проекта?

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

Всегда плохо, когда 1) один человек работает за двоих, 2) решение задачи затягивается из-за перегруженности сотрудника должностными обязанностями.

Тот случай, который на жаргоне некоторых разработчиков зовётся «блокировкой»? Я впервые познакомился с ним, прочитав книгу Джейсона Шрайера «Кровь, пот и пиксели»:

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

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

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

Свен Винке и Крис Авеллон играют в Divinity: Original Sin 2.

Логично. Но не кажется ли вам, результат во многом зависит от разработчика. Свен и Миядзаки (из FromSoftware) — отличные примеры непосредственного участия управленцев в разработке наполнения.

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

Свен и Фарго действительно участвуют в разработке своих проектов, хотя во многом полагаются на сотрудников, которые помогают реализовать их идеи на практике. Впоследствии они оценивают воплощение своих идей и предлагают внести правки. В частности, Свен нередко участвует в совещаниях, посвящённых сюжету и повествованию, на которых предлагает замечания. Сам он, насколько я могу судить, ничего не пишет, а лишь сообщает, что ему понравилось, а что нет, и что нужно сделать, чтобы это изменить. Фарго участвовал в разработке игровой области Рельсовых кочевников для Wasteland 2, но реализацией занимались другие люди — в общем, вы поняли.

Лучше всего руководителям проектов удаётся ставить задачи, принимать окончательные решения в различных направлениях разработки, контролировать соответствие проекта изначальной концепции. Никто не запрещает вмешиваться в разработку, но они должны с уважением относиться к работе подчинённых и думать прежде всего о качестве игры — погрузившись в детали, за деревьями не увидишь леса. Ещё хуже, если руководитель проекта нерешителен и безответственен. Допустим, ему не понравился художественный стиль и он хочет его изменить, но художники уже потратили неделю на прорисовку окружения — придётся решать. Руководитель проекта должен немедленно остановить работу и объяснить художникам, почему необходимо что-то переделать, а также принять ответственность за решение, или же продолжить работать дальше с тем, что есть, если время уже поджимает. Главное в таком случае 1) не откладывать решение на потом, зная, что решать всё равно придётся (это гораздо хуже блокировки, поскольку ты не просто останавливаешь работу, а выкидываешь её в мусорку, заставляя людей переделывать заново — и чем дольше медлишь, тем больше переделывать), 2) не говорить: «я знаю, что остался месяц или нас всех уволят, но мне нужно две недели на правильную постановку задачи».

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

Не нужно сразу замахиваться на огромную студию или проект. Начните с малого — придумайте игру на основе одной увлекательной механики, отполируйте её до блеска, затем сделайте следующую с этой же механикой и добавьте к ней ещё одну. BioWare делает так много лет, добавляя к каждой игре 20% нового материала и оставляя проверенные временем решения.

Разработчики Planescape: Torment.

Как вы решаете такие проблемы? Просто говорите как есть и пытаетесь найти компромисс, который устроит всех? Бывало, что вы ни разу не встречались с руководителем проекта (или направления) с глазу на глаз, и что вы тогда делали?

Мой подход заключается в том, что вы представляете своё видение дизайна/художественного оформления/части кода, которое сначала изучается вашим руководителем, а потом выносится на рассмотрение остальной команды. Делается это не из-за секретности, просто руководители обычно сходу видят распространённые ошибки, а кроме того, они должны выстроить линию поведения в разговоре с остальными и подготовить аргументы в защиту своей точки зрения. Если уже на этом этапе вам указывают на ошибки, предлагают другие варианты реализации или руководителю кажется, что ваша идея не подходит проекту, лучше принять информацию к сведению и устранить недостатки. Такое уже случалось в прошлом — если против вашей идеи выступает больше трёх человек, самое время её пересмотреть (как с KOTOR2).

Поэтому в идеале руководитель проекта сначала обсуждает проблемы с руководителями отделов (направлений), приходя к какому-то решению. Рядовым разработчикам об этом, как правило, не рассказывают, чтобы не вызывать лишних пересудов. Главная цель такого совещания — обосновать необходимость идеи и рассмотреть способы её воплощения (не всегда это касается дизайна — главный аниматор может объяснить коллегам, почему определённые анимации невозможно реализовать и предложить им замену). Если все всё поняли и со всем согласны, главы доносят решение до подчинённых. Если с уважением отнестись к чужому мнению, не отмахиваясь от несогласных без объяснения причин, компромисс рано или поздно найдётся.

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

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

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

И последнее — будьте готовы признать, что не подходите на свою роль. Я отказался от должности главного разработчика Dark Alliance 2, поскольку сомневался, что справлюсь с задачей. Мне казалось, что Дейв Мальдонадо подойдёт гораздо лучше.

Вы часто упоминаете Planescape: Torment как пример совершенно неразумного распыления сил. Не кажется ли вам, что такой подход оправдал себя?

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

И когда вы задаёте вопрос о том, окупились ли вложенные усилия, неплохо бы уточнять, для кого именно. Уж точно не для Interplay — компании, которой нужно было вернуть вложенные в лицензию средства. inXile извлекли выгоду намного позднее, когда игра обрела статус культовой классики, заслуживающей полноценного продолжения (?). Да, я поставил знак вопроса, но не для того, чтобы принизить заслуги inXile, а отметить, что они сделали духовного наследника, а не прямое продолжение Planescape: Torment. Спустя 13-14 лет, Planescape помогла профинансировать разработку другой игры, к чему я, конечно, никогда не стремился.

Думаю, те, кому понравилась новая Torment, считают, что мои усилия окупились, но их было не так уж много по сравнению с фанатами других ролевых игр. А многие и оригинальную Planescape: Torment не прошли.

Это вовсе не означает, что я не горжусь ей или о чём-то сожалею, но, да, я слишком распылял свои силы, будучи главным разработчиком и творческим директором (а также псевдо-руководителем проекта) одновременно. Отчасти это случилось потому, что у нас была маленькая команда и я не нашёл никого, кто справился бы лучше (Входило ли в мои обязанности задавать точки поиска пути для каждого персонажа в Улье? Наверное, нет. Должен ли я был рисовать концептуальные рисунки игровых областей? Мне нравилось, но это работа художника).

Концептуальные рисунки Криса и готовые игровые области.

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

Когда я говорю о том, какую выгоду принёс выход Planescape, я имею в виду и разработчиков, которые вдохновлялись этой игрой в разработке собственных проектов. Один из них — наш читатель, Марк Йохалем.

Изначально вопрос заключался в том, оправдано ли было с моей стороны так сильно распылять силы — и я ещё раз скажу «нет», игра вышла бы гораздо лучше, будь у меня возможность работать иначе. Чудесно, что Planescape вдохновила других разработчиков на создание собственных игр, и работая над новыми проектами, я всегда надеюсь на что-то подобное, но если говорить о самом процессе разработки Torment, то он был весьма неспокойным (и сильно затянулся, несмотря на уже готовый движок). Дела у Interplay шли не очень (и только выход Fallout 2 мог спасти компанию от массовых сокращений), все беспокоились о том, чтобы завтра не остаться без работы. Некоторые беспокоились не только за себя, но и за своих друзей в других подразделениях (не только Black Isle), которых в любой момент могли уволить, лишив возможности увидеть плоды своих трудов.

Что касается руководителя проекта, покинувшего его после бета-тестирования — я слышал это от Гвидо Хенкеля, но изучив некоторые интервью с ним, я бы усомнился в надёжности такого источника. Что произошло на самом деле?

Если мне не изменяет память, Гвидо покинул проект примерно в середине разработки. К тому времени он и так уделял большую часть времени Neverwinter Nights. Справедливости ради, Гвидо сыграл важную роль в рекламной кампании игры, разработав логотип и обложку. Ему на смену пришёл Кеннет Ли, сосредоточившийся исключительно на Planescape (и придумавший множество заклинаний).

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

Да, просыпаюсь, встаю с постели, сажусь за компьютер, печатаю. Много. Застреваю на чём-то. Переключаюсь на часок на другой проект, продолжая размышлять над предыдущим, практически неосознанно нахожу решение проблемы, переключаюсь обратно. И так до самого вечера.
Плохо, что я не умею вовремя остановиться, как во времена Torment, что не лучшим образом сказывается на моём здоровье. Иногда я скучаю по товарищам из Obsidian, но время от времени мы встречаемся, а иногда и пересекаемся в работе над проектами.

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

Брайан Мензе, Энтони Дэвис и Крис Авеллон.

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

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

В удалённой работе немало преимуществ, впрочем, как и недостатков. Совещания остались, пусть и через Интернет, например, через Skype. Google Drive помогает совместно работать над документами — мне это нравится гораздо больше систем обратной связи, использовавшихся мною в прошлом.

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

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

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

Работаете ли вы в офисе или дома, стоит всегда составлять план совещания. Тем не менее, в компаниях зачастую пренебрегают их планированием, считая его нецелесообразным (нередко попытка составить план сталкивается с непониманием руководства), хотя отсутствие чёткого плана почти всегда оборачивается дополнительными задержками. Планирование всегда полезно, в том числе и на совещаниях.

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