Ищем сокровища в исходном коде Aladdin

Нашел вот на хабре любопытную статью, много букв и картинок ...закончу сообщу...

На момент своего выхода в 1993 году Disney’s Aladdin на Sega Genesis (или Mega Drive, если в начале 90-х вы жили с другой стороны лужи) была удивительно красивой игрой.

Благодаря использованию технологии, которая позже стала известной, как Digicel, правильному выбору промежуточного ПО и впечатляющему таланту авторов Aladdin смогла выделиться на фоне других игр Genesis той эпохи. Красивая нарисованная от руки графика Aladdin установила новую планку качества для того, чего можно добиться на «железе» Genesis. Это стало возможным не с помощью особенно интересных растровых эффектов или тайных аппаратных приёмов, а благодаря сочетанию эффектной графики, дизайна и правильно выбранной технологии.

Эта уникальная смесь графики и технологий стала основной причиной, позволившей игре Aladdin занять особое место в истории видеоигр. Поэтому мне так радостно было найти архив с полным исходным кодом игры в коллекции Video Game History Foundation! Кроме бесценного источника данных, этот архив является для меня отличной возможностью создать стандарты для сохранения исходного кода, отслеживания зависимостей инструментов и многих других процессо-ориентированных аспектов в VGHF.

В этом архиве сохранились невредимыми почти все инструменты и материалы разработки. Я быстро начал объединять их фрагменты, и приступил к работе над получением исходного кода (который полностью написан на ассемблерном языке M68K), встроенного в работающий двоичный файл. Я расскажу вам о моём путешествия и об открытиях, сделанных на каждом из его этапов. В том числе нахождение множества неизданных материалов, и даже повторная реализация объектов и врагов, удалённых перед коммерческим выпуском игры!

Надеюсь, вам нравятся технические рассказы, потому что я не буду ничего утаивать. Если не нравятся, то тут есть картинки (и вы можете сразу перейти к части 3.0 Скрытое сокровище)! Можете также скачать копию Noesis, чтобы исследовать проект вместе со мной. Если этот инструмент вам неизвестен, то вкратце объясню: он построен на основе фреймворка и помогает в реверс-инжиниринге и изучении всех типов данных. В нём есть скрипт fmt_virginmd_chopper.py, позволяющий извлечть все данные тайлов Chopper из всех известных (коммерческих и иных) ROM-образов Aladdin. Полученные данные можно просматривать в самом Noesis. Хоть он и не позволит вам получить доступ к данным, не дошедшим до релиза, зато вы сможете просмотреть кадры и понаблюдать за тем, как используются тайлы в завершённом продукте.

Стоит также заметить, что Noesis может извлекать резервную копию данных Chopper из демо-сборки Aladdin для CES. В этой сборке есть пара уникальных вещей, в том числе дополнительные наброски, которые недоступны в сборке при обычном процессе игры.

Демо-сборка для CES помечена как Chicago CES, но как указано в статье TCRF о сборке, в сгенерированной SNASM метке времени указана дата 27 июня 1993 года. Это доказывает, что сборка была создана через несколько недель после проведения выставки.

Обратившись к архиву исходного кода, мы можем увидеть, что часть графики исходников была изменена уже в июне, и удалена из ROM в демо-сборке для CES. Из этого нельзя делать выводы (мы никак не можем узнать, изменялась ли графика исходников после удаления из базы данных Chopper), но это подтверждает мысль о том, что демо-сборка для CES могла быть создана из активной ветки разработки 27 июня 1993 года, а не была дальнейшей разработкой более раннего снэпшота проекта. Однако для простоты при обсуждении связанных с этой сборкой материалов мы будем продолжать называть её «демо-сборкой для CES».

1. Обзор

Архив с игрой Aladdin имеет такой вид, как будто это чья-то рабочая копия исходного кода и данных игры, а не какой-то общий репозиторий. В архиве отсутствует часть зависимостей данных, что немного удивляет, ведь на каком-то этапе игра собиралась на этом же самом рабочем месте. Однако мне удалось почти без проблем воспроизвести отсутствующие данные и получить работающий двоичный файл.

