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

Оптимизация

• Зачастую оптимизация — это поиск компромисса между скоростью и компактностью кода. Скорость определяется количеством затраченного на выполнение задачи процессорного времени, а компактность — количеством занимаемой памяти. «Быстрый» код нередко занимает больше памяти, а компактный — исполняется медленнее, однако в редких случаях удаётся и «ускорить» код, и сделать его компактнее.
• Кейну часто приходится объяснять не особо разбирающемуся в программировании начальству, что не стоит начинать оптимизировать проект сразу после его начала — необходимо выждать время и посмотреть, на что уйдут основные ресурсы компьютера. Тим снова припомнил первую демоверсию 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 тысяч слов — это одно, когда слов полмиллиона или миллион — это другое. При этом большое значение имеет какой это язык. Тут и сложность перевода, и необходимость добавлять новые шрифты, и, возможно, менять текст в зависимости от рода, а ещё в некоторых языках учитывается социальный статус собеседников, и тогда локализаторы начнут задавать вопросы, кто и с кем говорит, и всё это потребует глубокой доработки игры. Или, скажем, вы немного ошиблись с оценкой времени разработки определённой механики. В случае небольшого проекта цена такой ошибки измеряется десятками тысяч долларов, что может показаться немалой суммой, если не учитывать, что в действительно масштабных проектах такая ошибка может стоить миллионы. А ещё команды могут состоять из нескольких сотен человек в самых разных часовых поясах, что накладывает дополнительные ограничения.

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

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

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

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

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

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

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

Как баги становятся фичами

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

Лучшее — враг хорошего

• Это распространённая парадигма в игровой индустрии. Чаще всего эту фразу говорят, подразумевая, что время, потраченное на доведение до совершенства одного аспекта игры, можно потратить, чтобы сделать другой хорошим. Другой пример: не стоит тратить много времени на доработку одного аспекта до уровня, до которого не сможете довести остальные. Иногда так оправдывают вырезание механик и наполнения, которые не удалось довести до ума (последнее Тим всячески поддерживает).
• «Если собираетесь что-то вырезать, лучше сделать это как можно скорее». Некоторые продюсеры и прочие руководители думают, что вырезать что-то из игры можно по щелчку пальцев, достаточно просто решить и вычеркнуть из дальнейшей разработки. Однако механики большинства ролевых игр представляют нити в общем полотне игры, нельзя просто сделать вид, что их никогда не было. Пример: вы разрабатываете RPG и в какой-то момент решаете убрать ремесленную систему. Но нельзя просто так взять и сделать это: придётся убирать и соответствующие компоненты, править таблицы трофеев, избавляться от создаваемых в процессе предметов, рецептов, чертежей и так далее. Казалось бы, можно превратить это всё в продаваемый за копейки мусор, однако некоторые вещи всё же придётся убрать (те же рецепты), а огромное количество продаваемого мусора может сломать экономику игры. Кроме того, если игрок мог создавать какое-то уникальное снаряжение, он потеряет и его, или же его придётся как-то перенести в игру. При этом нельзя просто взять «топовый крафт» и закинуть в инвентарь торговцев по безумным ценам, ведь тогда игрок может быстро на него накопить, что сломает игру.
• Во время разработки The Outer Worlds из игры убрали множество механик, которые не смогли довести до нужного уровня качества. Некоторые из оставшихся механик заметно упрощены по сравнению с изначально предполагавшимися версиями. Что касается наполнения, то планету Монарх урезали в четыре раза. Это должна была быть огромная планета-песочница с джунглями и беззаконием, где игрок провёл бы на 5–10 часов больше, чем получилось в итоге — когда джунгли исчезли, и осталось лишь беззаконие. А вместе с этим исчезла и немалая часть исследовательского духа игры.
• Также эту фразу используют как предупреждение желающим с самого начала проекта заняться его оптимизацией. Многие программисты любят «вылизывать» код до совершенства, оптимизируя его «на месте»: «я только что написал этот код, я помню его, я знаю, как это работает, поэтому лучше не откладывать». Но, как говорил Кейн в видео про оптимизацию, ускорение редко вызываемого участка кода, равно как и попытки выжать всё из и без того быстрого кода — пустая трата времени.
• Кейн рассказал, как потратил много времени и сил, стараясь не допустить присущего многим изометрическим играм «скольжения» при перещении персонажа. Для него было принципиально сделать так, чтобы перемещение персонажей было правдоподобным. Однако у него не хватило времени исправить зигзагообразное передвижение по шестиугольной сетке вверх и вниз. Он хотел, чтобы персонажи ходили по прямой до точки назначения, но на практике воплотил своё желание лишь в The Temple of Elemental Evil. Почему времени не хватило? Потому что Кейн долго «вылизывал» перемещение спрайта персонажа по поверхности, а результат почти никто не заметил. «В той же Diablo эта проблема присутствовала — и всем было наплевать». Совет разработчикам: тратя время на доведение до совершенства чего-то одного, вы отказываетесь от многого другого. Лучше, чтобы всё было примерно хорошо, чем довести пару аспектов до идеала, а остальное бросить как есть, потому что не хватило времени. Лучшее — враг хорошего.

