Тим Кейн о себе, игровой разработке, Fallout и Arcanum (часть вторая)

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

Принципы разработки на примере Fallout, Arcanum и The Outer Worlds

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

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

В Fallout принципы разработки назывались «концептуальным документом», но внутри перечислялись именно принципы разработки. В Fallout это был довольно увесистый документ, однако в случае с Arcanum разработчики уложились в пару страниц, с The Outer Worlds — даже меньше, чем страницу. Брайан Фарго попросил Кейна написать концептуальный документ Fallout в ноябре-декабре 1995 года — на тот момент у Кейна уже была довольно крупная по меркам Interplay команда из 20 человек. Несмотря на все его старания, первые две версии документа Фарго не понравились. Тим был в отчаянии и не понимал, чего от него ждёт Брайан. Крис Тейлор предложил свою помощь, и Кейн с радостью поручил составление документа ему. Всего в нём 14 принципов разработки (перечислены не все):

• Ультранасилие. Разработчики хотели, чтобы в игре было много насилия.
• Правильного решения может не быть, но для всех основных квестов должно быть несколько вариантов прохождения (побочных это не касается).
• Действия игрока влияют на мир, а мир реагирует на игрока. В качестве примера Кейн приводит финальные слайды. «Игрок не должен закончить игру без понимания последствий своих поступков».
• Игрок должен ощущать давление времени. К этому принципу апеллировали сторонники 150-дневного срока на поиск водяного чипа. Кейн считал, что это чересчур, но таймер всё равно добавили, а затем исправили его в одном из обновлений, ведь помимо ощущения срочности разработчики хотели, чтобы игрок мог проходить игру как угодно.
• У игрока всегда должна быть цель, ведь крайне плохо, когда игрок не понимает, что делать дальше. Именно поэтому цели было всего три: а) добыть чип, б) уничтожить армию супермутантов, в) уничтожить Повелителя.
• Игрок сам контролирует свои действия. Разработчики не хотели лишать игрока свободы выбора и диктовать ему, когда быть хорошим, а когда плохим.
• В игре должен быть удобный интерфейс. По мнению Кейна, игровые интерфейсы становились всё запутаннее, особенно в сложноустроенных играх вроде Fallout, поэтому разработчики стремились как можно сильнее упростить его.
• Как можно больше снаряжения и доступных игроку действий, что привело к
• Крайне детализированная система создания персонажа, позволяющая воплотить практически любой образ в голове игрока. Эта идея родилась ещё во времена работы с GURPS. Для новичков в жанре, которые не смогут сразу же разобраться в устройстве ролевой системы, создали готовых персонажей.
• Сохранить верность GURPS, сделав игру для массовой аудитории.
• Команда должна состоять из замотивированных разработчиков, делающих игру, которая им нравится.

Пять принципов разработки Arcanum:

• Технологии имеют значение. Разработчики хотели, чтобы в Arcanum было динамическое освещение, зависящее от времени суток и влияющее на использование навыков.
• Комплексная ролевая система, позволяющая воплотить множество архетипов в контексте игрового мира Arcanum. Она не позволит создать Супермена или Человека-паука, но старую ведьму или стрелка в духе Дикого запада — запросто.
• Важность характеристик персонажа. Разработчики стремились всячески подчеркнуть проработанность ролевой системы, которую считали одним из главных достоинств игры. Многим это понравилось, однако Кейн считает, что это же стало одной из главных причин коммерческого провала игры (помимо общей технической сырости и изометрического вида в наступающей эпохе 3D). Данные по продажам от Sierra показывают, что казуальные игроки не справились со сложностью ролевой системы.
• Масштабная и весьма продолжительная сюжетная линия, состоящая из нескольких веток. В противоположность трём основным сюжетным узлам Fallout (найти чип, уничтожить мутантов и Повелителя), в Arcanum их 27 (не считая возможных вариантов их прохождения различными персонажами и побочных заданий).
• Многопользовательский режим, чтобы можно было сыграть в Arcanum с друзьями. А для этого была добавлена возможность создания отдельных модулей.

Три (плюс один) принципа разработки The Outer Worlds:

• Игра должна быть максимально простой. Механики, сюжет, взаимодействие со спутниками — всё должно было быть максимально просто. После истории со сложностью освоения Arcanum Кейн боялся отпугнуть игроков, не разбирающихся в ролевых играх. Игра должна быть простой, но не примитивной. Если вы видите, что в кого-то попали — значит попали, а вот урон уже высчитывается в зависимости от навыка. Всё просто. Однако в дальнейшем развитии персонажа и специализации на навыках открываются новые возможности.
• Мрачно, но с юмором. Леонард мрачный, Кейн весёлый, поэтому проекты у них выходили соответствующие. Эту «фишку» своих проектов они вынесли в отдельный принцип. Леонард не любит глупый юмор, но любит чёрный.
• Увлекательность важнее реализма. «Мы делаем игру, а не симулятор».
• Это классическая игра Obsidian Entertainment: в ней есть проработанный мир, хороший сюжет, множество возможностей кастомизации персонажа, разнообразные спутники, выборы и значимые последствия.

Что Кейн изменил бы в Fallout сегодня

• Тим отмечает, что сделал бы интерфейс интуитивнее, и прежде всего это касается предметов в руках персонажа. Если в активном слоте находится динамит, то при щелчке по нему персонаж должен настроить таймер и положить взрывчатку на землю, если верёвка — применить к указанному объекту.
• Кейн добавил бы кнопку «Взять всё» («не могу поверить, что мы этого не сделали»), прокручивание списка предметов стрелками на клавиатуре, отображение переносимого веса прямо на экране инвентаря (эта информация находится на странице персонажа), а также увеличил бы количество цифр в интерфейсе переноса (что позволило бы перемещать объекты больше чем по 999).
• Взятые предметы добавлялись бы в начало списка, а не в конец — ведь игрок скорее всего захочет тут же взглянуть на них без необходимости спускаться на самое дно инвентаря.
• В диалоговом интерфейсе следовало бы показывать количество денег у персонажа игрока («когда вы хотите кого-то подкупить или что-то оплатить, вы наверняка захотите увидеть, сколько у вас есть»).
• Кейн добавил бы больше «говорящих голов». В Fallout их мало потому, что на создание каждой уходило по 3–4 месяца.
• Что касается карты мира, то случайные встречи сбрасывали текущий маршрут — игрок мог забыть, куда шёл или вовсе потеряться, и это тоже следовало бы исправить.
• Спутников добавили в Fallout на поздних этапах разработки, поэтому доработать их ИИ не представлялось возможным. Самое очевидное, что стоило бы сделать со спутниками — позволить обмениваться с ними предметами без ухищрений вроде кражи. Не помешал бы и приказ отойти в сторону (что появилось в Fallout 2), настройки поведения в бою (защита, нападение) — распространённая «фишка» в современных играх. Ещё одна очевидная правка — стоило бы добавить развитие спутников, возможность повысить их уровень, улучшить навыки, а также способности (возможно, уникальные для каждого спутника). Из менее значимого: Кейн бы запретил перемещения спутников, когда игрок пытается применить навык — в частности, спутники просто обожали уходить из-под указателя мыши при попытках их вылечить.
• В боевую систему Тим добавил бы возможность одновременного хода врагов, что помогло бы сделать бои заметно динамичнее. Особенно полезно это было бы в больших поселениях, где большинство персонажей не участвует в сражении, а просто разбегается кто куда. На сложности боя ниже высокой Тим убрал дружественный огонь из оружия с сильным разбросом пуль вроде Узи, равно как и критические провалы на низкой сложности.
• Так или иначе стоило бы изменить баланс характеристик («игроки всегда выбирают персонажу одарённость», да и в целом черты крайне неравнозначны) и навыков. В игре есть навык энергетического оружия, но оно не встречается в первой трети игры, так что стоило бы добавить несколько экземпляров поближе к началу. Разумеется, напрашивалось объединение медицинских навыков.
• Разрешение 640×480 безнадёжно устарело, поэтому пришлось бы добавить более современные варианты, получить которые можно было бы хотя бы апскейлом. При этом следовало бы добавить варианты масштабирования интерфейса и перетаскивания окон в разные части экрана.

Воспоминания о Troika Games

• Три раза за семь лет существования Troika Games переезжала в новый офис. После второго переезда разработчикам достались складские помещения над офисными. Использовать их по назначению никто не собирался, так что когда у сотрудников начали появляться дети, складские помещения переделали в импровизированную детскую с мягкой мебелью и игрушками.
• Сам Тим завёл себе собаку, которую водил с собой на работу. Она была весьма дружелюбна с детьми и стала всеобщей любимицей. Тим хотел себе лабрадора, но поскольку в собачьих приютах они встречались редко, то взял немецкую овчарку.
• Некоторые портреты в Arcanum нарисованы по фотографиям сотрудников Troika Games.
• Перед выпуском каждого патча для Arcanum его должен был одобрить издатель. Из-за этого случалось, что работа стояла днями, а сотрудники играли в Counter Strike в ожидании звонка от издателя. В один из таких дней Тим немного перебрал спиртного и начал стрелять по своим.
• На разработку The Temple of Elemental Evil отводилось 18 месяцев, но Troika Games управилась за 20. Чтобы как следует проникнуться первоисточником, первые несколько месяцев разработки сотрудники по паре часов в день играли друг с другом в D&D. Атмосферу этих посиделок за настолкой и постарались воплотить в компьютерной The Temple of Elemental Evil. Кейн не уверен, насколько удалось воссоздать в игре атмосферу настольных сессий, но доволен дотошным воплощением правил.
• О Vampire: The Masquerade — Bloodlines у Тима не так уж много воспоминаний. По его словам, к началу разработки сотрудники были «уже на пределе». Сам же Кейн присоединился к команде через 22 месяца после начала проекта. Примерно в то же время Troika Games покинула жена Джейсона Шэрон Шеллман, поэтому Кейну пришлось взять на себя её обязанности — помимо программирования, планирования и работы с ИИ он занялся подбором персонала и бухгалтерией.
• Сотрудники Troika Games были как одна семья, они с готовностью оставались на переработки, ведь им нравилось делать игры, и многие впоследствии говорили Кейну, что это был лучший период в их карьере. Несмотря на колоссальное напряжение, он считает работу в Troika Games увлекательной.
• Кейн говорит, что игры Troika Games вышли «особенными» или даже «культовыми», но он не уверен, насколько это связано с тем, что их создатели были молоды, полны энтузиазма и не знали, где нужно остановиться.