Хотя контент во всём остальном, похоже, соответствует распространяемым в розницу копиям Aladdin, изменения в файлах некоторых исходников датируются аж 30 сентября 1993 года. Это на десять дней позже, чем дата сборки японской розничной версии, выпущенной 20 сентября 1993 года. Заметных изменений данных нет, но при побайтовом сравнении появляются проблемы из-за значительно отличающихся условий сборки.

Очень интересно здесь то, что в этом архиве содержится большой кусок исходного графического материала! Здесь скрывается то, что никогда не было в игре. Этот материал обычно собран в более идеальную/компактную форму каким-то другим инструментом, а потом включён в сам ROM. В статье мы рассмотрим все эти инструменты и процессы.

Это сообщение отредактировал denisiuk - 21.10.2017 - 01:20

Пример исходных данных кадров анимации.

Ещё одним большим открытием в этом архиве Aladdin стали большие участки закомментированного кода для прототипированных и/или удалённых функций. В наши дни, если программист убирает в комментарии сотни строк уже неиспользуемого кода, а не удаляет их полностью, то его, скорее всего, вырежет программа анализа кода. Но благодаря этой удивительной практике мы спустя 24 года сможем насладиться возможностями, врагами и многим другим, что должно было войти в игру! Выкусите, стандарты написания кода!

2. Инструменты

Для всего процесса, от сборки кода до создания и подготовки данных к использованию, в Aladdin используется довольно объёмный набор инструментов, помещённый в удобную среду MS-DOS. Этот архив позволяет нам эффективно изучить настоящий процесс создания контента, использованный в Virgin для реализации этой игры. В этом разделе я расскажу, что делает каждый инструмент и изложу хронику моего исследования и использования этих инструментов.

2.1. SNASM68K

Старый лог в архиве сообщает, что исходным ассемблером для Aladdin была версия 1.29 (или 1.30, как указано в некоторых комментариях к коду) SNASM68K. Я уже немного познакомился с SNASM после краткого экскурса в разработку для Sega CD много лет назад, но у меня был доступ к более новым версиям этого инструмента. Это значило, что для сборки исходников мне потребовалось внести некоторые изменения. Наиболее неприятным изменением было то, что в какой-то момент SNASM решил перейти от "!" и "|" к оператору OR, что привело к значительным изменениям в макросах. Также потребовалось добавить несколько операторов ветвления, несмотря на то, что архитектура памяти осталась относительно неизменной относительно коммерческого двоичного файла.

При изучении кода стало сразу понятно, что файл под названием FOLDER.68K должен был стать точкой входа для ассемблера. В этом файле определяется несколько переменных, что-то вроде «конфигурации сборки». Многие из переменных условно включают/исключают биты кода и определяют, какие данные должны быть записаны в ROM: PAL или NTSC. Разобравшись с этим и решив проблемы, связанные с различием версий SNASM, я попробовал запустить получившийся бинарник, и был рад увидеть это:

Это сообщение отредактировал denisiuk - 21.10.2017 - 01:21

Этот фрагмент экрана читов, который, как оказалось, активен в розничной версии. Он по умолчанию появляется при запуске кода этого архива с обновлённой меткой времени, добавляемой SNASM. Его появление при запуске тоже зависит от одной из этих переменных «конфигурации сборки».

Я радостно двинулся дальше в игру, но был встречен зависанием при загрузке первого уровня. Пришло время взяться за отладчик! Так, стоп, у меня же нет отладчика. После пары попыток решения проблемы вставкой переходов на себя, чтобы сузить рамки возникновения зависания, я решил перестать мучить игру и посмотреть, существуют ли эмуляторы Genesis с встроенными отладчиками, которые не требуют скачивания 50 отдельных библиотек для создания собственной сборки с отладчиком. В этот момент я наткнулся на сборку Regen с включенным отладчиком, и дело пошло!