Шаблоны повествования

• Кейн ненавидит, когда история начинается с амнезии. «Амнезия — это ленивый, халтурный способ начать ролевую игру». Этот приём применяется, чтобы уравнять персонажа с не знакомым с миром игры игроком. Но есть варианты получше. Например, в Fallout персонаж покидал Убежище, не зная, что его ждёт снаружи. А в Arcanum он прилетал на континент на дирижабле, и не знал, что там происходит. «Мне нравится Planescape: Torment, поэтому скажу то же, что сказал тогда Крису Авеллону: амнезию можно использовать лишь раз. Если вы сделаете это снова, я назову вас ленивым халтурщиком». Изначально планировалось, что сюжет Fallout 2 начнётся с того, что на вашего персонажа напали бандиты, ограбили и избили до потери памяти — так разработчики собирались обосновать сброс уровня до первого, потерю всех навыков, способностей и предметов. Кейну не понравилась эта идея, «почти никому она не понравилась» — и отчасти поэтому разработку Fallout 2 вернули ему.
• Во многих RPG перед игроком ставят задачу одолеть злодея и спасти мир. Это нормальный подход, но Тим старается отступать от него. Так, выйдя из Убежища в Fallout, вы тут же обнаруживаете труп в комбинезоне Убежища, и понимаете, что вы такой не первый, а если персонаж ещё и идиот — наверняка не последний. В Arcanum вступление носит нотки стёба: к вам подбегает Вергилий и с ходу заявляет, что вы Избранный, при этом тупой персонаж может потом сказать другим персонажам, что Вергилий назвал его импотентом [прим. пер.: игра слов, important — impotent].
• Многие считают затасканной так называемую «серую мораль», но Тим отмечает, что это не всегда было так, и 25 лет назад это было в новинку. «Я не хочу бросаться громкими словами, что „мы делали это до того, как это стало мейнстримом“, но мы действительно создали игру с „серой моралью“ во времена, когда другие заставляли игроков геройствовать».
• Другой приём, который иногда записывают в шаблоны, это возможность заболтать босса, которая есть во многих играх Кейна. Так, в Fallout было три основных способа прохождения основного сюжета (Сила, слово, скрытность / Убей, уговори, укради), поэтому основных целей игры можно добиться в том числе дипломатией. Для последнего, впрочем, требовалось соблюсти ряд условий — нельзя было просто уговорить Повелителя убиться о стену, нужно добыть диск с необходимой информацией, и лишь тогда, при высоком навыке красноречия, всё получится. Нельзя просто подойти к кому-то и сказать: у меня крутое красноречие, убейся — это глупо.
• Следующий троп — монстр-герой. В Fallout вы можете встретить гуля Гарольда. Гули предполагались монстрами и злодеями, и хотя обитающие в Некрополе уже выбиваются из этой идеи, Гарольд был своего рода героем, ведь он хотел как лучше, он пытался помогать окружающим. А в Arcanum был «самый умный орк в мире» Гар, но на самом деле он человек — правда, до этого ещё надо докопаться. Применяя этот шаблон, Кейн разрушал другой — что орки, гули, супермутанты и так далее всегда плохие. «Стремясь к „серой морали“ мы хотели, чтобы некоторые стереотипные злодеи оказывались героями, равно как некоторые эльфы — злодеями».
• Кейну не нравятся романы в RPG. Этот аспект Кейн подробно обсуждал с Леонардом Боярским при разработке The Outer Worlds. Они оба считают, что в большинстве игр романы реализованы плохо, а чтобы сделать их хорошо нужно немало времени и сил, в том числе на проработку квестов и создание игровых областей. Добавлять романы в игру следует лишь с уверенностью, что сможете сделать их хорошо. Кроме того, реализация романов связана с чередой решений, которые неизбежно оттолкнут часть аудитории. Например, если вы решите, что романы должны быть доступны только разнополым персонажам, это расстроит одних, а если добавите однополые романы — огорчатся другие. Зачастую игрокам не нравится, что им «запрещают» заводить отношения с персонажем потому, что их персонаж «не того пола» — и разработчики делают всех персонажей бисексуальными, и всё это превращается «в хреновый симулятор свиданий». Учитывая вышесказанное, от романтических отношений с игроком в The Outer Worlds отказались, хотя можно поучаствовать в чужих.