О балансе работы и личной жизни

• Около 10 лет Кейн работал по 12–14 часов 6–7 дней в неделю — он называет этот период «потерянным десятилетием» и считает, что так работать нельзя. Однако по его мнению он не смог бы сделать «такие игры», работая с 9 до 17.
• В Fallout Кейн занимался программированием, дизайном и продюсированием проекта. Он сетует, что такой объём работы невозможно выполнить за стандартный 8-часовой рабочий день. Но это была его личная инициатива. Fallout «получилась такой» потому, что многие работали сверхурочно и совмещали несколько должностей.
• Лучше сделать «плохую игру», чем «шаблонную». Кейн согласен, что его игры могут считать «плохими», но едва ли их назовут «шаблонными».
• Неудачи многому научили Кейна, но они же сделали его осторожным и нерешительным. Со временем он начал отходить от экспериментов в пользу проверенных решений, но не считает это чем-то однозначно хорошим и старается всё же хоть немного экспериментировать.
• Некоторые связывают экспериментаторство с молодостью и присущими ей самоуверенностью и невежеством, но Кейн не считает, что это так. Безусловно, в молодости у него было больше энергии, но на его взгляд, в сочетании с неопытностью это скорее приводило к тому, что он брал на себя больше, чем мог унести.
• Например, в Arcanum можно сражаться как в реальном времени, так и пошагово — а всё дело в уверенности Кейна, что он сумеет правильно реализовать и сбалансировать оба варианта. Другой пример — Кейн писал диалоги для The Temple of Elemental Evil в полной уверенности (из-за того, что какую-то часть этой работы он уже делал в Fallout, и людям зашло), что с этим справится.
• «Неопытность — палка о двух концах». Тим брался за работу, не понимая, «что можно, а что нельзя», и это приводило к неосознанному риску, без которого не получились бы «столь замечательные игры».
• Несмотря на важность баланса работы и личной жизни, некоторые профессии плохо подходят для фиксированного рабочего графика. Например, если хорошего игрового сценариста посещает крутая идея, он не станет ждать понедельника в надежде не забыть её к началу рабочей недели — он сразу сядет и запишет её. Разработка игр требует определённой самоотдачи, это не та профессия, в которой работают «от звонка до звонка».
• Кейна пугает тенденция игровой индустрии превращать игры в товар. «Игры всегда были товаром, но теперь их изначально делают как товар». Особенно Тима напрягают микротранзакции и игры-сервисы, поскольку в таких играх обычно нет места увлечённости и любви к своему детищу.
• Многие считают, что главным вопросом разработки должен быть «как это потом продавать», однако Кейн всегда старался переложить головную боль о продажах на кого-то ещё.
• Разработка игр — в равной степени искусство и наука. «Искусство нельзя запланировать» и поставить на поток как конвейерное производство. Кейн нередко говорит продюсерам, что понимает их стремление распланировать всё и вся, но не может гарантировать, что уложится в отведённые сроки. Поскольку точно распланировать разработку всё равно не получится, необходимо закладывать «буферное время» на различные доработки и переделки.
• Баланс работы и личной жизни — это хорошо. Отлично, что люди начали задумываться над этим и формировать профсоюзы. Если компания не стремится обеспечить здоровый баланс, сотрудники должны решить этот вопрос сами. При этом следует понимать, что не каждую игру получится сделать с 9 до 17 пять дней в неделю. Стремиться соблюсти баланс — это нормально, как и время от времени жертвовать им, чтобы сделать хорошую игру великой.
• Зачастую стремление работать чётко по графику приводит к счастливой семейной жизни с кучей посредственных игр в резюме, но и чрезмерная увлечённость может привести к потере 10 лет жизни, а что игры получатся хорошими — никто не гарантирует.

Предпочтения в ролевых играх

Создание персонажа:

• Тим предпочитает игры, где игрок создаёт одного персонажа и управляет им, поскольку это укрепляет связь игрока и персонажа, позволяя первому ассоциировать себя со вторым. Если у игрока есть чётко определённый герой, то и повествование обычно прописано под него. Кроме того, создание единственного персонажа улучшает реиграбельность, поскольку за одно прохождение вы можете отыграть лишь одну роль. Даже если в игре подразумевается управление отрядом, лучше, если игрок создаёт одного — своего — персонажа, а остальные присоединяются к нему позднее (как, например, в Pillars of Eternity).
• Важна комплексная ролевая система с характеристиками, навыками, способностями, чертами, предысторией персонажа и любыми другими механиками, которые придут в голову разработчику. Она должна позволять создавать огромное количество разнообразных персонажей. Разумеется, нельзя учесть все варианты, но желательно стремиться к тому, чтобы можно было создать любого вписывающегося в игровой мир персонажа.
• Тим предпочитает самостоятельно давать имена своим персонажам. Поскольку в современных играх принято полностью озвучивать диалоги, такое желание может стать проблемой, и разработчики по-разному выкручиваются из ситуации. Чтобы совместить оба подхода, они могут дать персонажу прозвище, по которому к нему и будут обращаться.
• Кейн не любит, когда ему отводят одну заранее заготовленную роль: «чем жёстче рамки, тем меньше мне это нравится».

Развитие персонажа:

• Опять же, сложноустроенная ролевая система с обилием возможностей для развития. Не обязательно посредством повышения уровня, хотя это и самый удобный способ отразить развитие персонажа. Прогрессию можно показать и через снаряжение: доступность более качественных предметов, возможность делать и улучшать их самостоятельно и так далее.
• Кейну особенно нравится, если развитие зависит от ранее принятых решений. Например, требования способностей к уровню развития определённого навыка или доступность способностей в зависимости от фракции и/или отношений с ней. Развитие персонажа — это один из вариантов награждения игрока, и поэтому нужно показать, что оно зависит от его действий.
• Игра должна полностью проходиться любым персонажем, которого можно создать предоставленными игроку средствами ролевой системы. Если игрок создаёт персонажа с акцентом на разговорные навыки, без скрытности и оружейных навыков, то игра должна подразумевать и такой вариант прохождения. Последние могут отличаться сложностью, но они должны быть. В конце The Outer Worlds встречается гигантский робот, но помимо лобовой атаки есть и иные способы одолеть его или хотя бы ослабить.
• В Fallout подразумевались три варианта прохождения: силовой (сражаться и убивать всех подряд), разговорный (пройти как можно больше игровых областей с использованием диалогов) и скрытный (избегать столкновений, прокрадываться мимо врагов, красть вещи). Можно попробовать реализовать и другие стили, например, исследование, которое отличается от скрытности тем, что в подразумевает навыки паркура, скалолазания, выживания в дикой природе, наблюдательности и так далее.

Повествование:

• Сюжет должен реагировать на персонажа, подразумевать выборы и последствия. Тиму не нравятся сюжеты, где всё жёстко заранее задано. «Терпеть этого не могу. Почему бы тогда просто не посмотреть киношку — она наверняка будет красивее, да и история подана гораздо лучше, поскольку её создатели могут контролировать темп повествования». Да, финал может быть один, но важно дать игроку развилки и выбор на пути к цели, ведь в зависимости от контекста он получит разные впечатления. Ключ от подземелья можно получить разными способами: украсть, купить, убедить отдать его бесплатно — так вы создаёте контекст, и если игровой мир реагирует на него, то даже при одинаковом финале впечатления от игры будут разными. Но лучший способ реализовать такой подход — это различные фракции, по-разному реагирующие на действия игрока.
• Кейн отмечает особо, что ему не нравится, когда разработчики заставляют отыгрывать «хорошего» или «плохого» персонажа. В Fallout и Arcanum они стремились к морально неоднозначным заданиям, когда идеального решения может не быть, и одни персонажи посчитают вас хорошим, а другие — плохим.
• А ещё лучше, когда в игре несколько концовок. Особенно Тиму полюбились финальные слайды (что хорошо заметно по его играм) — они сообщают игроку о последствиях принятых решений, дают понять, что он прошёл игру по-своему. Кроме того, они мотивируют на новое прохождение. Если после финальных слайдов есть возможность продолжить игру, то отражённое на слайдах должно проявиться и в самой игре.

Потерянное десятилетие

• «Потерянным десятилетием» Тим называет период 1993–2003 годы — в эти годы у него просто не оставалось времени ни на что, кроме разработки игр. Почти всё это время он работал минимум по 10 часов каждый будний день, а за несколько месяцев до того, чтобы обратиться к людям с просьбой поработать сверхурочно, сам переходил на 12-часовой график (в том числе по субботам). В моменты аврала же приходилось работать по 14 часов семь дней в неделю.
• За это время Тим не посмотрел ни одного нового фильма или сериала и не прослушал ни одного нового музыкального альбома.
• Во время упомянутых 14-часовых авралов Кейн редко бывал дома при свете дня, уходя на работу и возвращаясь обратно во тьме. Остального времени хватало лишь загрузить в стиральную машину бельё, поесть, посмотреть серию «Симпсонов» или немного позалипать в Everquest, которым Тим не на шутку увлёкся. За продуктами он ходил в круглосуточный магазин где-то в 2 ночи. Так продолжалось месяцами.
• В конце 1997 года соседи Тима решили, что он переехал, поскольку вообще не видели его, а по вечерам у него дома не горел свет — тогда Кейн купил специальные таймеры, включавшие по вечерам свет.
• Далее Кейн рассказывает, что после 2003 года он понял, что так дальше продолжаться не может, решил начать жить полноценно, зарегистрировался на сайте знакомств, встретил там умного и красивого архитектора, а дальше кринж и [роскомнадзор].

О процедурной генерации в Arcanum