Поставив в Regen точку останова уже после зависшего состояния, я увидел, что счётчик программы находится в непонятном месте, состояния регистров перепутаны, а в стеке находится хлам, поэтому мне не удалось обнаружить последнее нормальное место выполнения кода, даже после попытки использования встроенного обработчика исключений Aladdin. Тут стало понятно, что будет не до веселья.

Создав с помощью SNASM адресную схему, чтобы понять, что же происходит, я получил адрес в точке кода, который походил на место, где начинается загрузка уровня. Я установил контрольную точку PC на этом адресе и запустил программу. После остановки на контрольной точке я пошагово продолжил программу и обнаружил, что она уходит в забвение где-то возле процедуры ProPack распаковки в ОЗУ. А именно, при распаковке данных FLOOR уровня. Они соответствуют своему названию — это таблица поиска, задающая тайлы пола уровня.

Я довольно долго пошагово выполнял цикл распаковки, не наблюдая никаких проблем, пока наконец не заметил адрес назначения. Процедура распаковывала данные пола по всему стеку пользователя. Похоже, что это ошибка! Я посмотрел на метки, определяющие положение активного пола в ОЗУ, и действительно, они была прямо над стеком пользователя.

Как оказалось, здесь происходила какая-то магия с макросами для получения максимального размера всех распакованных тайлов пола и использования его для определения размера области пола в ОЗУ. Эта магия макросов в моей версии SNASM в результате вычисляла отличное значение — 0. Я исправил эту ошибку и поискал в коде другие места, в которых бы использовалась такая же магия, и с этого момента всё пошло гладко. При поверхностном прохождении игры не возникло никаких очевидных ошибок.

2.2. Chopper

Chopper — это невоспетый герой, ставший фундаментом того, что Virgin называла технологией Digicel. К сожалению, у меня нет никакой информации о процессе, использованном для ручной отрисовки графики и её оцифровывания, кроме того факта, что на каком-то этапе графика импортировалась в DeluxePaint Animation. Не знаю, использовались ли в основном стандартные аппаратные/программные решения, или Virgin добавила собственные разработки. Всё что я знаю — после того, как данные поступали в DeluxePaint Animation, их оттуда получал Chopper.

Chopper — это полностью проприетарный управляемый с помощью интерфейса инструмент, работающий на основе собственного формата баз данных спрайтов. Его главным разработчиком был Энди Астор, но похоже, что в разработке участвовали и другие люди. В том числе Дэвид Перри, придумавший выходной формат данных Genesis. К сожалению, в архиве нет исходного кода Chopper, поэтому мы можем изучить его разработку только по сопроводительной документации.

Основной задачей Chopper была нарезка импортированных анимаций на тайлы, имеющих размер от 1×1 до 4×4 (в том числе и прямоугольных размеров, при которых каждый тайл имеет размер 8×8 пикселей). У него было множество вариантов нарезки, а также опций задания границ коллизий каждого кадра анимации и выбора нарезания кадра, последовательности кадров или целой базы данных. Сам интерфейс выглядел так:

На рисунке выше я импортировал заключённого (Prisoner), который исключён из розничной версии игры. Мы видим чёткие границы, по которым текущий кадр разрезался на группы тайлов. Жёлтый прямоугольник представляет собой границы коллизии кадра, а каждое число определяет, сколько раз используется группа тайлов.

Хотя Chopper работает с собственным форматом баз данных, он может экспортировать данные тайлов в разные целевые форматы идеальной платформы с основным упором на Genesis и SNES. В случае Aladdin/Genesis Chopper записывает несколько файлов .SEG (от слова Sega, а не «segment», как мог подумать ваш внутренний программист или создатель карт для Doom), которые представляют собой весь объём «сырых» данных тайлов для каждого размера с 1×1 по 4×4. Chopper также генерирует несколько файлов .68K, которые должны собираться как код и задавать дополнительные свойства каждого кадра (номер части, коллизия и свойства каждой части, такие как размер тайла, смещение и индекс). Эти файлы также определяют нужный порядок вложения данных, отражающий конечное расположение данных в ROM и задающий все необходимые ограничения расположения самих тайлов данных.

