[Перевод] Как Crash Bandicoot взламывал Playstation
Энди Гэвин из Naughty Dog рассказывает об управлении памятью и 3D-анимациях 90-х.
«Памяти в Crash Bandicoot настолько не хватало, что мне приходилось красть небольшие кусочки лишней памяти из библиотек Sony. Я просто пробовал удалять те части, которые, как мне казалось, я не использую, и проверял, продолжает ли всё работать. Если всё работало, то я помечал их как свободные и делал хаки их кода, меняя байт-коды. Я думал: у меня получится, если Sony не хочет исправить это сама, то я просто изменю их код. Это была свободная память. [смеётся] Память была ограниченной. Но нам совершенно точно никто не разрешал этого делать».
Привет, я Энди Гэвин, сооснователь Naughty Dog Inc и ведущий программист Crash Bandicoot. Мы решили создать первый экшн-платформер с трёхмерным персонажем, и чтобы сделать всё правильно, нам в буквальном смысле пришлось взламывать оборудование.
Это было частью философии Naughty Dog — делать всё возможное, использовать каждый цикл ЦП или GPU, каждый байт памяти. Если в машине существовала такая возможность, то мы пытались разобраться, как выжать из неё максимум вне зависимости от того, пригодится ли это нам или нет, и будем ли мы использовать какие-то безумные трюки. Летом 1994 года мы с моим партнёром Джейсоном Рубином завершали файтинг для 3DO под названием Way of the Warrior и размышляли над тем, какую игру хотим сделать следующей. Самым популярным жанром на консолях в то время были экшн-платформеры, такие как Super Mario World и всевозможная другая классика 16-битных платформенных игр. В то же время на аркадных автоматах появилось новое 3D-оборудование и некоторые жанры начали переход из традиционного 2D в 3D.
Такие игры, как Street Fighter II и Mortal Kombat, по-прежнему были на пике популярности, но уже появился и Virtua Fighter. В нём использовалась 3D-графика, это было круто и стало очевидно, что игры будут двигаться этим путём. Новые консоли будут работать в 3D. Можно ли создать 3D-платформер? Никто этого ещё не делал, но это должно было произойти. Подумайте о том, как Соник летает по петлям из труб в 3D. Как это будет выглядеть? До осени 1994 года Naughty Dog состояла только из нас, Джейсона и Энди, образующих настоящую синергию. Мы оба занимались всеми творческими аспектами, мы были лучшими друзьями, соседями по комнате, Джейсон был феноменальным художником, а я — программистом игр, и мне кажется, довольно неплохим. [смеётся] Из нас двоих он пытался сделать так, чтобы игра выглядела потрясающе, а я пытался, чтобы технология заработала, и оба мы стремились сделать игру по-настоящему увлекательной. Мы с Джейсоном продали права на издание Way of the Warrior новому отделению Universal Studios под названием Universal Interactive. По сути, они нам сказали: приезжайте в Калифорнию, останавливайтесь на площадке Universal рядом со Стивеном Спилбергом, мы бесплатно дадим вам бунгало и всё необходимое. Вы сможете делать всё, что хотите, вам только нужно показывать это нам. Мы забрали собаку, пса по имени Naughty Dog Morgan, сели в мою Honda Accord и поехали через страну, поэтому у нас было много времени на разговоры. Мы обсуждали: как же будет выглядеть платформер в 3D?
Мы обсуждали нечто наподобие игр Sonic the Hedgehog. Представьте, что вы перемещаетесь по петлям, бегаете и прыгаете по платформам и собираете предметы в 3D. Камера всегда находится за игроком. Вы видите мир, и всё выглядит замечательно, но это как будто игра про задницу Соника. Всё, что вы делаете — смотрите на задницу Соника. Но наиболее выразителен персонаж, когда мы видим его спереди. Можно ли сделать уровни, где игрок движется на камеру? Но как же видеть, куда он бежит? По сути, такие размышления постепенно привели нас к уровням с булыжником из Crash Bandicoot. Должны ли быть уровни, где игрок движется вбок, должен ли он оглядываться через плечо на экран? Мы одновременно проектировали игру, которая станет Crash Bandicoot, и параллельно как бы выбирали для неё платформу.
Мы знали, что поскольку это будет 3D-игра, нам понадобится одна из новых 32-битных платформ. Итак, была 3DO, для которй мы уже сделали одну игру, но эта машина была как бы кривой, наполовину 3D-машиной. К тому же она была очень дорогой и не очень хорошо продавалась. Ещё была Atari Jaguar. Мы считали её недоразумением. А ещё были серьёзные ребята, собирающиеся выпускать новые машины. Мы знали о какой-то загадочной машине от Nintendo, но никак не могли узнать, что Nintendo готовит. Они вообще не общались с американцами. У Sega было два проекта. У неё была 32X, выпуск которой начинался той осенью; она должна была усилить возможности Genesis. Кроме того, она создавала новую машину; я не помню, называлась ли она уже тогда Saturn, но в результате она превратилась в Saturn. И ещё была тёмная лошадка Sony. Эта компания раньше никогда не делала видеоигр. Мы слышали, что у неё есть мощная новая машина, поэтому мы связались с Sega и Sony и изучили информацию, которую они нам дали. Чтобы заключить с ними договор, нужно было заложить свою душу и первенца, после чего можно заказать машины, если дать им залог и всякое такое. А у Sony была новая машина, как бы в полном 3D. Она неплохо справлялась и с 2D, и это была новая чёткая архитектура, очень похожая на коммерческое 3D-оборудование класса high end наподобие Silicon Graphics, но со множеством упрощений, позволявших сделать консоль более экономной; у PlayStation 1 было два основных специализированных чипа — графический модуль и специально изготовленный ЦП с MIPS-архитектурой. Но современные GPU намного сложнее и они выполняют кучу вычислений, на которые не были способны старые GPU 90-х. GPU консоли PlayStation 1 просто отрисовывал треугольники на экране, но довольно неплохо с этим справлялся. Он мог отрисовать примерно 120 000 треугольников в секунду, что по тем временам было феноменальным. На PC того времени не было оборудования для 3D-графики. На них были VGA-платы. Вам бы повезло, если бы удалось получить пару сотен полигонов, потому что все вычисления выполнялись программно. И была PlayStation, которая стоила 199 или 299 долларов.
— 299.
— И это была готовая машина с CD-приводом, памятью и всем необходимым. Разница между консолями и PC в то время была огромна. Мы говорим о временах Windows 3.1 и DOS. Для запуска игры обычно нужно было иметь загрузочный диск со специальным autoexec.bat и config.sys, которые нужно было открывать в машине. Мир PC тогда был не очень дружелюбен к играм. А на PlayStation или Genesis или Super Nintendo достаточно было просто вставить картридж или CD — и бум, всё загружалось. Больше всего мне нравилась Sony. Она была классная, чёткая, мощная и задумывалась для 3D. Я действительно думал, что это единственная из машин, которая бы смогла выдержать задуманное нами.
Базовая идея Crash Bandicoot как игры заключалась в том, что она должна иметь механику, как в игре наподобие Donkey Kong Country. Игрок должен был проходить уровни с обратным отсчётом, врагами и прыжками. Она должна быть платформенной с мультяшным персонажем-животным, и мы не хотели, чтобы она выглядела очень похожей на видеоигру. Мы хотели, чтобы она походила на мультик Looney Tunes, где персонаж хорошо анимирован и плавно движется. Если его раздавил огромный катящийся камень, то он превращался в катающийся плоский блин. Мы хотели создать мир, похожий на мультипликационный, с эмоциональностью классических анимационных лент, которая была в то время заново открыта такими телесериалами, как «Утиные истории» и «Симпсоны». Анимация снова стала крутой. И в кадре находился Крэш, у нас было 30 кадров в секунду и около 1 500 полигонов на экране. 600 из них занимал Крэш. Вот настолько он для наc был важен. В большинстве игр использовалось около 80 полигонов и персонажи выглядели как странные ходящие блоки. Мы хотели, чтобы он выглядел, как настоящий персонаж мультфильма. Для этого требовалось много деталей, поэтому он отнял треть нашего бюджета полигонов.
Создавая Crash, мы постоянно изобретали что-то новое. Никто ещё не делал 3D-игру в жанре экшн-платформера. В то же время было совершенно очевидно, что PC, которые обычно использовались для разработки игр, этого не потянут. Повторюсь, тогда было время Windows 3.1, отсутствия 3D-графики и по сути доступных всего 640 КБ ОЗУ. Мы рискнули купить для всех компании, а тогда нас было пять человек, рабочие станции Silicon Graphics, в основном это были Indigo2 Extremes. Рабочие станции по цене от 75 до 100 тысяч долларов. В них была 3D-графика. Программное обеспечение для создания 3D-графики тоже стоило порядка 75 тысяч на машину. Совсем незадолго до этого на подобном ПО были созданы такие фильмы, как «Терминатор 2», «Бездна» и «Парк Юрского периода». Поэтому мы решили выбрать в качестве ПО Alias PowerAnimator, который на то время был одним из трёх возможных вариантов [смеётся].
Итак, мы получили неуклюжую большую коробку — ранний прототип PlayStation, и он оказался довольно неплохой машиной. Но для начала вам нужно кое-что понять. Он поставлялся с кучей руководств, оказавшихся невероятно плохо переведёнными с японского загадочными текстами. У нас возникали удивительные обсуждения того, что они подразумевали под тем или иным забавным набором английских слов. Чтобы по-настоящему разобраться, нам приходилось тестировать всё эмпирически. Мы брали отдельные части и писали тестовый код, чтобы выполнить с машиной определённое действие и посмотреть, как она справляется. Это похоже на то, как ты ездишь на машине по автодрому и проверяешь, насколько быстро она может поворачивать. У консоли было множество различных графических режимов, например, работа с половинной скоростью в режиме высокого разрешения; однако режим среднего разрешения очевидно был придуман в последний момент, потому что работал с такой же скоростью, что и режим низкого разрешения. Джейсон к тому времени уже создал персонажа Крэша Бандикута, который выглядел почти так же, как в игре, поэтому я вывел его на дисплей и мы уменьшили его до размеров, которые помещались бы на экран. Я написал код, чтобы вычислить количество пикселей, занимаемых каждым полигоном, и выяснилось, что в среднем это 1,2 пикселя. Поэтому я предложил: зачем нам вообще текстурировать эти полигоны? Мы решили, что для персонажей не будем использовать режим текстурирования. Воспользуемся более быстрым и простым при затенении режимом, который большинство разработчиков не использует. Большинство просто использовало текстуры. И частично это было вызвано тем, что мы провели тесты и обнаружили, что в нетекстурированном режиме игра работает в два раза быстрее. Если разработчики не проводили тестов и верили числам из инструкций, то получали одно число. А мы выяснили, что PlayStation на самом деле может отрисовывать довольно приличное количество полигонов в секунду на графическом оборудовании, но нужно выполнять вычисления, чтобы знать, где должны находиться эти полигоны.
Сегодня почти в каждом компьютере и даже телефоне есть мощные GPU с вершинными блоками, и они могут выполнять огромный объём вычислений, часто гигафлопы операций суммирования умножений. А в то время большинство компьютеров могло выполнять умножение и сложение в ЦП по одному за раз, поэтому успевали выполнять сотни или тысячи, но не миллиарды вычислений. Это было серьёзной преградой.
Фундаментальная проблема PlayStation заключалась в том, что взаимодействие железа и ПО с математической точки зрения не было идеальным. Мы вроде бы понимали, что проблема программная, что Sony просто хотела использовать написанные ею библиотеки, но она не эксплуатировала машину по максимуму. Где-то внутри проектировщики добавили оборудование, предназначенное для выполнения суммирования умножений, потому что таких операций нужны миллионы, но всё это было скрыто под слоем библиотек языка C, написанных Sony: ты передавал им числа, они выполняли суммирование умножений, но производительность была ужасной. Хотя графический блок мог отрисовывать 100–120 тысяч полигонов в секунду, библиотеки успевали преобразовывать математику, быть может, для 5–10 тысяч, чего явно не хватало. То есть если тестировать базовую производительность математики вершин на PlayStation 1, пользуясь официальными инструкциями Sony и вызывая графические библиотеки, то можно было потерять целый порядок величин, задействовать железо на десятую часть. Код просто недостаточно быстро работал.
Мы сделали примерно так же, как сделал бы любой хороший учёный — разобрали систему на части и поняли, что внутри есть достаточно мощи, но консоль скрывает её от нас. В случае с этой конкретной проблемой я через своих знакомых в Sony предложил творческое решение — мы обменялись двумя листами бумаги, передав при личной встрече. «Я тебе ничего не говорил». [смеётся] Но на самом деле этого оказалось достаточно. Мы просто систематично проработали всё это, и выяснилось, что внутри специально разработанного ЦП Sony есть математический «мозг», называемый сопроцесором, способный выполнять очень узкоспециализированные и ограниченные вычисления, необходимые для преобразования вершин. И он успевает их выполнять с такой скоростью, что GPU способен потреблять эти данные. Почти в любом специализированном игровом оборудовании со времён аркадных автоматов всегда было два основных «мозга»: графический модуль и ЦП. Старые добрые ЦП обрабатывали отдельные числа и это позволяло им делать всё то, на что способны компьютеры, но одновременно они могли «думать» только одну мысль. Графический модуль обеспечивал способ аппаратного рендеринга графики. В ранних играх 80-х, даже в таких простых, как Galaga, где нужно было просто расстреливать корабли инопланетян, эта графика называлась спрайтами. В то время ЦП не могли отрисовывать спрайты. Были придуманы небольшие графические модули, способные создавать спрайты и выполнять скроллинг фона. По сути, все технологии компьютерной графики развивались благодаря видеоиграм. Но нужно было всегда сохранять в этих машинах баланс между графическим мозгом и мозгом, занимающимся общей математикой. Сегодня графические процессоры могут иногда выполнять тысячи таких же операций, и поэтому вычислительная мощь GPU гораздо больше, чем у CPU. У них много гигафлопсов, иногда даже терафлопсов. Они не выполняют общие вычисления.
Позвольте мне объяснить вам игровой процесс в 2D-платформере. Возьмём Donkey Kong Country. Игрок может перемещаться вперёд и назад по уровню, то есть влево и вправо, прыгать вверх и вниз по платформам, но по сути игра линейна. Обычно ты движешься вправо и сталкиваешься с препятствиями. Всё это сводится к принципу, появившемуся в Pitfall в 1980 году. Вы можете раскачиваться на лиане, чтобы перепрыгнуть шипы. По платформам могут бродить монстры, а над ними летают пчёлы. Игра развивается линейно. Вы видите, куда движетесь, и в игре очень высокий темп. Прыжок-прыжок-удар, прыжок-прыжок-удар. Поэтому это хорошо сочетается с 2D. Дизайнер отмеряет практически музыкальный ритм игры, и благодаря этому такие игры очень увлекательны и аддиктивны. Вы всё лучше разбираетесь в игре, сначала изучаете основы управления, становитесь Донки Конгом, потом изучаете движения врагов и объектов на уровне, запоминаете маршрут. Это похоже на воспроизведение музыки в ритм-игре. Но в 3D всё иначе. Мы добавили новое измерение. Теперь можно двигаться из стороны в сторону. Если в Donkey Kong Country или Mario на вас идут три черепахи, то вам нужно перепрыгнуть их или прыгнуть им на голову, чтобы одну за другой вырубить всех трёх. В 3D можно просто переместиться вправо и спокойно обойти их. Мы добавили целое новое измерение пространства, и пространства стало слишком много. Это как бы изменило баланс между выбором и конфликтом. Нам пришлось придумывать, как компенсировать это, чтобы сохранить активное течение игры. Мы осознали, что добавили новое измерение, поэтому проще всего будет отнять его, но отнимать разные измерения. Допустим, такое было на уровнях с булыжником. Измерением, которое мы отняли там на самом деле, было время.
Это не одно из трёх пространственных измерений. Из-за опасности уровня (камень расплющит тебя, если ты не будет постоянно двигаться, двигаться, двигаться), у тебя нет роскоши выбора других измерений, поэтому это заставляет тебя двигаться по узкому коридору так быстро, что игровой процесс ощущается напряжённым. А уровень с кабаном движется противоположно — вместо движущегося на вас предмета вы скачете в сторону объектов. Как будто вы сидите на кабане и не можете управлять его скоростью. Это дикий боров и вам в основном нужно перемещаться влево и вправо, после чего начинается более обычный 3D-уровень. Например, в Insanity Beach мы разместили стены из джунглей, чтобы сузить пространство, не полностью, но частично. Существуют и другие элементы, позволяющие его сузить, например, враги, допустим, крабы или скунсы на этих уровнях, они обходят игрока сбоку. Это не значит, что мы не можем при желании использовать новое измерение, потому что у нас есть ящик слева и ящик справа. Можно делать интересные вещи, например, игрок должен выбирать, встретиться ли угрозой и двинуться к ящику. А если игрок на уровне наподобие Hog Wild, то мы делали это намеренно. Допустим слева мы располагали столб с шипами и ящик, а справа — путь без препятствий. Поэтому чтобы легче пережить это препятствие, можно переместиться вправо и просто проехать мимо столба. Но тогда тебе не достанется ящик. Чтобы получить его, нужно в последнюю секунду переместиться к столбу, а потом скользнуть вбок. То есть игра даёт игроку выбор или элементы расчёта времени, как на некоторых уровнях 3D-типа с катящимся булыжником, за которыми идут уровни с платформами. Игроку нужно прыгнуть, но затем можно увеличить напряжение, заставив платформу обрушиться. Платформа как бы имеет свой срок действия. Игрок забирается на неё, а она движется и падает. А ещё у нас были уровни другого формата, где мы снова отнимали одно измерение. Например, в игре есть много уровней, которые представляют собой например стену, то есть они как бы происходят в 2D. Да, можно двигаться в сторону, но мы уже сделали что-то вроде 2D-уровня, фиксировав камеру так, чтобы она смотрела сбоку. И ещё был один тип уровней, в котором камера поднималась и Крэш двигался как бы по сетке, но движения вверх и вниз почти не было, и вместо открытого пространства игрок находился на мостиках, под которыми есть какая-то смертельная опасность.
В каждом из подобных случаев нам нравилось добавлять ограничения или понижать степени свободы, чтобы сузить пространство и усилить напряжённость игрового процесса. Из-за дополнительного измерения игра более разнообразна, чем была традиционная игра в 2D, потому что на разных уровнях мы отнимаем различные измерения. У нас было примерно 7–10 разных стратегий для ограничения измерений. Ящики на самом деле тоже были придуманы для того, чтобы заполнять пустоту. На экране не так много врагов, потому что машина бы не справилась с большим количеством, но мы активно заполняли пустые пространства ящиками. К тому же они могут разваливаться целыми штабелями и создавать головоломки; для такого простого объекта всего из нескольких полигонов он был невероятно универсальным.
Мы точно были уверены, что хотим создать тот тип анимации, который никогда не использовался в видеоиграх. Он должен был напоминать стиль Looney Tunes, такую деформированную анимацию. Это очень эластичный, резиновый стиль анимации, реализуемый в традиционной мультипликации. Поэтому персонажей на самом деле нужно было анимировать. В эпоху низкополигональной графики 90-х персонажи традиционно создавались из небольшого количества костей: плечевая кость, кость предплечья, кость головы; вся графика правого бедра персонажа прикреплялась к кости правого бедра. А кость — это жёсткий объект, наподобие шарнира. Её можно поворачивать или передвигать. Она чем-то напоминает имитацию робота, и если вам нужны пальцы, то придётся создавать много костей. Для PlayStation это слишком большой объём вычислений. Мы знали, что она никогда не справится с кучей костей. И совершенно точно невозможно было бы создать анимацию попадания молотком по руке, как это бывает в мультфильмах. Что мы там видим? Рука вздувается, как шарик, или расплющивается в блин, или что-то подобное. Мы не могли всё это сделать при помощи единой системы костей. В играх наподобие Virtua Fighter на аркадных автоматах использовалась классическая система костей. Для файтингов она вполне подходила, потому что там не так много деформаций, но персонажи выглядели немного скованными. При помощи костей практически невозможно или очень сложно создавать лицевую анимацию, а мы знали, что нам очень хочется её реализовать. Какой персонаж не любит усмехаться или подмигивать? Возможно ли вообще добиться подобной анимации на рабочей станции Silicon Graphics?
Джейсон создал эту модель Крэша и был готов к созданию крутых мультяшных анимаций; он выяснил, что действительно можно заставить PowerAnimator это сделать, потому что в нём были мощные инструменты наподобие костей и весов вершин, а также поля искажений. Но способ их реализации пакетом PowerAnimator было невозможно воспроизвести на PlayStation. Все эти вещи использовали дорогое оборудование для работы с плавающей запятой в рабочей станции Silicon Graphics, и даже она не могла выполнять их в реальном времени. Ей приходилось рендерить анимации, а видеоигра происходит в реальном времени. Нам было нужно успевать всё делать за 1/30 секунды. Это стало ещё одной серьёзной проблемой, ведь мы очень хотели реализовать эти анимации.
Я предложил: ну, мы ведь можем считывать позиции всех вершин. Если мы знаем, где находятся позиции всех вершин в каждом кадре, то тип костей нам не важен. Пусть SGI использует хоть тысячу костей, принцип будет тем же. Мы просто отрисовываем полигоны и позиции вершин, и это можно делать довольно быстро. Нам не придётся выполнять вычисления костей, поэтому ресурсы ЦП на кости тратиться не будут. Но при такой стратегии проблема заключалась в том, что если у нас есть анимация с 30 кадрами в секунду, а Крэш состоит примерно из 500 вершин и где-то 600 полигонов, то нам нужно хранить позицию в каждом кадре анимации для каждой вершины. Это большой объём данных. Но в то же время нас уже увлекла эта безумная стратегия для памяти с тридцатикратным увеличением объёма данных, так что мы могли обрабатывать чуть больше данных, чем удавалось другим. Поэтому мы решили запекать данные анимаций с использованием всех изощрённых эффектов Джейсона в PowerAnimator. Так я и сделал, и это сработало, потому что в комплекте разработки PlayStation было что-то вроде 8 или 32 мегабайт памяти. Поэтому можно было позволить гораздо больший объём, чем было бы доступно на реальной машине. Мы работали над этим несколько месяцев, и я постоянно думал, что нам каким-то образом придётся уместить всё в памяти. Объём был просто огромным. Его нужно сделать меньше. Но у меня было чувство, что в математическом смысле данных не так много, что можно было написать специализированный алгоритм сжатия. Как это понимать: в теории компьютерных наук данные имеют определённую степень сложности. У них есть паттерн и ограничения, и в нашем случае данные анимации вполне могут вытерпеть потерю своей части. По той же самой теории работает jpeg и именно благодаря ей он совершенно изменил Интернет и способ хранения изображений. В случае jpeg мы преобразуем изображение в диапазон частот, это сложное математическое преобразование, а потом отбрасываем высокочастотный мусор, обращаем его и в зависимости от количества выброшенного мусора изображение начинает выглядеть лучше или хуже, но в нём всё равно остаются наиболее важные части, занимающие в 20 или 30 раз меньше места, потому что мы избавились от маловажной информации. Я был сильно уверен в том, что с данными анимаций будет такая же ситуация, что мы сможем избавиться от высокочастотных анимаций, например, у вершин талии персонажа, они ведь не очень сильно движутся вверх и вниз.
Марк Церни написал программу для анализа. Он взял набор анимаций и проанализировал каждый компонент и каждую вершину, вычислил своего рода динамический диапазон и величину изменений, происходивших между анимациями. Он обнаружил, что информация и в самом деле меняется довольно незначительно. Поэтому оказалось, что мы сможем использовать очень специализированный алгоритм, который определяет диапазон и всё остальное, а также создаёт в начале карту, в которой, например, написано, что координата Y вершины номер семь содержит мало информации, поэтому ей достаточно всего двух битов. Что она перемещается в таком-то диапазоне и ей требуется столько-то бит. В конечном итоге мы получили соотношение сжатия где-то в пределах 50–81, то есть данные стали в 50 раз меньше.
Если посмотреть на конструкцию PlayStation 1, то несмотря на правильное проектирование и баланс, у машины было всего два мегабайта ОЗУ и один мегабайт VRAM. Но у неё был и CD-привод, на котором могло храниться до 640 мегабайт данных для чтения, а это намного больше. Это соотношение очень велико. То есть теоретически можно было сделать уровни гораздо больше, чем два мегабайта. Как в обычной игре, допустим в Twisted Metal, вы попадаете на уровень Eiffel Tower и игра загружает уровень Eiffel Tower в один мегабайт памяти. В них есть определённый объём графики и анимаций, занимающих примерно один мегабайт. Теперь можно придумывать разные способы сжатия данных, но нет никакого способа обойти это ограничение, а люди не особо и пытались. Вот так, в принципе, всё и работало. Компьютер, то есть ЦП и GPU, мог получать доступ только к тому, что в данный момент находится в памяти. Каждую 1/30 секунды в памяти есть то, что нужно для рендеринга кадра. Всё, что вы будете отрисовывать сейчас, любая анимация и любой звук, которые будут сейчас использоваться, должны быть в памяти, потому что получить доступ к памяти можно быстро. CD-приводу требуется порядка ⅓ секунды для перемещения головки в любую точку CD. Для загрузки данных требуется какое-то время. Он может загрузить мегабайт за шесть секунд, или около того. Поэтому нельзя просто отрисовать один кадр и начать скачивать новый мегабайт с диска, потому что для его получения потребуется ещё восемь секунд. И что вы будете делать — ждать целых восемь секунд? Это можно делать между уровнями. Поэтому при переходе между уровнями в обычной игре есть экран загрузки, когда она считывает целый мегабайт, или сколько ей там нужно, с диска. CD — это более «далёкий» накопитель. Он больше, но и медленнее. Его дольше использовать, но почему бы и не использовать его? Он ведь есть. В ранних играх для PlayStation разработчики создавали уровни по одному-два мегабайта, а на CD помещается 640 мегабайта, то есть на него можно записать 300 уровней. Было ли у них 300 уровней? Нет, иначе для создания игры понадобилось бы десять лет. Поэтому CD в основном пустовали, или их заполняли музыкой или видео, потому что это объёмные данные. Но очень часто диски просто были пустыми. Такие игры, как Twisted Metal, могли занимать на диске всего 50 мегабайт. Поэтому уровни очень многих игр выглядят, как будто занимают примерно мегабайт, ну, может мегабайт с половиной. Этого было достаточно. Так было создано множество игр для PlayStation, но по моей теории нам необязательно было этого придерживаться.
Моя идея заключалась в том, чтобы использовать сложные техники виртуальной памяти для подмены блоков данных. Допустим, если уровень занимает 30 мегабайт, то в конкретный момент времени нам может требоваться только один мегабайт, но весь уровень на самом деле составляет 30 мегабайт. Я решил разбить весь уровень на страницы по 64 КБ, создав из них блоки данных. Они могут быть чем-то осмысленным, например, анимацией Крэша, его кодом или частью фона. Блоки должны быть меньше 64 КБ, мы запихиваем их в страницу, пока она почти полностью не заполнится, но они не могут разделяться на несколько страниц, или придётся разбивать блоки на ещё меньшие блоки. Когда уровень состоит из 30 мегабайт страниц, в памяти может поместиться 16–18 страниц. Проблема заключается в том, смогу ли я распределить блоки уровня таким образом, чтобы на любой точке уровня мне никогда не понадобится больше 16 страниц данных; также можно было взять один блок, дублировать его на несколько страниц, если бы это помогло работать лучше всей системе. Игра заранее, но постоянно определяет, какие страницы она будет загружать, если игрок двинется одним из путей, отбрасывает старые страницы, которые ей не нужны, загружая на их место другие. Любая страница может заменить любую другую, если нам никогда не понадобится больше 16 активных страниц одновременно. Все текстуры Crash достаточно чёткие и со множеством цветов, а текстуры Tomb Raider как будто размыты и пикселизированы, потому что на них выделено мало памяти. У разработчиков не было места для хранения дополнительной текстуры. А у нас для этого было в 20–30 раз больше пространства. Или возьмём количество полигонов на уровне. Игры наподобие Tomb Raider выглядят очень кубическими, с квадратными коридорами, а в Crash есть безумные формы и многое другое, потому что у нас было намного больше полигонов. Было множество других технологий, служивших этой цели, но очень важной оставалась память. Благодаря этому я получил целую кучу патентов потому что оказался одним из первых людей, которые поняли, как на самом деле использовать место на CD или диске в качестве динамической части игры, чтобы расширить её. Сегодня это происходит постоянно.
Я считаю, что одним из важнейших уроков Crash Bandicoot стало то, что игры, оказывается, могут иметь собственную уникальную стилистическую индивидуальность и художественный стиль. И да, в определённой степени раньше это делали и другие. В конце концов, у Марио есть собственный стиль, который во многом задавал стиль видеоигр прошлого. Но Crash имеет собственный целостный мир с очевидными заимствованиями из стиля американских мультфильмов. И вся продукция Crash (я имею в виду первые четыре игры) придерживалась этого стиля. В оригинальные версии по-прежнему интересно играть и они выглядят довольно неплохо даже на PlayStation 1, потому что подобный стиль как бы превосходит пиксельные ограничения. На ранних этапах разработки у нас была совершенно высокомерная полунадежда-полумысль: важным фактором выбора PlayStation стало то, что у Nintendo есть Марио, а у Sega есть Соник. А у Sony, похоже, пока не было маскота, поэтому мы если мы создадим игру с персонажем, похожим на маскота, то конкурентов у нас не будет. И Sony действительно сразу заинтересовалась, они хотели эту игру. Мы должны были гарантировать, что она появится только на PlayStation. Мы намеренно решили создать такую ситуацию и затем изучили свои возможности. Но то, что это сработало, оказалось чудом. Мы мечтали, что Крэш станет маскотом. Но даже когда Sony согласилась сотрудничать, она так и не сделала его официальным — они говорили, что это не маскот, что у них нет маскота, но все считали его маскотом, и компания настолько поддерживала это, что даже выкупила права у Universal.
Продажи Crash Bandicoot начались хорошо, но они продолжались снова и снова. Crash Bandicoot стала первой игрой, продавшейся лучше во второй год продаж, а возможно и в третий, и я уверен, что когда мы выпустили Crash Team Racing в неделю перед Рождеством, то Crash Bandicoot обогнал её, и продался бОльшим количеством копий, чем продавался за всё предыдущее время. Во-первых, это была игра, привлекательная для очень широкой аудитории, в неё могли играть все, от ребёнка до хардкорного геймера. В ней не было много жестокости, но персонажи очаровывали, она была забавной, а игровой процесс — довольно напряжённым и в то же время доступным. Можно было просто сесть и начать играть в неё, и для нас это было одной из самых важных целей. Я не хотел создавать игру, над которой надо слишком сильно задумываться. Crash Bandicoot стала кузнечным горнилом, в котором была выкована философия Naughty Dog: каждый элемент, попадающий в игру, должен быть отличным, потому что мы хотели создать действительно великолепную игру, игру, которая станет хитом, классикой, и чтобы добиться этого, мы решили, что в ней великолепно должно быть всё, а для реализации этого необходима наилучшая технология. Чем лучше технология, тем лучше будет ощущаться и выглядеть игра. Если ты реализуешь всё это правильно, то можно превзойти посредственность и создать игровой шедевр.