• Компьютерам времён создания Arcanum не хватало памяти для хранения запланированного разработчиками объёма игрового мира, поэтому пришлось прибегнуть к процедурной генерации.
• Тайл в Arcanum — ромб 80×40 пикселей. Каждым тайлом представлено примерно пять футов игрового мира, а значит в миле примерно 1000 тайлов. Разработчики заготовили множество типов тайлов, соединяющихся лишь с ограниченным перечнем других типов тайлов. Например, к тайлам глубоководья могли примыкать лишь тайлы мелководья, а к последним — не только глубоководье, но и тайлы с песком (для создания берега). Типы тайлов также различались проходимостью: одни можно было свободно пересечь, другие были непроходимы. В зависимости от типа тайла (земля, песок, снег и так далее) менялось озвучение шагов — всего шесть вариантов. Тайлы можно было поворачивать, поэтому художники старались сделать универсальный вариант, позволяющий использовать тайл в разной ориентации.
• Более крупные единицы ландшафта — секторы — состояли из массивов 64×64 тайла, что составляет 5120×2560 пикселей или примерно 320 на 200 футов. Каждому сектору на карте мира присваивался уникальный номер в зависимости от координат по осям X и Y.
• На состоящую из секторов карту накладывался один из 32 базовых ландшафтов, среди которых вода, лес, горы, вода, луг и так далее. Базовый ландшафт использовался для процедурной генерации.
• По умолчанию карта состояла из 64×64 секторов. Для карт на открытом воздухе задавались параметры отображения дневного и ночного освещения. Кроме того, движок мог выводить различные наборы звуков (дневные или ночные) в зависимости от времени суток.
• Карта мира состояла из 2000×2000 секторов, большая часть которых приходится на центральный континент, что примерно равно 128×128 милям, где можно идти куда захочешь — огромный мир по меркам 90-х. В целом, движок поддерживал создание игрового мира размером более 67 миллионов секторов, а это 4,2 миллиарда тайлов, что теоретически позволяет создать в игровом редакторе мир со стороной 4,2 миллиона миль.
• Разработчики создавали мир в редакторе, который и шёл вместе с игрой. Мир создавался секторами, которым присваивался базовый ландшафт (трава, горы, вода и так далее). При открытии сектора его наполнение генерировалось случайным образом на основе отражающего его расположение в мире уникального номера. Для каждого базового ландшафта был собственный алгоритм генерации тайлов сектора, причём аргументом служил номер сектора, в результате чего, на каком бы компьютере его не открыли, результат генерации был одинаковым. Если разработчик изменял расположение объектов, сохранялась лишь разница между исходным результатом генерации и доработанным вручную, что эффективно использовало ресурсы компьютера. Но это работало не только в редакторе. Если в самой игре персонаж выбрасывал предмет на землю, то этот предмет сохранялся как изменение относительно исходного состояния сектора.
• Движок поддерживал размещение зданий непосредственно в игре, и они тоже сохранялись как изменения относительно начального состояния сектора. Для чего? Планировалось дать игрокам возможность возводить собственные постройки — примерно то же, что впоследствии появилось в Fallout 4. Также планировались изменяющие тип местности заклинания, но их тоже не успели реализовать.

Какую игру считать хорошей

• «В Интернете полно людей, высказывающих положительные и отрицательные мнения, и все эти люди претендуют на объективность и истинность своей точки зрения». Поскольку в пользу каждой приводятся те или иные аргументы, стоит попробовать их проанализировать.
• Один из первейших и главнейших аргументов в пользу качества игры — это её популярность. Под популярностью Тим подразумевает многочисленные обсуждения, стримы, количество одновременно играющих. Самой популярной из своих игр Кейн считает Fallout — и так было ещё до того, как права перешли к Bethesda. Если рассуждать с точки зрения популярности, то оригинальная Fallout — лучшая игра Тимоти Кейна.
• Более объективным способом оценить качество игры Кейн считает продажи. Продажи — это количество проданных копий, и с этой позиции лучшая игра Тима (с огромным отрывом от остальных претендентов) — The Outer Worlds. Отдельно Тим подчёркивает, что игроки склонны трактовать одни и те же метрики как за, так и против оценки игры. Например, если у игры хорошие продажи — значит она «казуальная» и не подходит для хардкорщиков, а покупателей таких игр они считают «шимпанзюками». Есть нюансы, но в целом, если игра хорошо продается, то вряд ли её можно назвать плохой. Один из таких нюансов — за 40 лет масштабы игровой индустрии выросли в разы, а потому неверно сравнивать «в лоб» продажи Fallout и The Outer Worlds. Значит, это не всегда хороший способ оценить качество игры.
• А что с оценками критиков? Лучшие оценки на Metacritic получили Fallout и Pillars of Eternity (у обеих по 89 баллов). Чуть меньше получила Fallout 2 — 86 баллов, далее идут South Park: The Stick of Truth и The Outer Worlds (85 баллов). Таким образом, по мнению игровых журналистов Arcanum и Vampire: The Masquerade — Bloodlines не входят в пятёрку лучших игр Тима. Его очевидный и банальный совет: не пытаться оценить игру по «средней температуре», а найти рецензентов с похожими вкусами и прислушиваться к их мнению. Однажды один журналист начал обзор игры Тима со слов «я не особо играю в ролевые игры, поскольку они мне не нравятся, но давайте поговорим об одной из них», и Кейн такой: «всё с тобой понятно».
• Некоторые оценивают игры по их продолжительности. Метрика довольно сомнительная, в том числе и потому, что предлагаемые разработчиками цифры неточны и условны. Если оценивать качество продукта по продолжительности его использования, то лучшим у Кейна будет The Bard’s Tale Construction Set, поскольку технически сидеть за ним можно бесконечно. Но самой продолжительной из своих игр Тим считает Arcanum, а значит по этому параметру она лучшая.
• Ещё одна крайне субъективная метрика оценки качества игры — её оригинальность. Многие считают, что самой оригинальной игрой Кейна была Arcanum. Разработчики стремились напихать в игру как можно больше идей, так что ничего удивительного. С другой стороны, на момент релиза Fallout не походила другие вышедшие игры. Изометрические игры были и раньше, но они постепенно отмирали, уступая место трёхмерным, тем не менее, есть у Fallout есть свои уникальные черты.
• И есть ещё такой критерий как стабильность, и в этом плане что Arcanum, что Vampire: The Masquerade — Bloodlines — плохие игры, да и The Temple of Elemental Evil вышла весьма сырой. Тим отмечает, что для многих это критически важный критерий оценки, поскольку такие игроки просто не могут стерпеть множественные глюки и закрыть на них глаза ради всего остального.
• Какой же вывод? Хорошая игра — это та, которая вам нравится.

Прототипы и структуры в Arcanum

• В конце 90-х у компьютеров было мало памяти, что заставляло разработчиков её экономить. В результате в Arcanum всё кроме тайлов ландшафта представляло объекты 18 типов (стены, порталы и так далее). Это довольно общие категории: под «существом» могли подразумеваться любые персонажи, включая игрового, а оружие, броня, боеприпасы, золото, еда, свитки, ключи и так далее считались предметами. Были подвижные объекты, местоположение которых могло измениться в процессе игры (но далеко не факт, что они могли двигаться самостоятельно). Или так называемые расходники — такие объекты исчезали сразу после использования. Каждый объект описывался набором полей, одни из которых уникальны, другие — универсальны. Среди таких полей: идентификатор художественного объекта, местонахождение, прочность, защита. Последние два параметра прописывали всем объектам на случай, если игроку понадобится их повредить или разрушить. У порталов и контейнеров могли быть уровни сложности взлома и идентификаторы ключей.
• Каждый объект в игровом мире указывал на прототип. Например, у прототипа ножа был уникальный идентификатор художественного ресурса (и поэтому нож выглядел как нож), он имел тип оружия и заданный диапазон урона, например, 1–6, тип урона, вес, стоимость и другие параметры. Если игрок находил в игровом мире нож, то в это место вставлялся идентичный прототипу объект, а затем к нему применялись параметры конкретного экземпляра. Некоторые параметры, например, местонахождение, были у объекта, но отсутствовали в прототипе. Как и в случае с генерацией ландшафтов, параметры конкретных объектов хранились в виде расхождения с характеристиками прототипов. При запуске игры в память подгружались все прототипы, а конкретные объекты подгружались с секторами, где они находились. Чтобы игрок не сталкивался с подтормаживаниями при подгрузке секторов, несколько соседних подгружалось заранее. Всё это позволило не только сэкономить память, но и уменьшить размер сохранений. С другой стороны, это сильно усложнило модификацию игры.
• Структуры (чаще всего здания, но сюда же относились подземелья и пещеры) создавались иначе. У структур были пол, стены и потолок (последний отсутствовал в пещерах и подземельях). Если нужно было вставить дверь или окно, нужно было выбрать их, а затем щёлкнуть в нужное место стены. При размещении окна вокруг него рисовалась рама — поэтому нельзя разместить окно на углу здания. Если рядом с одним окном вставить второе, то получится одно длинное. Примерно так же это работало и с дверями. Благодаря простоте инструментария Тарант создали довольно быстро.
• При этом подземелья устроены схожим образом, но разрабатывались по-другому. Разработчики будто бы прокладывали коридоры, врезаясь в камень, и стены появлялись сами. Унификация создания структур позволяла выполнять огромный объём работ силами одного человека. Создав структуру, дизайнер мог наполнить её объектами, например, мебелью, но поскольку все эти объекты имели прототипы, то для тех же столов и стульев в памяти хранились лишь указатели на прототип с единственным заполненным полем местоположения объекта.

Как быть хорошим руководителем проекта, часть вторая