Упомянутый выше в статье скрипт Noesis fmt_virginmd_chopper.py пытается найти данные кадров в ожидаемом формате Genesis и преобразовать их обратно в набор файлов .SEG и текстовый файл .68K, ссылающийся на файлы .SEG, используя тот же формат названий, что и нативные данные Sega Chopper. Можете поэкспериментировать с текстовым файлом, чтобы понаблюдать, как изменение свойств влияет на использование тайлов так же, как это было бы на настоящем «железе».

Ещё один интересный аспект Chopper заключается в том, что он настроен на поиск однопиксельного прямоугольника для задания границ анимационной последовательности. Я также закодировал опцию параметров, чтобы повторить это в импортёре DeluxePaint Animation в Noesis. Поэтому многие исходники анимации выглядят примерно так:

На рисунке выше я импортировал заключённого (Prisoner), который исключён из розничной версии игры. Мы видим чёткие границы, по которым текущий кадр разрезался на группы тайлов. Жёлтый прямоугольник представляет собой границы коллизии кадра, а каждое число определяет, сколько раз используется группа тайлов.

Хотя Chopper работает с собственным форматом баз данных, он может экспортировать данные тайлов в разные целевые форматы идеальной платформы с основным упором на Genesis и SNES. В случае Aladdin/Genesis Chopper записывает несколько файлов .SEG (от слова Sega, а не «segment», как мог подумать ваш внутренний программист или создатель карт для Doom), которые представляют собой весь объём «сырых» данных тайлов для каждого размера с 1×1 по 4×4. Chopper также генерирует несколько файлов .68K, которые должны собираться как код и задавать дополнительные свойства каждого кадра (номер части, коллизия и свойства каждой части, такие как размер тайла, смещение и индекс). Эти файлы также определяют нужный порядок вложения данных, отражающий конечное расположение данных в ROM и задающий все необходимые ограничения расположения самих тайлов данных.

Упомянутый выше в статье скрипт Noesis fmt_virginmd_chopper.py пытается найти данные кадров в ожидаемом формате Genesis и преобразовать их обратно в набор файлов .SEG и текстовый файл .68K, ссылающийся на файлы .SEG, используя тот же формат названий, что и нативные данные Sega Chopper. Можете поэкспериментировать с текстовым файлом, чтобы понаблюдать, как изменение свойств влияет на использование тайлов так же, как это было бы на настоящем «железе».

Ещё один интересный аспект Chopper заключается в том, что он настроен на поиск однопиксельного прямоугольника для задания границ анимационной последовательности. Я также закодировал опцию параметров, чтобы повторить это в импортёре DeluxePaint Animation в Noesis. Поэтому многие исходники анимации выглядят примерно так:

Многие исходники содержат активные данные изображений за пределами нужного прямоугольника, который, вероятно, стандартно использовался для записи примечаний и сравнения. После того, как Chopper импортирует последовательность с обработкой по умолчанию, она в результате выглядит так:

Для использования в процессе импорта Chopper для игры Aladdin был написан ещё один инструмент, который простейшим образом обрабатывает нативные выходные данные .68K Chopper для выдачи дополнительных покадровых таблиц/списков. В них входит линейный список указателей на каждый кадр. Возможно, так сделано из-за желания увеличивать счётчик кадров переходами между указателями, а не обработкой переменного размера (так как имеется разное количество частей) каждого кадра.

2.3. tUME

В Aladdin используется тайловый редактор карт общего назначения tUME. Как и в любой другой игре той эры, использовавшей tUME, в Aladdin есть собственный упаковщик tUME. Упаковщик — это отдельный инструмент, экспортирующий данные в набор форматов, идеально подходящих к платформе и конкретной игре.

Это сообщение отредактировал denisiuk - 21.10.2017 - 01:21

В случае Aladdin упаковщик tUME называется «tPJungle». Вероятно, он назван так, потому что был предназначен для использования в The Jungle Book. tPJungle создаёт множество файлов, в том числе данные блоков/персонажей, данные контуров (которые обычно являются общими для уровней), данные поиска/тайлов пола, различные типы данных комнат (в зависимости от того, является ли уровень традиционной комнатой или комнатой-картинкой, как бонусный экран Джинна и другие экраны камео, используемые в игре), файлы палитр и параллакса, которые позволяют нескольким слоям комнат ссылаться на данные персонажей/тайлов.

