Тим Кейн о себе, игровой разработке, 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, где публикует видеоролики с воспоминаниями, откровениями о разработке и советами делающими первые шаги в игровой отрасли. Мы взялись отсмотреть все видео, чтобы вам не пришлось. Продолжение следует.