• Одно из важных качеств хорошего руководителя проекта — научиться играть в игры аналитически, смотреть на них глазами разработчика, а не обычного игрока, стремящегося просто получить удовольствие. Вы смотрите на любой аспект проходимой игры и думаете, как поступили бы вы данном случае, и если иначе — то как.
• Руководитель проекта влияет на каждый его элемент (дизайн, программирование, озвучение и так далее), включая те, в которых он не разбирается. Тим долгое время боялся вмешиваться в работу команды озвучения, поскольку не играл ни на одном инструменте, что не помешало ему в итоге предоставить весь исходный материал для музыки в Fallout, потому что для него это было важно. По мнению Кейна, об озвучении игр вообще обычно думают в последнюю очередь, а ведь если в игре есть оружие, то звуки перезарядки, выстрела и так далее сильно влияют на впечатления от его использования.
• Со временем дальтонизм Тима развивался, но он всё равно продолжал высказывать художественную критику, будучи полностью уверенным, что она обоснованна, и потому, что наблюдал заметные расхождения с видением художников. Леонард Боярский постарался сделать так, чтобы Кейн остался доволен художественным оформлением The Outer Worlds.
• Руководитель проекта играет в него больше всех — нередко даже больше тестировщиков. Но если последние ищут технические ошибки и дисбаланс, то руководитель проекта оценивает работу всех его аспектов. Он должен проверить ключевые элементы дизайна: сражения, диалоги, скрытность, ремесленные механики, взаимодействие со спутниками и так далее — и, что самое важное, понять, как воспримет их игрок. При этом руководитель проекта должен быть гораздо критичнее обычного игрока.
• Все игроки разные, но вы должны сделать игру интересной для всех, а не только тех, кто играет как вы. Например, вам может не нравиться отыгрывать пацифиста, но нужно сделать и этот путь увлекательным.
• Руководитель проекта составляет документацию с основополагающими принципами дизайна, однако немалую часть документации пишут его подчинённые. Во время прохождения игры необходимо убедиться в отсутствии внутренних противоречий и полном соответствии вашему видению проекта.
• Сейчас много способов получить финансирование, а для этого нужно рассказать об игре. Будет ли она страшной, депрессивной, юмористической, где и сколько раз можно раскрыть тайны игрового мира — на все эти вопросы должен ответить руководитель проекта, ведь именно он знает игру лучше всех. Каждый специалист, будь то художник, дизайнер или программист лучше разбирается в своей специфике, но именно руководитель проекта видит его в целом. Он проверяет каждый уровень, предмет или персонажа на соответствие философии дизайна и настроению/атмосфере проекта.
• Ранее Тим уже упоминал, что медицинские навыки в Fallout следовало бы объединить, а ещё — добавить энергетическое оружие в первую треть игры — и это как раз те вещи, на которые он должен был обратить внимание как руководитель проекта.
• Руководитель проекта также отвечает за расстановку приоритетов. Собирать совещание со всей командой бесполезно, поскольку вы никогда не получите полного одобрения чего бы то ни было. Руководитель должен прислушиваться к мнению ведущих разработчиков, но решать всё равно ему.
• Нередко игроки возмущаются, как можно было выпустить игру с очевидными проблемами вроде дисбаланса определённых аспектов. Обычно это означает, что у разработчиков были другие приоритеты, которые поставил перед ними руководитель проекта. Да, в игре может быть дисбаланс, но вероятно потому, что вместо настройки баланса все пытались исправить критическую ошибку, из-за которой игра не работала вообще. Возражения по этому поводу понятны, но у разработчиков никогда нет времени воплощать все свои хотелки, да и не стоит за этим гнаться.

Предпочтения в разработке

• В разработке любой игры Тим уделяет большое внимание возможности выбора и реакции на него игрового мира. Однажды кто-то сказал Кейну: «Не могу поверить, что в вашей игре можно убить ребёнка!» А он ответил: «Она не заставляла вас это делать, но если вы знаете о такой возможности, это многое говорит о вас, и последствия будут очень плохими». Кейн не ограничивает свободу игрока, даже если он делает что-то плохое. Да, решение может быть плохим, и игра скажет, что это плохо, но она всё равно позволит вам это сделать. Ограничение выбора ведёт к ограничению последствий, что приводит к навязыванию морали.
• Кейну нравятся игры с серой моралью, где персонажи не однозначно хорошие или плохие. Игрок должен сам выбирать, быть ему хорошим или плохим, и жить с последствиями этого выбора.
• Создавая игры в чужих вселенных, Тим, разумеется, отступает от собственных правил. Например, в играх по D&D приходится использовать соответствующие механики мировоззрений, и из-за их ограничений он не хочет делать игры по D&D. Поэтому Кейн предпочитает работать с собственными наработками, а не лицензировать чужие. Исключения из этого «правила»: The Bard’s Tale Construction Set, The Temple of Elemental Evil, South Park: The Stick of Truth.
• Тим получил огромное удовольствие, работая над придуманной Джошем Сойером Pillars of Eternity, а также Tyranny, основы которой заложил Крис Авеллон, поскольку когда создатель вселенной находится совсем рядом, с ним всегда можно проконсультироваться, особенно в вопросах выборов и последствий. Таким образом, если создатель игрового мира не сам Кейн, то лучше, если он находится где-то рядом.
• Кейну не нравится разрабатывать продолжения. В своё время он высказал начальству нежелание работать над Fallout 2. У последнего в головах не укладывалось, как можно отказаться от продолжения столь великолепной игры. Тим же, отработав три с половиной года над оригинальной Fallout, мечтал реализовать новые идеи. Он восхищается людьми, способными посвятить игровой вселенной одно или несколько десятилетий своей жизни.
• Кейну нравятся игры с юмором. Последний встречается во всех играх Тима.
• Увлекательность важнее баланса, но дисбаланс может её испортить. Однако это нормально, если некоторые классы или варианты развития сильнее остальных. Преимущества и их поиск — это часть игрового процесса, и это — отдельное развлечение.
• Игроки должны сами создавать своих персонажей, а не брать заготовленных разработчиками. Если приходится навязывать игроку конкретного персонажа, Тим старается сделать его максимально безликим.
• В Fallout вопрос отправки жителя Убежища наружу решался голосованием. Это отвечает на вопрос, почему при создании максимально тупого персонажа его отправляли спасать Убежище. Так вот: его не отправляли спасать Убежище, его выгоняли, поскольку он всех задолбал. А через пару недель, возможно, послали бы кого-то более способного с этой важной миссией.
• Аналогично, в начале The Outer Worlds вы всего лишь замороженный колонист. На корабль напали, поэтому Финеас торопится и выбирает первого же попавшегося персонажа. Таким образом, предыстория остаётся на усмотрение игрока.
• Тиму нравится пробовать разнообразные сеттинги, поскольку они ему постоянно надоедают. Кроме того, он любит добавлять в свои сеттинги «изюминку». Так, например, действие Fallout разворачивается в постапокалиптическом мире, но такое уже было в Wasteland и других играх, поэтому Кейн добавил в игру ретрофутуризм — представления о будущем людей 1950-х годов. Arcanum — с одной стороны, типичное фэнтези в духе «Властелина колец», но этот мир переживал индустриализацию. The Outer Worlds — научно-фантастическая ролевая игра, но с элементами антиутопии, например, основанными корпорациями колониями.
• Что касается повествования, то здесь Тим отдаёт предпочтение нелинейности. У игрока должна быть свобода в прохождении сюжета. Последний должен реагировать на действия игрока, а не наоборот.
• В механики Кейн тоже добавляет остроты. Так, он считает, что до Fallout в компьютерных ролевых играх не встречалась механика перков, равно как он не припоминает отдельных диалогов для персонажей с низким интеллектом. В Arcanum были так называемые «очки судьбы», которые можно было использовать, чтобы повлиять на результаты броска виртуального кубика, нанести критический урон, полностью исцелиться и так далее — у игрока была могущественная сила, которую нельзя применять постоянно, но у него была своего рода страховка. Ещё в Arcanum был конфликт магии и технологии, и это не просто сюжетный ход, в игре присутствовал индикатор склонности к одной из сторон и соответствующая механика.
• Поскольку The Temple of Elemental Evil основывалась на D&D, пространство для новаторства существенно сужалось. Тем не менее, Кейн сделал так, чтобы мировоззрение отряда влияло на его состав — паладин и убийца не уживались. Мировоззрение отряда влияло и на начальные предыстории длиной в пару часов.

Генерация диалогов в Arcanum