Выходные данные упаковщика tUME обычно затем сжимаются в отдельном пакетном процессе, после чего ссылки на сжатые (или в некоторых случаях на несжатые) данные вручную вносятся в файл .68K.

Враги и объекты располагаются в соответствии с номерами их тайлов. Это значит, что представленная ниже битовая карта таблицы тайлов соответствует непосредственно таблице в коде, запускающей выполнение спаунера/генератора соответствующего объекта на основании индекса тайла:

В таблице есть много неиспользованных ячеек, а также ячеек, которые раньше ссылались на удалённые теперь объекты (такие как заключённый (Prisoner) или глотатель мечей (Sword Swallower)), которые теперь перенаправляют исполнение на функции-пустышки. К сожалению, удалённые враги, похоже, не добавлены в исходники tUME, то есть кроме упоминаний в дизайн-документе у нас нет никакой информации о том, где и как должны были располагаться эти враги.

2.4. GEMS

В Aladdin применяется звуковой драйвер GEMS, использующий для воспроизведения музыки патчи FM и PSG. Также в PAL-версии есть отдельно сгенерированный набор данных. В нашем архиве нет промежуточных исходников GEMS, а сгенерированные с помощью GEMS код/данные сопровождаются пакетным файлом, из которого видно, что они скопированы локально из сетевого каталога. Это значит, что всё, что мы можем получить из этого архива, мы также можем получить из розничной версии игры, покопавшись в резервной копии данных секвенсора/сэмплов/патчей GEMS из двоичного файла.

Однако в этом архиве присутствует настоящий исходник Cakewalk MIDI (используемый для передачи секвенсору, который передаёт данные GEMS) и линейные сэмплы PCM, предоставленные самим Томми Талларико! Подробнее об этом можно прочитать в разделе 3.5 Звуки и музыка.

2.5. ProPack

Во множестве типов данных Aladdin активно используется ProPack Роба Нортена, в том числе для тайлов данных таблиц поиска пола и персонажей (но не анимированных/разрезанных). Как сказано в статье на Sega Retro, ссылку на которую я только что давал, в Aladdin используется только метод 1. Благодаря большому количеству справочной документации на декодеры (среди прочих, на языках ассемблера 8086, M68K и 6502), я также написал реализацию декодера для Noesis.

В архиве Aladdin есть множество пакетных файлов, которые, похоже, изменялись вручную для преобразования и сжатия всех нужных данных уровней, которые включались непосредственно в ROM. Предполагаю, что процесс создания уровней был примерно таким: «изменяем в tUME, сохраняем, выходим из tUME, выполняем пакетный файл, собираем, запускаем игру».

3.0. Скрытое сокровище

Самым потрясающим при изучении этого архива было открытие большого количества материалов, не вошедших в розничную версию игры. Меня очень удивило, что осталось невредимыми так много вещей, и ещё больше я удивился, когда выяснил, что в кодовой базе до сих есть куча соответствующего им кода (хотя он и не собран в образ розничного ROM).

Освоившись с Chopper и остальными инструментами, я решил заново импортировать часть удалённых ресурсов и добавить разные части кода для таких элементов, как старые генераторы объектов, анимации и логика элементов (которых в наши дни обычно называют акторами, или сущностями (entities), если вы фанат Quake). Я расширил размер ROM до 4 мегабайт (32 мегабита), чтобы в нём было достаточно места для возврата той части «плёнки», которая была вырезана на «монтажном столе» и чтобы не пришлось тщательно выбирать то, что я хочу вернуть. Часть кода была сразу готова к работе, но в других случаях мне приходилось что-то подправлять и настраивать, чтобы восстановить полный функционал.