Сожаления о Fallout

• Как уже говорилось в прошлых видео, спутников добавили настолько поздно, что времени прорабатывать их ИИ не осталось. Поначалу они были жёстко заскриптованы и просто следовали за игроком, нападая на его врагов. У Кейна не было времени писать отдельные скрипты для спутников, поэтому использовались написанные для вражеского ИИ. Проблема в том, что эти скрипты писались не для использования спутниками. Некоторые моменты в исполнении врагов были весьма забавны, но не когда то же самое делал союзник. Самый наглядный пример — оружие с высоким разбросом пуль вроде узи. Забавно, когда враг очередью выкосил всех союзников, но не попал в тебя. Разумеется, когда то же самое делает твой напарник, это не не так забавно, особенно с учётом критических попаданий и провалов.
• Опять же, об этом уже говорилось, но Кейн жалеет, что так и не нашёл времени добавить функцию, позволяющую «подвинуть» загораживающего проход спутника. Это было одной из первых функций, написанных для Fallout 2.
• Было бы неплохо добавить в игру механику повышение уровней спутников, чтобы они оставались полезными всю игру, а также возможность попросить спутника подождать персонажа игрока в указанном месте. На всё это не хватило времени. Многие задумки относительно спутников нашли воплощение в Arcanum.
• Что касается Fallout 2, то из неё вырезали область под названием «Аббатство утраченных знаний». Кейн очень хотел, чтобы она появилась в игре как дань уважения повлиявшему на создание оригинальной Fallout роману «Гимн Лейбовицу» Уолтера М. Миллера-младшего. Кроме того, посредством Аббатства Тим хотел показать иной подход к сохранению знаний и технологий старого мира, нежели у Братства стали. С ними были связаны квесты по поиску чертежей и технических руководств по созданию различных предметов. В отличие от Батства стали, монахов интересовали не столько сами технологии, сколько знания о них. Разумеется, в какой-то момент монахам пришлось бы столкнуться с Братством стали, которое несомненно сокрушило учёных-пацифистов с идеей общедоступных знаний, на разрешить этот конфликт предполагалось игроку.

Гедонистическая адаптация

• У каждого человека есть собственная мера и точка отсчёта счастья. У кого-то она ниже, у кого-то выше, но независимо от происходящего вокруг, положительного или отрицательного, человек всегда со временем возвращается к своей норме. Гедонистическая адаптация сильно влияет на разработку игр.
• Можно сделать сколь угодно крутую игру, и игроки будут носить тебя на руках, но со временем этот уровень станет для них нормой, и они начнут воспринимать его как нечто обыденное. И если игра с определёнными чертами «выстрелила», то все начинают копировать её, и все они становятся похожи друг на друга. Именно поэтому Кейну нравится создавать новые игры с новыми мирами и механиками.
• В отличие от The Outer Worlds, Тим не руководил разработкой продолжения, а лишь консультировал его создателей, даже не числясь в штате Obsidian Entertainment. Ещё в начале разработки оригинальной игры Тим уже знал, что откажется от участия в создании продолжения.
• Отчасти Тим отошёл от дел, поскольку устал от используемых повсюду, «затасканных» игровых механик, равно как и доказывать вышестоящему начальству и инвесторам, что его идеи имеют право на жизнь.
• Сейчас у Кейна гораздо больше времени на игры, при прохождении которых он постоянно ловит себя на мысли, что он всё это видел и не раз. Механики, квесты, NPC кочуют из одной ролевой игры в другую, и это вызывает усталость. Лучший комплимент современным играм: «о, я всё это уже видел, но не в таком сочетании» или «о, они вернули механики 20-летней давности с небольшими доработками».
• Кейну нравится Tyranny как «фэнтезийный мир, в котором Саурон победил».
• «Я постоянно жду от игр чего-то нового, но боюсь, что гедонистическая адаптация притупляет моё восприятие игр». Немалый вклад в это вносит и то, что Кейн руководил разработкой нескольких проектов, и в его обязанности входило критически смотреть на каждый элемент игры.