SCUMM можно считать просто «одним из» видеоигровых движков, но этот движок вызывает почти столько же чувств, что и игры, сделанные на его основе.
Говоря о золотом веке адвенчур LucasArts, нельзя обойти вниманием движок SCUMM, «Script Creation Utility for Maniac Mansion» («утилиту создания скриптов для Maniac Mansion»), который использовался в самых запомнившихся играх всех времён, таких как Full Throttle, Day of the Tentacle, Sam & Max Hit the Road, и, разумеется, Maniac Mansion.
Написали SCUMM Арик Уилмундер (Aric Wilmunder) вместе со знаменитым гейм-дизайнером Роном Гилбертом (Ron Gilbert), обеспечив таким образом возможность создания этих игр. Недавно Уилмундер и журналист Майк Бевэн (Mike Bevan) связались друг с другом по электронной почте и обсудили SCUMM и истории, его окружавшие. В статье представлены избранные фрагменты этого разговора, записанные со слов Уилмундера.
Мы решили, что важно передать слова Уилмундера, потому что SCUMM — это не просто движок или технология. Для многих разработчиков это был способ передачи своего художественного видения тысячам людей в один из самых запомнившихся периодов истории видеоигр.
Эволюция движка
Одним из свойств, отличавших LucasArts от большинства других разработчиков, было то, что многие из нас пришли с мейнфреймов, поэтому мы разрабатывали инструменты и компиляторы на рабочих станциях Sun, а затем создавали оборудование, позволявшее загружать код и данные на нужные платформы. Всё началось с Atari 800, потом Рона [Гилберта] наняли работать с C64, поэтому похожую систему создали и для этой платформы.
Важнейшим преимуществом было то, что мы могли разрабатывать инструменты на C, или, как в случае SCUMM, использовать YACC для обработки и маркировки кода. Большинство разработчиков использовало для написания и выполнения кода одну и ту же машину, поэтому их инструменты использовали возможности только одной платформы.
После первых нескольких лет разработки продуктов для PC, сам PC стал таким же мощным, как и наши первые рабочие станции, поэтому один за другим мы начали выполнять миграцию наших инструментов и постепенно отказались от рабочих станций Sun.
Эволюция возможностей началась очень рано. Я был первым внутренним разработчиком, работавшим на PC, и в то время инструменты и компиляторы были очень грубыми. Например, компиляторы C в случае возникновения ошибок выдавали очень «подробные» описания. На PC можно было получить сообщение типа «File: walk.c Line:409 Error: 4004», после чего нужно было лезть в код и разбираться, в чём проблема, или достать руководство и превратить код ошибки в нечто более понятное. Иногда описания ошибок тоже были запутанными. Так как у нас не было хороших редакторов для написания кода на PC, я использовал редакторы на Sun, а потом переносил файлы. Когда на PC возникали ошибки, я перекомпилировал и отлаживал код на рабочей станции Sun. Это стимулировало меня писать более чистый код, который бы с самого начала работал на двух сильно отличающихся машинах.
На PC было ещё множество дополнительных сложностей, потому что управление, звуки и графика совершенно отличались. Например, мыши не всегда были стандартным оборудованием, поэтому управление было рассчитано на мышь, джойстики или клавиатуру. Это упрощало перенос игрового движка на другие платформы, потому что управление стало модульным. Для звука мы поддерживали внутренний динамик, ещё, кажется, звуковую карту CMS (предшественника Adlib), а также звуковую систему для компьютеров Tandy. Графика тоже была модульной, потому что мы поддерживали чёрно-белые дисплеи Hercules, четырёхцветную CGA-графику, 16-цветную EGA, VGA в 16-цветном режиме и Tandy Graphics в ещё одном графическом режиме. Чтобы реализовать это, вся графика рендерилась в буфер памяти, а затем очень специализированные процедуры копировали буфер в видеокарту. Мы использовали так называемую систему «грязных прямоугольников», отслеживающую те области, которые обновлялись, поэтому мы копировали только необходимые части экрана.
Арик Уилмундер
Общение на SCUMM
SCUMM был языком, компилируемым в размеченной форме. Например, команда «walk dr-fred to laboratory-door» преобразовывала команду Walk в однобайтовую команду. Следующий байт определял, для какого актора или персонажа была эта команда, а объект «laboratory-door» преобразовывался в двухбайтовое число, то есть вся команда уменьшалась до четырёх байт данных. Байт, если вы не знаете — это фрагмент компьютерной памяти, который может содержать численное значение от 0 до 255. Как мы видим, размеченный язык очень эффективен. Интерпретатор никогда не знал, каким актором был «dr-fred»; это было просто число актора, поэтому мы всегда старались избегать жёсткого задания любой специфической информации об игре непосредственно в интерпретаторе.
Единственным исключением из этого правила в Maniac был цвет, которым актор отображал текст…
При разработке Maniac у нас была пара исключений из правила, что интерпретатор никогда не должен иметь кодированных игровых значений. В нём пришлось указать цвета, используемые для акторов, и цвет отображения их фраз. Исходный код встраивал эти значения в интерпретатор. После переноса Maniac на PC и до выпуска Zak McKracken были добавлены две новые команды, чтобы этими значениями можно было управлять из скриптов. «set-actor-talk-color» и «set-actor-color» удаляли специфические команды игры из интерпретатора, чтобы всем управлял скрипт.
Я говорю об интерпретаторе, поэтому давайте рассмотрим его подробнее. Интерпретатор — это программа, запускаемая конечным пользователем. Она инициализирует графику и звуки, считывает файлы с диска и интерпретирует скрипты в этих файлах для выполнения игры. При выпуске игры мы переименовывали интерпретатор в «Monkey.exe» или «Dig.exe», но во время разработки этот инструмент назывался SPUTM, что расшифровывается как «SCUMM Presentation Utility (tm)». Название на самом деле не является торговым знаком (TM), но нам просто хотелось, назвать его как ещё одну жидкость тела.
SCUMM, или Script Creation Utility for Maniac Mansion был инструментом, размечающим скрипты и объединявшим все игровые ресурсы в файлы, которые мы выпускали на дисках. Версия SCUMM, использованная для Maniac, должно быть, содержала примерно 80% команд, использованных в последующих играх, таких как Full Throttle. После завершения разработки языка большинство важных команд никогда не менялось. «walk bernard to clock» и «walk ben to motorcycle» в сущности ничем не отличались.
Многозадачность SCUMM
Наверно, самой выдающейся частью SCUMM была многозадачность. Это означало, что одновременно можно было выполнять несколько скриптов. Можно было создать часы на стене в офисе Зака Маккракена и анимировать их. Был простой, очень простой скрипт специально для часов, который говорил движку анимации менять одно изображение часов на следующее, давал указание звуковому движку воспроизводить звук тиканья, затем приказывал скрипту «sleep-for 1 second», и повторял действия. Команды Sleep были обманчиво простыми командами, говорившими системе, что скрипт завершён и нужно вернуться назад через какое-то время и продолжить выполнение скрипта с точки, в которой был выполнен выход. «Sleep» ожидала указанное количество времени.
Была также возможность «Wait». Она часто использовалась, когда актору приказывали идти к объекту или повернуться в нужном направлении. Скрипт просто командовал актору идти, затем давал команду «wait-for actor», которая погружала скрипт в сон, пока актор не достигнет нужной точки или не повернётся в нужном направлении. Это позволяло писать скрипты в очень линейном стиле, отражающем последовательность действий, которые должен был выполнить актор.
Всевозможные полезные инструменты с отвратительными названиями
Наряду с SCUMM и SPUTM было ещё множество других инструментов, которые мы разработали для создания игр. SPIT был простым редактором шрифтов для создания разных форматов текстов для разных частей интерфейса. Диалог в верхней части экрана мог иметь один шрифт, другой мог использоваться для экрана сохранения игры, а третий применялся для команд-глаголов интерфейса в нижней части экрана (Walk-To, Pick-Up, Look At и т.д.). FLEM был графическим инструментом, используемым для управления комнатами. Можно было помечать объекты в комнате, их состояния (закрытые или открытые двери) и таким образом создавать области, определяющие доступные для перемещения акторов места. FLEM также позволял просматривать плоскости отсечения, которые были слоями, скрывавшими актора, заходившего за объекты или поверхности. В Maniac была всего одна поверхность, но в последующих играх могло быть до трёх плоскостей, за которыми мог скрываться актор.
Maniac Mansion
MMUCUS был помощников FLEM. MMUCUS получал изображение комнаты и данные объектов, данные плоскостей отсечения и областей, в которых можно ходить, и сжимал данные в файл «room», содержащий всю эту информацию. Это было важно, потому что соединение вместе сжатых данных позволял создателям скриптов вносить быстрые изменения в скрипт, после чего нужно было просто скомпилировать его, чтобы изменения вступили в силу. Файл room оставался неизменным, он менялся только при добавлении объектов или изменении областей, доступных для движения.
BYLE — это наш исходный инструмент анимации, использовавшийся для отрисовки и анимирования акторов. BYLE имел простой движок анимации, который можно было запрограммировать на циклическую смену анимации с одного кадра на другой. Кроме того, он понимал «направление», то есть можно было менять сторону, в которую повёрнут актор. Можно было различными способами сжимать акторов, и это позволяло делать так, что очень простые и быстрые анимации, например как в начале Day of the Tentacle, занимали мало места, а для многоцветных персонажей, например, для Бена Троттла (Ben Throttle), использовался другой способ сжатия, необходимый только при 16 или 32 цветах. Со временем у нас возникла потребность в более сложных анимациях, поэтому был разработан новый инструмент CYST, в котором использовался тот же самый формат данных, но управление большими изображениями значительно упростилось.
Очень недолгое время у нас был инструмент под названием SMEGMA. У одного из программистов был ребёнок, и он сказал нам, что первые кишечные выделения младенца состоят из этого вещества. Оказалось, что он ошибся, а вещество называется Meconium (меконий). Мы не стали выяснять, что такое Smegma, нам просто понравилось название. Но однажды проверили значение слова, и через пару дней сменили название. Вы наверно можете представить, что стоять рядом с нами в столовой было довольно неприятно, мы обсуждали SCUMM, BYLE, MMUCUS, FLEM и так далее. [Прим. пер.: одно из значений scum — семя, bile — желчь, mucus — слизь, FLEM созвучно с phlegm — мокрота.]
Обновление SCUMM
SCUMM критикуют за то, что в него не вносились революционные изменения, и вместо этого он постепенно усовершенствовался. Явным примером этого можно считать графику. Мы начали с поддержки 16-цветной графики в разрешении 320х200. С увеличением количества графических карт мы перешли к 256 цветам и разрешению 640x480. В звуковой системе мы начали с внутреннего динамика IBM и перешли к многоканальному потоковому стереозвуку. Персонажи, которые раньше были высотой всего в несколько пикселей, теперь могли вырастать почти на всю высоту экрана. Интерфейсы тоже эволюционировали: от начального интерфейса с командами-глаголами к сложным UI на основе значков, похожих на современный стиль Mac.
Одним из важных шагов стала интеграция движка INSANE, видеосистемы, разработанной для Rebel Assault. Изначально я нанял Винса Ли (Vince Lee) для работы над версией одной из игр SCUMM для Amiga, но он быстро доказал свои программистские навыки на различных платформах. При работе над SCUMM он увидел, как я занимаюсь тем, что изолирую первичные машиннозависимые части системы для упрощения портируемости на другие компьютеры. При разработке INSANE он попробовал вывести этот подход на новый уровень и добавил возможность потокового воспроизведения и ветвления видео, поэтому мы посчитали очень важным внедрить эту систему в SCUMM. Full Throttle стал первым шагом в этом процессе. Благодаря рок-н-ролльным саундтрекам Gone Jackals, когда кто-нибудь запускал игру в соседней комнате, это быстро замечали окружающие. Движок Throttle был явно неидеальным: когда запускался INSANE, систему SCUMM приходилось останавливать. Поэтому между Throttle и Monkey 3 я попытался полностью интегрировать эти две системы. Я выкинул оригинальную систему видео и курсоров, даже систему шрифтов, поэтому SPUTM на самом деле выполнялся поверх INSANE. Получалось, что мы клали всё больше яиц в одну корзину, но выгода была огромной. Например, если бы я добавил поддержку японского или корейского языков, то и продукты на движке Rebel Assault и продукты на SCUMM могли бы поддерживать японский и корейский.
Впечатляющая многоплатформенность
Благодаря простоте портирования игры SCUMM работали более чем на дюжине систем и примерно на дюжине языков. Мы начали с Commodore 64, потом был IBM PC, Atari ST, Amiga, восьмибитная консоль Nintendo, Fujitsu Towns, [Fujitsu] FM Marty, Sega CD, CDTV, Mac, а недавно добавились ещё и iPhone с iPad. Неплохо для системы, разработанной 25 лет назад.
При наличии таких проектов как ScummVM, написанного фанатами интерпретатора SCUMM, возможна поддержка новых платформ. Именно Monkey Island была выбрана как одна из пяти игр, демонстрирующихся в Смитсоновском музее американского искусства и доказывающих, что хороший сюжет часто более важен, чем новые технологии игр-однодневок.
Не всем было известно, что SCUMM также был основой для множества популярных обучающих игр, таких как Putt-Putt, Freddi Fish и Spy Fox, а также серий Backyard Baseball/Football/Soccer, разработанных Humongous Entertainment. Если взглянуть внутрь, то можно найти те же команды и почти тот же код, что и у их братьев из LucasArts.
Изучение SCUMM
В то время все дизайнеры были также и программистами, поэтому SCUMM, хоть он и был во многих аспектах уникальным, был довольно прост в изучении и кодировании. Во время Maniac или Zak у движка не было руководства, но перед Monkey была нанята группа из 6-8 новых создателей скриптов. Для них написали руководство и провели недельное обучение (Scumm University, «Университет Scumm»). Для курсов Рон взял самую последнюю игру, удалил из неё всё, кроме одной комнаты и поместил в неё объекты, показывающие возможности движка.
Новые создатели скриптов («скамлеты») начинали с этой комнаты и учились основам. За несколько дней их учили, как добавлять новые комнаты, создавать области движения. Некоторые обладали художественными навыками и создавали собственные анимации, другие занимались написанием диалогов. Обычно к концу недели у нас уже было довольно хорошее понимание навыков, которыми обладали «скамлеты», после чего лидеры различных проектов выбирали, кто из них будет работать в их проектах.
Мне кажется, что первый «Университет Scumm», или «Scumm U» начался со стандартного интерфейса с глаголами. Одним из первых проектов всегда был анализ работы интерфейса. Поэтому обычно один-два создателя скриптов начинали с того, что заставляли систему работать. Говоря про обучение «скамлетов», я вспоминаю, что однажды оно проводилось на Ранчо [ранчо Джорджа Лукаса]. Все собрались на третьем этаже главного здания. Офисы Джорджа были на втором этаже, поэтому им нужно было вести себя очень хорошо.
Secret of Monkey Island
Преимущество SCUMM
Одно из самых больших преимуществ SCUMM заключалось в высокой скорости создания прототипов. Дизайнер придумывал идеи для комнат и локаций, потом ведущий художник по фонам начинал делать эскизы. Когда достаточное количество эскизов было готово, их сканировали, очень быстро добавляли и соединяли с помощью SCUMM. Обычно уже через несколько недель после начала процесса дизайна уже было несколько десятков комнат, иногда это были просто карандашные эскизы. Мы брали акторов из другой игры и начинали соединять их вместе. Иногда оказывалось, что комнату нужно перевернуть или перерисовать, если она не очень хорошо подходила, но всё равно можно было прототипировать огромную часть игры.
Создатели скриптов теперь могли создавать предварительные области движения, чтобы актор мог передвигаться по комнате, художники по фонам могли начинать преобразовывать эскизы в окончательную графику, а аниматоры начинали работать над анимацией персонажей. Поскольку окончательные персонажи всё ещё находились в процессе создания, на этом этапе разработки можно было побродить в нарисованной карандашом комнате из Full Throttle, но место основного персонажа мог занимать Гайбраш из игр Monkey Island. Такие замены позволяли дизайнерам экспериментировать и вносить изменения и улучшения с очень низкими затратами труда.
Долгая жизнь SCUMM
Не думаю, что кто-то из нас полагал, что игры SCUMM будут с нами так долго. Я работал над системой примерно двенадцать лет, и постоянно стремился подготовить код к длительному использованию, тестируя его на как можно большем количестве платформ. При разработке под Windows я тестировал его в Windows NT, даже если она не была одной из наших целевых платформ. Но NT требовала более строгих стандартов кода. Поэтому если игра работала в NT, увеличивались шансы на то, что она будет работать на будущих операционных системах Windows.
Также я старался избегать слишком частых трюков в коде, которые могли бы вызывать сбои на компьютерах будущего. Например, можно написать самоизменяющийся код, но при определённых размерах и типах кэша процессора он будет приводить к сбою. Поэтому вместо этого я писал пять или шесть немного отличающихся вариаций одной процедуры, каждая из которых была специально оптимизирована под конкретную ситуацию. Например, было множество версий кода отрисовки акторов. Если актор находился в полноэкранном режиме и не скрывался за другими объектами, я использовал одну версию кода. Если актор выходил за левый или правый край экрана, я делал другую версию. Для масштабирования актора была ещё одна версия. Кажется, было восемь вариаций того, как мог выглядеть актор, и у меня было восемь версий кода, каждый из которых был оптимизирован для наиболее быстрого выполнения задачи. Также изначально я писал код на C, чтобы заставить его работать и оптимизировать. Потом я переписывал код на языке ассемблера, чтобы добиться максимальной скорости. Код на C был удобен, когда мы разрабатывали SCUMM для других компьютеров, потому что разработчики могли запустить этот код и он работал, после чего можно было заняться его оптимизацией.
Scumm 2.0 называлась система для Zak. В Maniac использовалась версия 1.0, в Zak — 2.0, в Monkey — 3.0, а в Indiana Jones and the Last Crusade — что-то вроде 3.0 или 3.1. Мне нужно немного покопаться, чтобы найти точные номера версий. Кроме того, были номера специальных выпусков. Первая 256-цветная версия Indiana Jones была рекламой производителя видеокарт. Я заставил код работать, но в то время на рынке было мало 256-цветных карт, поэтому мы заключили сделку и поставляли игру вместе с видеокартой.
Преимущества интерпретируемых языков
Рон какое-то время работал с интерпретаторами. Он разработал новые команды, которые можно было добавить к Commodore Basic, поэтому он выполнил реверс-инжиниринг этой системы. При создании Maniac он подумал, что это будет самым лучшим подходом, а Чип Монингстар (Chip Morningstar) имел опыт в работе с компиляторами языков, поэтому язык в основном развивался благодаря их сотрудничеству. Ирония в том, что в то время Чип работал над проектом Habitat, в котором вместо интерпретируемого кода поддерживались фрагменты ассемблерного кода 6502, которые менялись и перемещались в память. Сбой любого из этих фрагментов вызывал сбой всей системы. С другой стороны, в SCUMM использовалось всего около 80 команд, и команды были упакованы в байты со значениями от 0 до 255. Если значение команды было больше 80, то система сообщала об ошибке, поэтому SCUMM мог очень быстро дать понять, что выполняет неправильные команды. А Habitat просто «вываливался», и в нём было очень сложно отслеживать ошибки. Думаю, что в ретроспективе Чип решил бы использовать интерпретируемый язык.
Другим преимуществом интерпретируемых языков является лёгкая миграция между разными аппаратными платформами. Интерпретатор был написан удобно портируемым кодом на C, и очень просто анализируется через набор маркеров команд. Ещё одним огромным преимуществом было то, что вся игра была данными. При разработке под новые машины мы знали, что все данные правильны, поэтому работать и искать ошибки нужно было только в очень небольшом количестве кода.
Работа с неподражаемым Роном Гилбертом
Работать с Роном было невероятно забавно. Вот пара баек…
Бóльшая часть нашей ранней графики создавалась традиционными художественными технологиями. Карандаши, ручки, бумага, а случайные ошибки исправлялись ножом Exacto. Однажды Рон стащил одно из лезвий и несколько дней играл с ним на своём столе. Он привык при написании кода держать нож между зубами с высунутым изо рта лезвием. В один день я услышал громкий вздох, обернулся и увидел кровь, стекающую на пол с руки Рона. После того, как я помог забинтовать руку, мы забеспокоились о возможности столбняка, поэтому я позвонил своей жене и попросил сделать Рону укол. Рону на лицо упали волосы, а он забыл, что у него между зубов лезвие, сделал движение рукой, чтобы поправить волосы и воткнул лезвие прямо в ладонь. После этого ножи не покидали художественного отдела.
***
В другой раз мы с Роном работали вечером в здании на бульваре Кернер, рядом с Industrial Light & Magic, и у нас возникло серьёзное разногласие о том, как нужно реализовать фрагмент кода. Рон и я часто работали до десяти-одиннадцати часов вечера, поэтому мы хорошо знали уборщиков. Один из них даже потом стал киномонтажёром. Ну так вот, в тот вечер я был уверен, что моё решение проблемы было правильным, Рон был уверен, что лучше его подход, по какой-то причине спор постепенно нарастал и закончился соревнованием в крике. Наконец Рон встал, кажется, обругал меня, вышел и со всей силы хлопнул дверью. Наверно, я подумал, что избавился от него, и вернулся к написанию кода. Примерно через пять минут Рон вернулся и спокойно сказал: «Ладно, мы закончили с этим. Теперь давай выясним, как решить эту проблему». Уже через несколько минут мы уже вернулись к доске и работали над решением, более внимательно прислушиваясь друг к другу. В результате мы создали гибридное решение, позаимствовавшее лучшее из обеих наших идей. Рон был настоящим мастером совместной работы.
***
Тоже в начале разработки один из наших сотрудников должен был провести презентацию в компьютерном клубе в Беркли. У нас не было серьёзных дедлайнов, поэтому мы залезли в машину, чтобы пересечь мост Ричмонд-Сан-Рафаэль и посмотреть выступление. Примерно посередине поста Рон увидел стоящую на аварийной остановке машину, поэтому я остановился. Это был наш сотрудник, у него спустило шину. Запаски у него не было, а моя не подошла, но он не хотел оставлять машину, поэтому отдал нам две коробки флоппи-дисков и попросил провести презентацию вместо него.
У нас не было никакого плана выступления, только диски. Поэтому когда нас представили, я просто начал вытаскивать диски и загружать всё, что найду, на компьютер, в то время как Рон произносил совершенно импровизированную речь. Учась в колледже, Рон работал на радио, и был в «утренней команде», поэтому ощущал себя как рыба в воде. Я никогда не любил публичные выступления, но хорошо умел показывать программные «демки». Презентацию восприняли очень хорошо, и мы возвращались домой воодушевлёнными. У нас было хорошее настроение и на следующее утро, до десяти часов, пока не появился наш сотрудник. Он был в гневе, и мы не могли понять, почему. Мы прикрыли его задницу, да и публика осталась довольна. Оказалось, что в зале находился друг нашего сотрудника. Когда его спросили, показывали ли демо какой-то определённой части, то оказалось, что нет. Мы не знали, что было на дисках, и наверно пропустили её. Вместо того, чтобы поблагодарить нас, сотрудник подумал, что мы намеренно саботировали его демо.
***
Рон Гилберг, Арик Уилмундер, Ноа Фальштейн, примерно 1985 год (фото с Mobygames)
В ночь землетрясения Лома-Приета мы с Роном должны были поехать в Сан-Франциско, чтобы найти его подругу. Мосты были перекрыты, мы видели, что пожар поглотил квартал в районе Марина, и нам нужно было найти её. Моя жена была очень встревожена, но я не хотел оставлять Рона одного. Мы уже собирались выходить из дома, но зазвонил телефон. Это была подруга Рона, она села в автобус до Сан-Рафаэля и её нужно было подвезти.
***
В какой-то момент Рон ушёл из LucasArts, потому что его подруга должна была уехать преподавать в Китай. В это время я работал над Maniac Mansion для PC, поэтому когда я встречал написанные Роном части кода, которые не понимал, то буквально преобразовывал код ассемблера 6502 напрямую в C, чтобы система работала, даже если я не осознавал, что она делала. Этот код переписали после возвращения Рона, но даже спустя годы ходили слухи о затаившемся в системе коде 6502.
***
На время своего отъезда Рон одолжил свою новую Mazda RX7 другому коллеге. К сожалению, когда однажды вечером он возвращался домой, дорогу перебежал олень, машина слетела с дороги и перевернулась на забор с колючей проволокой. Поцарапался кузов и разбился люк на крыше. До приезда Рона коллега отремонтировал весь кузов и перекрасил машину. Рон не знал об аварии и удивился, потому что солнцезащитный люк на крыше казался ему другим. Потом коллега рассказал ему, что случилось, Рон успокоился и не стал сердиться.
Мой друг SCUMM
25 лет — это очень большой срок. Не думаю, что есть общий список всех игр, в которых использовался SCUMM, но между LucasArts и Humongous было, наверно, 30-40 разных игр. Я знаю — некоторые дизайнеры ощущали, что SCUMM ограничивает их возможности. Один из них сказал, что использовать SCUMM — это как пытаться сдвинуть слона стирательной резинкой.
Но я думаю, что самая популярная игра этого дизайнера была написана на SCUMM. Иногда ограничения в работе приводят к сосредоточению усилий. SCUMM был предназначен для выполнения одной задачи, и если вашей целью было создание отличных адверчур, то SCUMM был точно лучшим вариантом.
Я много раз играл во все игры SCUMM, от начала до конца, хотя в The Dig, кажется, я что-то пропустил и не играл в неё с самого начала. Меня разочаровало то, что я видел решение большинства лучших головоломок заранее, или в процессе разработки, или когда над ними работали художники с авторами скриптов. Некоторые головоломки я пропустил совершенно, потому что знал решение заранее и мне не нужно было искать подсказки. Кроме того, я играл в игры на многих языках и на разных машинах, потому что нёс ответственность за международные версии и кросс-платформенную разработку.
Мой ответ на вопрос о любимой игре на SCUMM остаётся тем же в течение многих лет. Мне всегда нравится и я больше всего горжусь самой последней игрой, над которой мы работаем. С каждой новой игрой мы старались раздвинуть границы и делать то, что до нас не делал никто. Я всегда считал: зачем вообще работать, если мы не делаем новый шаг в искусстве или технологиях? У меня есть любимые моменты, например, начальная анимация в Day of the Tentacle или юмор Sam and Max, музыка Full Throttle или возможность перемещения всеми тремя персонажами Maniac. Каждое достижение было особенным, но все они, как родные дети, занимают особое место в сердце.
Автор: PatientZero