Ещё одним потрясающим бонусом, найденным среди этих файлов, стала копия оригинального дизайн-документа игры версии 3.3, датированная 27 апреля 1993 года. Я использовал этот документ как справку, чтобы разобраться с истинным назначением незавершённого кода и функций, которые я нашёл в своём путешествии.

Я не буду описывать здесь все материалы, а поделюсь самыми большими на сегодня открытиями. Я также нашёл готовые для игры анимации скелета из демо-сборки для CES с дополнительной анимацией ходьбы. Похоже, что создатели намеревались сделать так, чтобы он падал в направлении игрока, а потом взрывался. В архиве нет кода для этого, и я ещё не настолько освоился, чтобы писать совершенно новую логику анимаций/состояний для него, поэтому я оставил это на будущее.

3.1. Бонусный раунд

Почти в первую очередь я наткнулся на код старого бонусного раунда Джинна. В нём в явном виде задаётся элемент «рука», которая представляет собой рычаг слот-машины, а также используется дополнительный код движения и состояния. Я полностью вернул код слот-машины Джинна и заново импортировал все зависимости анимаций через Chopper. Я также заметил, что в исходниках графики была анимация вращающейся монетки с Джинном, что имеет смысл с учётом тематики игрового автомата, поэтому я вернул и её тоже. Вот результат:

Можно заметить, что фон не совсем соответствует рычагу слот-машины. К счастью, мне удалось найти исходник карты tUME для фона, к которому он принадлежит, он был погребён в каталоге TRASH. Я экспортировал старую карту tUME с помощью tPJungle и вставил обратно в игру
Однако у этого фона есть свои собственные проблемы. Передний слой настроен не совсем правильно, и в коде не осталось логики, соответствующей идее слот-машине с тремя барабанами, которую должен изображать фон. Сложно сказать, может быть, этот фон не добрался до этапа прототипирования, прежде чем попал в разрезанный блок, или связанный с ним код был полностью удалён. Возможно также, что эта копия в TRASH не является окончательным фоном, который использовался до удаления этого тематического бонусного раунда со слот-машиной.

Чтобы вернуть эту бонусную игру, нам придётся самостоятельно исправить довольно многое так, чтобы она выглядела логичной и сочеталась с исходной темой слот-машины. Однако у нас всё-таки есть все данные, которые необходимы для правдоподобного воссоздания исходной задумки в новой реализации. Версия этой бонусной игры со слот-машиной очень подробно описана в дизайн-документе игры. В нём также описана игра «камень, ножницы, бумага», но нигде нет ни следа её исходого кода или графики, так что, похоже, эту идею даже не начинали реализовывать.

3.2. Враги

Перед коммерческим релизом из игры удалили множество врагов. Причины удаления зависели, вероятно, от конкретной ситуации: несоответствие дизайну/внешнему виду, недостаток времени разработки или ограничения места в ROM. Учитывая то, насколько плотно розничная игра умещается в 2 мегабайта (16 мегабит) ROM, мы можем только догадываться о балансе принятия решений в каждом случае. Некоторые из этих врагов были полностью рабочими, другие же для своего спасения требовали любви и заботы.

Глотатель мечей

Глотатель мечей (Sword Swallower) по своему дизайну очень похож на жонглёра кинжалами (Knife Juggler) и должен был стать частью линейки врагов на рыночных уровнях. Он сидит в одном месте, вытаскивает изо рта бесконечный поток мечей и бросает их по экрану. Потребовалось также подключить код его мечей, но он был рабочим без дополнительных модификаций. Похоже, он действует точно так, как в реализации из демо-сборки для CES.


Это сообщение отредактировал denisiuk - 21.10.2017 - 01:03

Заключённый

Заключённый (Prisoner) должен был появиться на уровне с подземельем султана (Sultan’s Dungeon). Он полностью завершён и имеет несколько последовательностей анимации. В режиме ожидания он спиливает цепь со своей ноги, а при приближении начинает размахивать ядром на цепи. У него также есть анимация боли/реакции, которую пришлось реализовывать с нуля, потому что следов связанного с ней кода не сохранилось. Заключённый также появляется в демо-сборке для CES, но в неправильной палитре, а в ROM отсутствует анимация реакции.