• Тим особенно гордится системой генерации диалогов в Arcanum, поскольку она упростила работу сценаристов и позволила сделать больше меньшими силами.
• Над Arcanum работало 14 человек, и всего несколько из них писали диалоги. Инструмент генерации диалогов позволил им удвоить количество реакций персонажей на действия игрока.
• Система генерации диалогов включала множество операторов с различными опциональными параметрами, позволявшими вставлять определённый текст вместо того, чтобы писать его вручную. Операторы управляли не только отдельными строками текста, но и целыми ветками диалогов.
• В частности, благодаря операторам можно было задать гендерные параметры диалога, например, особенности диалога, если в нём участвуют двое мужчин, две женщины или мужчина с женщиной.
• Операторы могли учитывать социальный статус NPC, что особенно важно при переводе на японский, поскольку японцы придают этому аспекту огромное значение. Всего таких статусов было 11, в порядке убывания: аристократия, духовенство, маги, технологи, торговцы, стража, горожане, крестьяне, нищие, воры и бандиты. Таким образом, по социальному статусу горожанин выше крестьянина, а маг — технолога. Операторы могли проверять значения навыков и характеристики заклинаний, что прописывалось в опциональные параметры оператора.
• У любого NPC в Arcanum два уникальных оператора: это «приветствие» и «деньги». Если добавить последний, персонаж будет просить денег, и характер просьбы будет меняться в зависимости от его социального статуса. Таким образом, дворянин и нищий просят денег по-разному. Первый, например, скажет что-то вроде: «Уважаемый сэр, я прошу у вас небольшую сумму». В параметрах можно задать точное количество, однако по умолчанию сумма составляла 10 монет (но это не точно). Это один из хороших примеров, как одним оператором создавалась целая ветвь диалога. Если прописать оператор M с параметром 100, NPC сказал бы что-то вроде «Простите, сэр, не могли бы вы дать мне 100 монет?», на что игрок мог согласиться или же отказаться. В случае согласия указанная сумма вычиталась из средств игрока, и игра переходила к указанной строке диалога.
• Для персонажа игрока также использовалось множество операторов. Среди них: оператор благодарности (игрок благодарил NPC), бартера, проверки состояния сюжета (персонаж игрока мог поинтересоваться какими-то деталями текущего состояния сюжета — например, как попасть в определённое место, и получить лишь текстовое «направление» или с маркером на карте), завершения диалога (после которого NPC прощался с игроком), оператор «забудь/забей» (игрок мог ответить: «не обращай внимание», «мне уже всё равно»), запрос исцеления, оператор общих вопросов, оператор извинений (в различных вариациях), просьба потренировать персонажа игрока (в параметрах — конкретный навык), просьба к NPC применить навык или прочитать заклинание вместо вас (например, чтобы жрец воскресил персонажа).
• У персонажа игрока и NPC было два общих оператора: «оскорбление» (конкретный текст также зависел от социального статуса NPC, но не только — оскорбить можно было и по расовому признаку — и список оскорблений был огромным) и «слухи» (в параметрах можно было указать одно число, диапазон, несколько отдельных чисел — они определяли известные NPC слухи).
• Наборы слухов определялись текущим этапом развития сюжета, игровой областью и социальным статусом NPC (как и в других случаях, от него зависели конкретные формулировки). У оператора слухов было много опциональных параметров. Так, NPC мог потребовать денег — для этого оператор «слухи» динамически вставлял в диалог оператор «деньги» и всё это превращалось в многоуровневую ветвь диалога.
• Игровые задания были довольно сложноустроенными и у них было семь состояний: неизвестен, упомянут, принят, выполнен, завершён, завершён (другим игроком или NPC), провален. Неизвестен — когда игрок ничего не знает о нём, упомянут — игрок узнал, но не принял, принят — без комментариев, выполнен — задание выполнено, но не сдано, завершён — когда задание сдали. Иногда провал квеста можно исправить. Например, если у вас задание спасти похищенного персонажа, то вы можете прибыть на место, забрать NPC (состояние сменится на «выполнен»), но по дороге персонажа убьют (состояние «провален») — тогда вы можете воскресить его, и скрипт сообщит игре, что персонаж жив, и задание снова станет «выполненным». Провалить уже завершённое задание невозможно: если спасённого убьют после сдачи задания, то это уже не ваша проблема, и в дневнике оно не будет отмечено как проваленное. С заданиями связан диалоговый оператор Q, который меняет диалог в зависимости от состояния задания. Например, если игрок не слышал о похищении, женщина могла бы рассказать о похищении мужа, и тогда состояние задания сменилось бы на «упомянут», а дальше изменился бы и сам диалог — при повторном запросе на выдачу задания, она бы сказала, что уже рассказывала о похищенном муже, и спросила бы, собирается ли игрок его искать. Если же задание имеет статус «принят», женщина спросила бы, почему игрок до сих пор не ищет её мужа, а если игрок привёл к ней похищенного (статус «выполнен»), она бы поблагодарила его, и статус задания сменился бы на «завершён», после чего оператор Q отдавал бы что-то вроде: «Я бесконечно благодарна тебе до самой смерти».
• Но самым сложным оператором было всё-таки «приветствие». Причина — в невероятной вариативности, именно здесь, по словам Тима, Arcanum проявлял большую часть реакций на персонажа игрока и его действия. Для генерации приветствия использовалось множество проверок, первая из которых — не мёртв ли NPC (вы не можете разговаривать с мёртвым персонажем, если только не применили соответствующее заклинание). Вторая проверка — нет ли с персонажем поднятых мертвецов, призванных существ или иллюзий (это три отдельные проверки со своими фразами в диалоге). NPC-маг мог бы саркастически заметить, что научился призывать элементалей огня ещё в 15 лет или что поднятый мертвец запачкал пол, а обычные люди сказали бы, что вид нежити их пугает и отказались бы разговаривать. Третья проверка — какие заклинания действуют на игрока, в следующем порядке: невидимость, тело из воздуха/камня/огня/воды, полиморф, зеркальное отражение и уменьшение. Для каждого заклинания был свой набор комментариев. Персонаж-маг попросил бы игрока снять невидимость или смену формы, но всё равно продолжил бы общаться, чего не скажешь о других NPC, которые отказались бы говорить с персонажем в форме овцы или под невидимостью («Кто здесь, призрак?»). Обычный NPC отреагировал бы на уменьшение персонажа и продолжил диалог, а в случае зеркального отражения спросил бы, к кому именно обращаться. Четвёртая проверка — наличие верхней одежды или брони. Реакция на персонажа в одном лишь нижнем белье зависела от социального статуса NPC. Также были отдельные реакции на броню варвара: аристократ мог бы сказать, что это варварство, а торговец мог бы отметить, что редко встречает варваров. Ещё одна проверка — отношение к персонажу. Обращение могло быть восторженным, дружелюбным, нейтральным, подозрительным, отрицательным (например, если NPC не нравилась раса персонажа игрока) и враждебным — и всё это с вариациями по социальному статусу NPC. Более того, учитывалось, общались ли вы с этим персонажем или нет — для первой встречи были одни приветствия, для последующих — другие. Например, при первом посещении магазина торговец мог бы спросить «Вы впервые здесь? Не хотите ли посмотреть товары?», а при втором — «Как приятно видеть вас снова!» Сценаристы могли запретить любые из этих проверок, либо сделать их обязательными.
• Тим неоднократно предлагал реализовать подобную систему приветствий в других проектах, но ему отказывали. С развитием больших языковых моделей он надеется, что можно будет не только повторить, но и значительно улучшить эту механику.

Игровые движки

• Кейна часто спрашивают, предпочитает ли он создавать собственные движки или покупать готовые, и почти всегда речь идёт о Unity или Unreal.
• Тим начал работать в игровой индустрии в 1981 году, и первые 20 лет у него не было выбора. Движки всегда приходилось писать, поскольку ничего готового не продавалось.
• В отличие от Кейна, многие программисты в Interplay (и не только) отказывались делиться кодом с другими, а по необходимости отдавали лишь предварительно откомпилированные библиотеки.
• За одним исключением (очевидно, Vampire: The Masquerade — Bloodlines, в которой использовался Source от Valve) с 1981 по 2014 годы Тим пользовался движками, написанными внутри студии, где он работал. Движки для Bard’s Tale, Fallout, Arcanum, The Temple of Elemental Evil и South Park Тим писал самостоятельно (в последней использовался собственный движок Obsdian Entertainment (Onyx), разработанный для Dungeon Siege 3). C 2014 года Тим выпустил Pillars of Eternity и Tyranny на Unity, а также The Outer Worlds на Unreal.
• Главное достоинство собственного движка — возможность сделать именно то, что хочешь. Для достижения цели разработчику не приходится городить сложноустроенные и отжирающие кучу ресурсов костыли. В случае с Unity вы должны сразу определиться, делаете ли вы 2D или 3D игру, но в любом случае используется множество лишних компонентов, которые впустую расходуют ресурсы компьютера. Следующее достоинство собственного движка — это обладание исходным кодом. По словам Тима, у него есть исходный код Arcanum и The Temple of Elemental Evil, и он его отлично знает. Ближе к концу разработки наступает время оптимизации и отладки проекта, и когда вы уже знаете код наизусть, сделать это намного проще. Так что третье преимущество в том, что можно оптимизировать конкретные элементы игры. Например, если в игре много работы со светом, вы можете оптимизировать соответствующие функции, а не использовать написанные кем-то ещё, выбирать из нескольких вариантов или отказываться от них вовсе. Плюс лично для Тима — он любит писать движки сам.
• Что касается недостатков своих движков, то главный — «вам понадобится много времени, денег и людей» на переизобретение не одного «колеса», а сразу нескольких, при этом далеко не всем и всё удаётся сделать лучше, чем профессиональным разработчикам готовых коммерческих движков. Например, вы можете быть отличным программистом, но плохо разбираться в работе графических процессоров, сетевых карт, интерфейсов операционной системы, распределения памяти в ней и так далее. Всё это нужно знать не хуже, чем программистам готового платного движка.
• Одно из преимуществ готовых движков — «они сразу работают». Кейн испытал огромное облегчение, когда Pillars of Eternity запустилась уже в начале разработки, без создания множества прототипов. Что касается последних, то благодаря наличию множества бесплатных библиотек ресурсов, их разработка тоже заметно ускоряется. Второе важное преимущество — найти разработчиков под готовые движки не так уж и сложно, и с каждым годом становится всё проще, ведь рынок фактически поделили Unity и Unreal. Да и самим разработчикам нравится работать с популярными движками, поскольку они набираются навыков, которые пригодятся им в других проектах и компаниях. Если последние думают, что собственный движок поможет удержать сотрудников, то новички, напротив, задумаются, а стоит ли тратить время на освоение движка, который им больше нигде не пригодится. Третье преимущество — вы покупаете не только движок, но и поддержку компании-разработчика, которая может быть значительно больше вашей, и наверняка в ней работает гораздо больше программистов. Вы можете сообщать им об ошибках движка, и они их исправят. Кроме того, у разработчика движка обычно много специалистов, которые отлично понимают работу отдельных функций или модулей, для написания которых к собственному движку пришлось бы долго учиться или нанимать отдельного (и недешёвого) сотрудника.
• Среди недостатков готовых движков Тим упоминает медлительность поддержки. Разработчики готовых движков вынуждены расставлять приоритеты, и если вы не крупная компания, создающая дорогущий блокбастер, или у вас нет нужных знакомств, ваши запросы на исправление ошибок могут оказаться в самом низу списка. Чаще всего приходится долго ждать обновления движка, и далеко не факт, что досаждающую вам ошибку исправят. В случае с Unity у разработчика игры нет доступа к исходному коду, поэтому остаётся только ждать. В случае с Unreal можно забуриться в исходный код и попробовать исправить проблему самостоятельно, однако даже если это получится, после каждого обновления движка процедуру придётся повторять. Второй важнейший недостаток коммерческих движков — необходимость делиться прибылью. Большинство разработчиков движков перешло от фиксированной платы к отчислениям с продаж. Небольшим разработчикам это может быть даже выгодно, поскольку движок обходится им бесплатно или почти бесплатно, но если игра вдруг выстрелит, придётся отдать часть денег Unity или Epic.
• В идеальном мире с неограниченным временем разработки и бюджетом Тим всегда бы писал собственный движок. Но поскольку это не так, то если разработчик не планирует создавать игры на одном движке десятилетиями или у него нет возможности писать для каждой игры новый движок, лучше купить готовый. «Скорее всего, в какой-то момент вы всё равно перейдёте на Unity, Unreal или что-то ещё — это неизбежно и вам придётся с этим смириться».

Реализация случайности