Золотая обезьяна

Золотая обезьяна (Golden Monkey) — это довольно простой враг, бросающий в игрока бесконечный поток самоцветов. На видео она показана в неверном контексте (на самом деле она должна была встречаться в пещере чудес (Cave of Wonders)). У неё больше нет других анимаций, и для её работы не требовалось никакого дополнительного кода.

В дизайн-документе поведение золотой обезьяны описывается как аналогичное поведению статуи Шивы в готовой игре. Статуя Шивы тоже должна была стать более интересным врагом, оживающим, когда к ней подлетает Яго и бросает пузырёк. Похоже, в какой-то момент просто решили отказаться от золотой обезьяны и использовать вместо неё статую Шивы.


Это сообщение отредактировал denisiuk - 21.10.2017 - 01:22

Яго-фламинго

На уровне «Дворец султана» (Sultan’s Palace) Яго должен был предстать в обличье фламинго. Он ходит по экрану на ходулях и наносит игроку урон при касании.



Это сообщение отредактировал denisiuk - 21.10.2017 - 01:22

Последовательность анимации Яго-фламинго также присутствовала в ROM демо-сборки для CES, хотя и этот враг не использовался в игре.

Катящаяся змея

Хотя змея и дожила до релиза игры, изначально она должна была кататься. На самом деле её внутреннее название ROLLY_SNAKE. Я наткнулся на код, который доказывал, что она должна была кататься, если после атаки оказывалась достаточно близко к игроку. Я подключил этот код обратно и увидел довольно любопытное поведение, при котором направление качения было очень случайным. Иногда змея оставалась в режиме «катания» даже после завершения анимации. Мне пришлось немного поработать над исправлением, и удалось вернуть эту атаку качением в состояние, в котором она выглядела логичнее.

Интересно, что в нашей версии дизайн-документа описываемое поведение довольно сильно отличается от того, что видно в коде:

Если змею два раза подряд ударяют метательными предметами, то она превращается в змею-колесо и катится вправо, через других врагов, убивая их. Змея катится так быстро, что Аладдин не может догнать её, и укатывается с экрана.

В исходном коде нет никаких свидетельств того, что это поведение вообще попадало в игру. Можно высказать догадку: это доказательство того, что существующая реализация качения была тестовой, эта функция показалась слабой, но разработчики всё равно пытались использовать уже созданные анимации. Анимации змеи (в том числе анимация катания) тоже присутствуют в ROM демо-сборки для CES, даже несмотря на то, что змея в этом демо не встречается.

3.3. Части тела Джинна

Из релиза игры было удалено несколько связанных с Джинном объектов, хотя ни один из них, похоже, так и не был доведён до совершенства. Эти объекты должны были использоваться на уровне «Внутри лампы» (Inside the Lamp) и влияли на движение игрока по карте.

Рука Джинна

Рука Джинна — это ладонь Джинна, соединённая с шестью шарами. Она двигается по постоянному маршруту и переносит игрока вместе с собой.

Сложно сказать, были ли они какой-то опасностью или тоже как-то влияли на перемещение. Возможно, что часть важного/связанного с ними кода была удалена (а не сохранилась для справки), потому что она привязана к другой (относящейся к игроку) логике.

Шар Джинна

Шар Джинна возникает при приближении игрока и при касании удерживает игрока на месте

Назначение шара Джинна описано в дизайн-документе:

Это палка о двух концах. Если Аладдин попадает на верхушку катящегося шара Джинна, он может использовать его как движущийся лифт, чтобы обойти разные области лампы. Также шар даёт дополнительную высоту, которая иногда нужна для прыжка в бонусную или секретную область, но Аладдину может потребоваться какое-то время балансировать на шаре, пока он докатится до места, из которого нужно сделать прыжок.

Код шара Джинна довольно сильно интегрирован в код движения игрока, поэтому будет неудивительно, если в новой воссозданной форме что-то серьёзно испортится. Возможно, объекту также нужны не указанные здесь дополнительные настройки, судя по его поведению в демо-сборке для CES.

3.4. Наброски

В исходниках графики есть несколько оцифрованных набросков. Вот, например, наброски каждого кадра из анимации падения Аладдина:

В наброске второй анимации падения Аладдина есть больше подробностей. На самом изображении обозначены конкретные кадры для циклов и удержаний:

Это даёт нам небольшой намёк на то, каким на самом деле был процесс создания графики. Особо примечательна найденная мной готовая для игры анимация Абу, которая всё ещё находится в состоянии наброска:

В этом фрагменте анимации Абу заглядывает в мешок. Похоже, что эта анимация не отражена в событиях игры или в сохранившемся коде прототипа. Однако связанная с ней механика, которая влияет на битвы с боссами, упоминается в дизайн-документе:

Аладдин приходит к боссу, скроллинг останавливается, музыка сменяется на тему босса, которая используется для всех боссов. После смены музыки на экран вбегает Абу и кладёт волшебный мешок с драгоценностями, которые он неохотно одалживает Аладдину где-то на экране (на последних уровнях и на высокой сложности — в более труднодоступных местах), чтобы помочь ему победить босса.

Потом Абу снова сбегает с экрана, потому что он очевидно не хочет участвовать в последующем «веселье»! Аладдину остаётся только подойти к мешку (так же, как он собирает все объекты и метаемые предметы), после чего мешок исчезает (в инвентарь Аладдина).

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

При возврате волшебного мешка реакция/поведение Абу зависит от количества камней, которые Аладдин потратил на босса. Чем больше драгоценностей было потрачено, тем более яростна жестикуляция обезьяны. Если Аладдин не использует камней, то Абу в свойственном ему стиле демонстрирует свою радость. Скорее всего, в версии для картриджа будет три реакции Абу (радость, невозмутимость, гнев), в CD-версии — пять реакций.

Эта анимация рыбы, также присутствующая в демо-сборке для CES, тоже сохранилась вместе с готовой версией исходников графики:

Она говорит нам, что у нас есть готовая к игре графика с маской, которая всё ещё находится в форме наброска и готова к дальнейшей работе, и что часть её была использована в игре для демо-сборки. Маловероятно, что такое случилось бы, если бы процесс создания графики до этого момента не был невероятно упорядоченным. Это показывает нам довольно интересный рабочий процесс!

3.5. Звук и музыка

Хотя у нас и нет никаких относящихся к GEMS промежуточных данных исходников/проекта, мы нашли в архиве нечто ещё более интересное: «сырые» файлы Cakewalk MIDI и данные сэмплов, предоставленные Томми Талларико. Все эти цифровые сэмплы поставлялись в форме «сырых» 8-битных линейных «блоков» PCM. Именно так Томми называет в сопровождающем письме частоты дискретизации:

Стоит проверить темп всех композиций на случай, если произойдёт что-то странное с PAL-NTSC. Я уверен, что теперь вы в курсе проблем! Все сэмплы имеют частоту 10,4 кГц, за исключением следующих:jl87.vmd 8.7honk.vmd 5.2xplode2.vmd 5.8camel2.vmd 8.7finger.vmd 7.3feet2.vmd 7.3feet3.vmd 8.7cash2.vmd 7.3feet5.vmd 8.7

Томми также упоминает здесь разницу таймингов между NTSC и PAL, что было особенно важно при использовании GEMS, потому что тайминг записывался в конечные данные секвенсора, передаваемые драйверу GEMS. В Aladdin создатели особо позаботились о добавлении отдельных звуковых данных для PAL.

Инструменты и оборудование, которые использовались для передачи данных секвенсора Cakewalk в GEMS, неизвестны, но «сырые» блоки линейных PCM соответствуют тому способу, которым GEMS ожидает обрабатывать данные сэмплов. Взглянув на файлы проекта Cakewalk (вместо изучения двоичного файла, предназначенного для драйвера GEMS), мы могли бы получить более чёткое представление и об исходных треках.

Это сообщение отредактировал denisiuk - 21.10.2017 - 01:23