• В Fallout использовался линейный конгруэнтный генератор псевдослучайных чисел — очень простой генератор с большим периодом, который отлично справлялся с генерацией случайных чисел.
• Тем не менее, однажды один из сотрудников Interplay зашёл в кабинет Кейна и сказал, что этот генератор ужасен, и его нужно починить. Человека возмутило, что он промахнулся три раза подряд при отображаемой игрой вероятности попадания 95 %. Тим начал считать: шанс попадания в 95 % означает, что вероятность промаха составляет 5 %, то есть 1 к 20. В таких случаях игроки обычно ожидают, что из 20 выстрелов они промахнутся лишь раз, но это так не работает. Генератор случайных чисел не удаляет из доступных уже выброшенные числа, таким образом, при каждом броске может выпасть единица. При таких вводных вероятность промахнуться два раза подряд составляет 20 в квадрате, то есть 1 к 400, а три раза подряд — уже в кубе, то есть 1 к 8000. Кажется, будто это практически невероятное стечение обстоятельств, но когда ты работаешь тестировщиком 40 часов в неделю, делая по 200 выстрелов в час, то раз в неделю такое может случиться. «Ты уже не первый месяц тестируешь эту игру, я ожидал, что этот случай будет у тебя далеко не первым», — сказал ему Тим.
• Однажды звукорежиссёр Wildstar поручил Кейну сделать так, чтобы пять фоновых звуковых дорожек включались в случайном порядке. Разумеется, Тим просто воспользовался генератором целых чисел от 1 до 5. На следующий день к нему зашёл этот звукорежиссёр и заявил, что дорожки нередко повторяются, на что Кейн ответил, что так всё и должно работать. Вероятность услышать одну и ту же дорожку два раза подряд составляла 20 %, но звукачу хотелось, чтобы они никогда не повторялись. Тогда Тим сделал так, чтобы если при новой генерации выпадало совпадающее с предыдущим число, генератор перезапускался. На следующий день звукорежиссёр пришёл снова и показал результат. Они с Тимом услышали сначала первую дорожку, потом вторую, затем снова первую. «Работает, как и задумано», — сказал Кейн, но звукорежиссёр возразил, что не услышал 3, 4 и 5 дорожки. Он хотел, чтобы все дорожки были отыграны в случайном порядке, а затем этот цикл следовало перезапустить. По мнению звукорежиссёра именно так и выглядела случайность, на что Кейн возразил, что никакой случайности в этом нет, ведь если ты уже прослушал четыре дорожки, то точно знаешь, какая пойдёт пятой. Так что на самом деле проблема была в изначально неправильно поставленной задаче, настоящая случайность в которой не требовалась.
• Ещё одна история из разработки Wildstar. Однажды к Кейну заглянул дизайнер и попросил добавить случайности в систему распределения трофеев. Он хотел сделать так, чтобы при убийстве определённого монстра выпадала добыча с вероятностью 20 %, то есть примерно с каждого пятого убитого. Как и звукорежиссёр, этот дизайнер не хотел настоящей случайности, но поставил задачу именно так. На следующий день он пришёл к Кейну и заявил, что убил 10 монстров подряд и добыча не выпала ни разу. «Такое бывает», — ответил Тим, но дизайнера это не устроило и он предложил увеличивать шанс выпадения трофеев каждый раз, когда из монстра ничего не выпало. На следующий день дизайнер пришёл снова и сказал, что убивает монстров пачками, но частота выпадения добычи кажется ему недостаточной. Он предложил добавить фиксированное количество убийств, после которого что-нибудь обязательно выпадет. И с этим Тим тоже блестяще справился, вот только к случайности это не имело никакого отношения. Когда после каждого сотого убийства обязательно что-то да выпадает — это не случайность. Через две недели тот же дизайнер пришёл снова и пожаловался, что при вероятности критического попадания в 20 % он сделал 10 выстрелов, и ни один из них не был критическим. Кейн поступил так же, как и с добычей.
• Когда дизайнер или любой другой специалист кроме программиста просит добавить в игру случайность — практически всегда он имеет в виду что-то другое. «Забавно, что умные люди используют слово, значение которого не до конца понимают».
• Набравшись опыта, Кейн как программист научился видеть за словами настоящие желания разработчиков. Это невероятно полезный навык, в том числе и при чтении отзывов об играх. Люди нередко высказывают пожелания, но на самом деле хотят чего-то другого. Возможно, им не хватает словарного запаса, они не склонны к самоанализу, либо просто не могут передать свою мысль словами.
• Если вы дизайнер или программист, стоит внимательно изучить значения терминов и выражать свои мысли как можно точнее.

Шесть демоверсий Fallout

• Первая демоверсия Fallout появилась в ноябре 1995 года — через год после начала полноценной разработки командой и через полтора от момента, когда игрой занялся сам Кейн. Она предназначалась исключительно для внутреннего использования. О ней осталось мало упоминаний, но Тиму кажется, что для неё сделали уникальную карту и основной целью было показать работу огнемёта. Исполнительный продюсер Алан Павлиш сказал тогда, что игра сильно тормозит. Это было вполне объяснимо, поскольку на столь раннем этапе разработки мало кто думает об оптимизации. Брайану Фарго демка понравилась, особенно он отметил анимации смерти. Удивительно, что Steve Jackson Games также положительно отозвались о них, но впоследствии резко поменяли мнение и заявили, что они выглядят чересчур жестоко.
• Вторая демка была готова в мае 1996 года — её делали для выставки E3. Примечательна она тем, что была уже вполне играбельной. В ней было две карты, диалоговая механика, торговля, убийства и поиск интересных предметов — и всё это составляло миниатюрное приключение, в котором игрокам предстояло убить несколько радскорпионов. Эти две карты вполне могли быть Шейди Сэндс и Джанктауном, а ещё там была пещера с этими самыми радскорпионами. В награду игрок получал несколько крутых предметов, однако пройти демку смогли не только лишь все: разработчики заметили, что многие подходили, играли несколько секунд и уходили. Впереди оставалась ещё пара лет разработки.
• Третью демоверсию выпустили всего через несколько месяцев — для очередной выставки в июле 1996 года. Разработчики хотели показать ту же демку, но маркетологи настояли, что нужно сделать новую. О ней Тим не помнит вообще ничего, кроме того, что на её создание ушло несколько недель.
• Четвёртая демоверсия была неинтерактивной. Её сделали в августе 1996 года специально для журнала Computer Gaming World. В то время игры были довольно маленькими, поэтому зачастую для подобных демонстраций было проще собрать полноценную демку, при запуске которой скрипт выполнял на движке последовательность действий, но в этот раз решили записать видео, поскольку несмотря на размер, видео воспроизводилось стабильнее и плавнее, особенно на слабых компьютерах. На диске с видеодемкой Computer Gaming World окрестили Fallout «духовной наследницей Wasteland» — Тим не помнит, была ли это инициатива Interplay или мнение редакции журнала, но он на 99 % уверен, что разработчики об игре ничего такого не говорили, ведь (как уже не раз подчёркивал Кейн) они старались сделать не продолжение чего бы то ни было, а нечто своё — отчасти потому, что не хотели давать игрокам ложные надежды. Люди слышат, что «Arcanum/The Outer Worlds — игра от разработчиков Fallout», и у них складываются определённые ожидания. Но это всё на совести маркетологов, и ни сам Тим, ни другие разработчики не могут на них повлиять.
• Пятая демоверсия вновь была неинтерактивной, и появилась в октябре 1996 года, и снова в формате видео. И о ней Тим не помнит ничего, кроме того, что отказался делать для маркетологов новые демки, поскольку ему нужно было заниматься разработкой основной игры — он потребовал обходиться тем, что есть. На создание каждой демки уходили недели, и поскольку ни одна из выпущенных демок не входила в план разработки, команда потеряла в общей сложности восемь недель, которые можно было потратить с большей пользой.
• Однако через полгода шестая демоверсия Fallout всё же вышла — её опубликовали в апреле 1997 года, и именно она обрела всеобщую известность. В ней был полноценный интерактивный игровой процесс, она запускалась на ПК в DOS и Windows 95, а ещё была версия для Mac. Кроме того, разработчики представили давно готовый вступительный ролик игры. Действие разворачивалось в Джанктауне, который был примерно таким же, как и в полной версии игры, а вот сюжет разительно отличался, поскольку разработчики не хотели раскрывать карты раньше времени. Кроме того, чтобы сократить размер демки до 20 мегабайт или меньше (а её ещё нужно было скачать) пришлось уместить приключение на одной карте. Через неделю выпустили ещё одну, зацензуренную версию «без насилия» для стран, где игру могли признать излишне жестокой — в ней было гораздо меньше анимаций смерти, что дополнительно сократило её размер. Некоторые анимации были весьма продолжительными, и занимали довольно много места.
• Незапланированные демоверсии привели к авралам. Они были не единственной причиной, но внесли немалый вклад. Тим не знал, как управлять проектом и командой, он не знал ничего о лидерстве и работе в чудовищном кошмаре под названием Microsoft Project. О необходимости сделать очередную демку всегда сообщали внезапно, начальство же считало, что их создание — не повод менять график разработки. «Крутись как хочешь», — говорили Кейну.
• «Нам не стоило выпускать эти демоверсии, но зайдите на Mobygames и посмотрите, сколько игр Interplay вышло с продюсерами, которые больше никогда не появлялись в титрах. Они пытались противостоять системе, и их уволили». Так что причины переработок не всегда были в самих разработчиках или даже их непосредственном начальстве. Просто маркетологам позволили заставить людей потратить восемь недель на создание демоверсий, но бюджет и сроки никто увеличивать не собирался. «Крутись как хочешь».

Оптимизация

• Зачастую оптимизация — это поиск компромисса между скоростью и компактностью кода. Скорость определяется количеством затраченного на выполнение задачи процессорного времени, а компактность — количеством занимаемой памяти. «Быстрый» код нередко занимает больше памяти, а компактный — исполняется медленнее, однако в редких случаях удаётся и «ускорить» код, и сделать его компактнее.
• Кейну часто приходится объяснять разбирающемуся в программировании начальству, что не стоит оптимизировать проект сразу после его начала — необходимо выждать время и посмотреть, на что уйдут основные ресурсы компьютера. Тим снова припомнил первую демоверсию Fallout и её медлительность, что было абсолютно нормально, поскольку внесённые на ранних стадиях разработки оптимизации могут впоследствии оказаться бесполезны, потому что появился новый код, новые функции, а часть старого убрали или переписали.
• Хороший пример рассказанного выше — механизм прототипов в Arcanum, позволивший заметно сэкономить память ценой небольшого увеличения нагрузки на процессор. «Колоссальная экономия памяти» стоила дополнительных трат процессорного времени на извлечение необходимых данных.
• 15–20 лет назад была в ходу оптимизация переписыванием с языка C++ на обычный C, который лучше оптимизировался компилятором. Иногда начинался настоящий хардкор: часто используемые участки кода на C переписывали на ассемблер.
• Многие современные молодые неопытные программисты не умеют даже толком работать с компилятором. Если на выходе из компилятора появляются какие-то проблемы, они начинают наугад отключать флаги оптимизации, пока всё не заработает снова. Тим не любит, когда что-то делается без понимания происходящего. С другой стороны, он признаёт, что зачастую так получается быстрее заставить работать код, нежели копаться вручную в ассемблере.
• Когда только появились первые видеокарты, приходилось отдельно оптимизировать игру под каждую, ведь все они сильно отличались друг от друга. Зачастую дело касалось даже не оптимизации — сложно было написать код так, чтобы игра запускалась на любой видеокарте. Но и сейчас есть определённые нюансы с оптимизацией игр под консоли с разным аппаратным обеспечением.
• Среди современных программистов бытует мнение, что оптимизация не важна, и хотя Тим понимает, откуда растут ноги этого убеждения, он с ним не совсем согласен. В современных играх он постоянно видит нерациональное использование процессора и памяти. Например, нередко значение переменной пересчитывается при каждом обращении к ней, даже если ничего не изменилось. Или создаётся огромный массив данных, из которого потом извлекается единственный элемент. Например, в одном из проектов Тима программист запросил перечень всех существ в игровой области, чтобы определить ближайшее к игроку, но всё ещё сложнее: вызывалась функция, которая собирала перечень всех объектов в игровой области, вычленяла из них существ и формировала массив, который сортировался, затем выбирался первый элемент, а все остальные отбрасывались. Тим заменил всё это технопорно на функцию, которая при перемещении существ вычисляла расстояние до персонажа игрока — так и определялось ближайшее к нему существо (при гибели которого функция перезапускалась).
• Одна из самых распространённых операций — сортировка, но нет одного подходящего на все случаи жизни алгоритма. И хотя на небольших объёмах данных они действительно справляются с задачей примерно одинаково, на больших лучше подбирать подходящий под конкретные параметры.
• Таким образом, оптимизацию откладывают на самый конец разработки, и предсказать необходимое на неё время довольно трудно («не уверен, что встречал хоть одного программиста, который мог бы предсказать время, необходимое для оптимизации кода — а о всяких продюсерах и говорить нечего»). Кроме того, трудно найти программиста, который умеет оптимизировать код. Нередко программисты просто наугад перебирают различные методы и алгоритмы, наблюдая за изменением в потреблении ресурсов и скоростью выполнения кода.
• Оптимизация — это задача не только программистов, но и художников с дизайнерами. Например, стоит поразмыслить, нужно ли в вашем проекте динамическое освещение, если в нём нет подвижных источников света. Если таковые всё же есть, стоит определиться с их максимумом.

Вопросы без однозначных ответов

• Изометрия или вид от первого лица. Раньше у разработчиков не было особого выбора, и Fallout была изометрической не потому, что это был лучший вариант для этой игры — разработчики перепробовали несколько движков, и именно изометрический вариант выглядел лучше всех (хотя выбора, опять же, особо и не было). Игры от первого лица того времени были низкополигональными, да и разрешением текстур похвастаться не могли. Изометрия отлично подходит для тактической боёвки: игрок видит местность, врагов, может оценить различные факторы, управлять отрядом. С другой стороны, при игре единственным персонажем отлично раскрывается вид от первого лица. Он обеспечивает лучшее погружение: игрок видит происходящее словно своими глазами, может бродить по миру, заглядывать в различные закоулки, а разработчикам не приходится думать, что делать с мешающими обзору в изометрии крышами и стенами.
• Сложные или простые игровые механики. Простые механики привлекают больше игроков: чем проще механики игры — тем она популярнее. Однако всегда можно воспользоваться принципом постепенного усложнения, то есть на первых порах предложить простые механики, которые будут усложняться по мере прохождения. Это отчасти повторяет современный подход Тима к подаче информации об игровом мире: в прошлом разработчики любили навалить «лора», теперь же Тим старается не перегружать игрока сведениями, давая лишь самое необходимое, а дополнительное вынося в книги и сведения от второстепенных. Если при создании персонажа игрока завалить тоннами информации, он не поймёт, что важно, а что нет, ведь он ещё не играл. Один из способов избежать этой проблемы — дать пройти обучение и определиться с предпочтениями или для начала выбрать пол, внешность и имя, а остальное оставить на потом.
• Определённость и неопределённость. Кейн предпочитает элемент случайности не только в боевых системах, но и в проверках навыков (взлом замков, обезвреживание ловушек, убеждение). Он прекрасно понимает, что современные игроки при таком подходе будут просто сохранять игру на каждом шагу и загружаться до победного. Поэтому для борьбы с этим применяются жёсткие проверки — например, когда убедить персонажа можно лишь с навыком 50 или выше, и никак иначе.
• Работа в небольших или крупных студиях. «В маленькой команде ты знаешь всех, кто над чем работает, достоинства и недостатки каждого, и исходя из этого можно распределить работу». Разработка идёт быстрее, обратная связь появляется чаще, меньше бюрократии. Однако в небольших командах требуется доверять друг другу и полагаться на остальных. Тем не менее, большую современную игру с открытым миром, видом от первого лица и крутой графикой не сделать малыми силами, а там уже нужны различные продюсеры, координаторы отделов и так далее, что приводит к засилью политики и бюрократии, а значит и некоторым явлениям, не идущим на пользу проекту. Тим не умеет в политику, поэтому с опаской относится к крупным командам.
• Балансировка универсальных и специализированных персонажей. В играх можно реализовать оба пути со своими достоинствами и недостатками. В своих первых играх Тим делал акцент на специализацию, но впоследствии осознал, что неплохо бы поддержать и персонажей-универсалов, что видно ещё на примере Arcanum. Универсальные персонажи дают игроку больше возможностей, но в среднем их навыки слабее, чем у специализированных. Поскольку по задумке разработчиков игра должна проходиться любым персонажем, проверки навыков на заданиях основного сюжета занижены. Напротив, специалист получает определённые преимущества, но некоторые сюжетные задания становятся существенно сложнее, ведь ему доступен лишь один вариант их выполнения, и он может быть не самым простым. Зато некоторые побочные задания могут оказаться проще, поскольку правило «Сила, скрытность, слово» (или «Убей, укради, уговори) на них не распространяется, и никто не ориентируется на персонажей с минимальными уровнями навыков. В The Outer Worlds самые крутые уровни навыков — это первый и последний. Таким образом, игра поощряет как универсалов, так и специалистов в своём деле.

Искусственный интеллект в Arcanum

• Стоя в центре сектора (область 64×64 тайла, об этом говорилось в видео о генерации ландшафта в Arcanum) вы видели на экране лишь его. По мере приближения к краю сектора, в память подгружались соседние (взамен удалённых), а максимум видимых на экране секторов составлял четыре (это означало, что разработчикам не требовалось держать в памяти больше четырёх секторов одновременно). Загружалась не только графика, но и оживающие после загрузки существа.
• В отличие от анимаций, искусственный интеллект работал по «тикам» продолжительностью в три секунды. По мере приближения игрока к существу промежуток между «тиками» сокращался. Очевидно, что это стало следствием оптимизации под вычислительные мощности процессоров того времени — разработчики попросту не могли себе позволить обрабатывать ИИ всех окружающих существ в максимальном «разрешении».
• У существ было четыре основных состояния искусственного интеллекта: мирное, боевое, бегство и капитуляция. Существа убегали, когда их здоровье падало до определённого низкого уровня, но у некоторых этот уровень был установлен в ноль, и они никогда не сбегали. В состоянии капитуляции существо просто переставало сражаться.
• Когда атакующий нападал на жертву, это замечали. Вокруг нападающего и жертвы формировались два круга, радиус которых зависел от заметности атаки, поэтому скрытные атаки всегда лучше. Все атаки делились на незаметные, обычные, заметные — и в зависимости от этого вокруг нападающего и жертвы появлялись области, в радиусе которых все узнавали об атаке. Тим не помнит точно, но ему кажется, что местоположение нападающего точно раскрывалось лишь если жертва видела его, в противном случае окружающие персонажи узнавали лишь примерное положение нападающего, и отправлялись в этом направлении. Зачем нужны эти области? Нападающий «сообщал» союзникам в радиусе области, что нападает на кого-то, «предлагая» присоединиться, жертва же делала примерно то же, но уже с позиции защиты.
• К трупу любого персонажа привязывалась информация об убийце. Каждый раз при обнаружении трупа NPC пытался понять, какое ему до него дело. И NPC было не всё равно, если убитый принадлежал к его фракции (а страже — всегда). В таком случае NPC начинал искать убийцу, и занимался этим 15 игровых минут, при условии, что персонаж игрока не приблизится к трупу.
• Через 24 часа труп исчезал, оставляя лишь пятно крови. Пятно крови исчезало через два дня. Так что через два дня следов преступления не оставалось.

Размер команды

• В целом, для разработки игр с каждым годом требуется всё больше людей.
• Тим работал как в маленьких (3–4 человека), так и в больших (около 200 человек) командах. В среднем в 90-е игры разрабатывались командами 15–30 человек, но в 2000-х они начали разрастаться, и в 2010 году типичная команда разработчиков включала 50–60, а иногда и 70–80 человек.
• У больших команд есть свои достоинства и недостатки, которые меняются на противоположные в случае маленьких. Главное преимущество большой команды — возможность сделать большую игру. В случае маленькой команды крайне сложно сделать длинную и увлекательную ролевую игру с современной графикой. Люди ждут определённого уровня технического исполнения, продолжительности, количества персонажей и игровых областей, и эти ожидания трудно удовлетворить небольшой командой. Кроме того, лишь большим командам по зубам создать и поддерживать какую-нибудь MMO.
• Большие команды тяготеют к специализации. В 80-е и 90-е годы Тим был мастером на все руки: продюсером, дизайнером, программистом. В больших командах может быть отдельный программист освещения или пиксельных шейдеров, художник по освещению и ничему больше. В отдельную касту выделились и сценаристы. Раньше повествованием занимались другие специалисты в дополнение к основным обязанностям, теперь же в проектах есть так называемые «дизайнеры повествования», да и те могут делиться на описывающих мир, пишущих диалоги и так далее.
• В больших командах обычно есть управляющий сообществом — человек, который занимается постами в соцсетях, форумами, отвечает на вопросы игроков по конкретному проекту. Он особенно полезен, если нужно поучаствовать в конференции или выставке. Управляющий сообществом может донести до разработчиков часто задаваемые игроками вопросы, а значит можно заранее заготовить ответы на некоторые из них.
• «Чем больше рук — тем меньше работы», то есть если разделить работу на множество специалистов, её сделают быстрее и эффективнее. Кроме того, в разработке много рутины, а значит если выдать её всем понемногу, то меньше вероятность, что кто-то выгорит.
• Большие команды (теоретически) позволяют ускорить разработку за счёт конвейерного производства. Если в крупной команде освобождаются специалисты, их можно перевести на подготовку следующего, и так далее. Кроме того, на разных этапах разработки необходимо разное количество специалистов определённого профиля, а значит можно перебрасывать людей между проектами. Например, в самом начале разработки требуется много концептуальных художников, в середине меньше, а в конце, когда начинается оптимизация и исправление ошибок — они и вовсе не нужны.
• К сожалению, в больших командах требуется много усилий для отслеживания и синхронизации работы множества специалистов, поэтому чем масштабнее проект, тем больше совещаний, согласований и переписок, документации, баз данных и ошибок, и с расширением команды все эти проблемы усугубляются в геометрической прогрессии. «Распределять задачи и поддерживать слаженную работу двух человек гораздо проще, нежели сотни», поэтому у вас появляются продюсеры и прочий производственный персонал, который сам ничего не разрабатывает, но помогает разработке не встать колом.
• Чем больше команда, тем меньше люди знакомы друг с другом. У вас может быть 2–3 друга, 20–30 приятелей, но если в команде уже больше 50 человек, то будет немало людей, которых вы вообще не знаете. Это нередко приводит к недоразумениям и взаимному недоверию. Люди начинают думать, что именно они вкалывают, а остальные только вату катают.
• В больших командах крошечные проблемы превращаются в огромные. Пусть у вас появляется издатель, который требует добавить в игру новый язык. Если у вас скромный проект на 10–20 тысяч слов — это одно, когда слов полмиллиона или миллион — это другое. При этом большое значение имеет какой это язык. Тут и сложность перевода, и необходимость добавлять новые шрифты, и, возможно, менять текст в зависимости от рода, а ещё в некоторых языках учитывается социальный статус собеседников, и тогда локализаторы начинают задавать вопросы, кто и с кем говорит, и всё это требует глубокой доработки игры. Или, скажем, вы немного (процентов на 10) ошиблись с оценкой времени разработки определённой механики. В случае небольшого проекта цена такой ошибки измеряется десятками тысяч долларов, что может показаться немалой суммой, если не учитывать, что в действительно масштабных проектах такая ошибка может стоить миллионы. А ещё команды могут состоять из нескольких сотен человек в самых разных часовых поясах, что накладывает дополнительные ограничения.

Вовлечённость игроков

• О вовлечённости игроков заговорили относительно недавно. Раньше Тим думал не о вовлечении игроков, его больше волновало, что интересного он может добавить в проект, чего ещё не было в других играх. Вовлечённость отличается от зависимости: последняя — это обещание награды, для получения которой нужно обязательно продолжать играть. Зависимость во многом опирается на случайность вознаграждения — она проявляется как у людей, так и у животных, и от неё сложно избавиться. Случайное вознаграждение — это когда вы периодически даёте игроку желаемое, и эта стратегия нашла применение во многих играх, особенно мобильных.
• Вовлечённость — это ощущение погружения в игру, сопричастности, желания взаимодействовать с ней. Ключевое отличие от зависимости: игрок не ждёт вознаграждения — ему нравится сам процесс. Есть множество способов улучшить вовлечённость.
• Один из лучших — разнообразить игровой процесс. Это не связано с вариантами развития персонажа, речь о различных типах геймплея. У игрока должна быть возможность сражаться, исследовать мир, общаться с интересными NPC, получать крутое снаряжение — всё это развлекает по-разному. Если в игре множество разнообразных и постоянно меняющихся активностей, вероятность того, что игрок заскучает, заметно снижается.
• Что касается сражений, то один из простейших способов разнообразить их — добавить к рядовым противникам требующих особой тактики «боссов». Людям нравятся «боссы», но нельзя сделать игру из одних лишь «боссов». Когда все супер — никто не супер. Игровой процесс должен напоминать американские горки, а не монорельс.
• По мере прохождения игры нужно добавлять новые занятия и механики. Например, в бою могут появляться новые комбинации навыков и способностей. Таким образом, уже привыкший к одному стилю боя игрок может внезапно получить новые возможности.
• Возможность выбора также улучшает вовлечённость. Следует дать игроку выбор: сразиться, пробраться скрытно или уговорить персонажа. Игрок понимает, что у него есть свобода выбора, игра реагирует на неё — и это само по себе увлекательно. Игрок должен принять решение, от которого зависит дальнейший игровой процесс.
• Ещё один способ увлечь игрока — добавить таинственности. Каких-нибудь слухов, обрывков информации, чтобы игрок захотел докопаться до истины. Можно добавить задания, в процессе выполнения которых игрок получает ответы на вопросы, но можно озадачить общими вопросами вроде «почему корпорация действует именно так, ведь это вроде как не в её интересах?» Иногда стоит оставить вопросы без ответов, что даёт задел для продолжения, в котором вы можете раскрыть карты.
• Вызов — отличный способ увлечь игрока. Можно заставить игрока подбирать комбинации характеристик, навыков и способностей для решения определённой задачи. При этом важно соблюсти баланс — и Тим признаёт, что у него с этим не очень. Он часто обращается за помощью к другим, но и у них не всегда получается, поскольку в играх Тима у игрока слишком много возможностей. Невероятно сложно сбалансировать игру под огромное количество вариантов развития персонажа.
• Кейн предлагает следующую модель балансировки: задания основного сюжета должны быть сбалансированы под самый плохой вариант развития персонажа. Разумеется, неоптимальное развитие персонажа может привести к дополнительным сложностям, но игра всё равно должна проходиться. А вот на побочках можно отыграться: запихнуть в них что-то действительно сложное, но и награды предложить пожирнее (в конце концов, в случае с заданиями основного сюжета, продвижение по нему — уже награда).
• Если у игрока что-то не получается, у него возникают проблемы, важно дать понять, что это — последствия его решений. Игроки склонны перекладывать вину на внешние факторы, обвинять кого угодно, кроме себя. В качестве примера Тим вновь вспоминает случай, когда тестировщик три раза подряд промахнулся с шансом попасть 95 %, и по его мнению вина была в «кривом» генераторе случайных чисел. А в D&D некоторые люди любят сваливать всё на «рак кубов» и тому подобное.

Что значит быть известным разработчиком

• По словам Тима его «знаменитость» зависит от того, кого спрашивать. Раньше журналисты нередко приходили брать интервью о различных проектах, и на их вопросы отвечал он, но некоторые в команде завидовали, и тоже хотели свою «минуту славы».
• Тем не менее, в жизни и даже на конференциях разработчиков его почти никогда не узнают, пока не представят. Посетители и участники конференций не в курсе, кто он и чем «знаменит». «Я не чувствую себя знаменитостью и не веду себя как знаменитость».
• Тима это ничуть не расстраивает, чего не скажешь о том, что немало разработчиков работает в жанрах, в которых не разбираются, то есть они не только не создавали в них игры, но даже не играли в них. «Мне всё равно, что они не знают меня, но они должны хотя бы понимать разницу между характеристиками, навыками, способностями и чертами, понимать, как они работают, и как это используется в разных играх, ведь всё это придумали не в Fallout — и до, и после было много игр».
• Но бывает и обратное, когда Кейна чрезмерно обожествляют. «Сложно проводить мозговой штурм с людьми, которые любую твою идею считают гениальной». От таких людей нельзя получить объективную обратную связь, поскольку они во всём поддакивают.
• Третья категория людей знает, кто такой Кейн, и изо всех сил старается принизить его, дав понять, что его опыт и методы устарели. «Когда у людей не остаётся аргументов, они начинают апеллировать к возрасту».
• Четвёртая группа — те, кто готов слушать. Как правило, это разработчики похожих проектов, стремящиеся избежать ошибок или добавить какие-то новые функции, и они хотят узнать мнение Тима, обсудить достоинства и недостатки своих идей и подходов, сравнить разные варианты их реализации до того, как всё будет сделано. Нередко молодые разработчики предлагают свои решения, которые не приходили в голову Кейну, так что эта польза обоюдна.

Опыт и уровни развития

• В среде разработчиков давно говорят об отказе от уровней, но Тим убеждён, что в ролевой игре нужно некое мерило развития и прогресса, и уровни отлично для этого подходят.
• Что касается получения опыта, то Тим пробовал разные варианты: давать опыт за убийство врагов, использование навыков, выполнение заданий и даже за урон противнику в Arcanum (причём количество опыта зависело от нанесённого урона). По мнению Тима, опыт лучше всего начислять исключительно за выполнение заданий. Он любит, когда задания можно выполнить множеством способов, и не желает навязывать конкретные варианты. Если игроку нужен предмет со склада, он может прокрасться внутрь, убить/подкупить охрану, украсть ключ, взорвать дверь динамитом — главное, что задача выполнена. Кейн горячо продвигал эту идею в Pillars of Eternity, и Джош Сойер его поддержал.
• Игрокам важно чувствовать прогресс, и заполняющаяся шкала опыта до следующего уровня в этом отлично помогает.
• По мнению Кейна, провал в использовании навыка тоже может давать опыт, и даже больше, чем успешное применение. На эту мысль его натолкнула жизнь: по мнению Тима, ошибки научили его большему, нежели победы. В создании The Temple of Elemental Evil было много неудачных моментов, и потому в разработке этой игры Тим понял больше, чем за все годы работы над Fallout. Кроме того, такой подход выравнивает кривую развития.
• Отлично, если при повышении уровня игроку предлагается огромное разнообразие навыков, но взять все у него не получится. На случай, если на определённом уровне игрок не найдёт ничего достойного, у него должна быть возможность оставить очки развития на потом. Также Тим всячески приветствует возможность распределить очки в любой момент, в том числе и перед появившимся препятствием: например, вложить очки в обезвреживание ловушек, стоя прямо перед ней.