В середине 90-х QuickTime VR от Apple была популярной новой технологией. Примерно в то же время Myst была популярной игрой на компакт-дисках.
Поэтому, конечно же, я решил сделать компьютерную игру на компакт-диске на основе QuickTime VR. Он будет сочетать то, что мы привыкли называть FMV (полное видео) и среду 3D CG со сценами QTVR.
Я написал то, что считал (и до сих пор считаю) интересным и оригинальным научно-фантастическим сюжетом для игры. Персонаж игрока садится на явно заброшенный космический корабль и должен понять, как вернуть его системы к жизни, путешествуя между различными узлами QTVR, представляющими ключевые места на борту корабля. Когда он это делает, в его сознание вторгаются фрагменты видео, которые могут показывать или не показывать ему, что случилось с командой. Все заканчивается крупными разоблачениями, поворотами сюжета и бравурным повествованием. Отличный материал, если я могу протрубить в свой собственный рог.
Для проекта, который назывался «Встреча», я объединился с моим другом-продюсером Джоном, и мы получили инвестиции от местной монреальской продюсерской компании. Достаточно произвести демо-версию игры.
Мы купили Power Mac 9500, программное обеспечение для 3D-моделирования и рендеринга (FormZ), Macromedia Director и приступили к работе.
Пока я целыми днями моделировал 3D-окружение на основе (очень крутого) концепт-арта, созданного для игры, Джон начал собирать производственную группу и подбирать актеров для подготовки к съемкам видеоматериалов, которые мы собирались использовать на зеленом экране в сценах космического корабля компьютерной графики. .
Это был бы мой первый опыт работы с актерами. Живые, а не компьютерные.
Код и дизайн
Предупреждение: этот пост может спровоцировать (больше) хватку жемчуга, если вы заботитесь об эффективности кода.
Я запустил профилировщик на sweep-mesh-group, изображенном на изображении выше, и результаты после небольшой оптимизации перечислены здесь.
Актуальная сцена обновляется примерно за 2 секунды. Остальное время — это накладные расходы на профилирование (вероятно, включая накладные расходы на подкачку и все, что у вас есть). Вращающийся пляжный мяч определенно наблюдался.
Незначительные оптимизации привели к ускорению примерно в 2 раза, что показывает, что код (как я знал) далек от оптимизации. На самом деле, как я и подозревал, структуры данных point и color несут значительные накладные расходы. Минимум 20%, а может и больше.
Я мог бы использовать объявления для встраивания и типов, а также уменьшить консинг. Я подозреваю, что происходит много ненужного анализа из-за преобладающего использования списков из-за педагогических корней программного обеспечения. Замена их массивами может помочь уменьшить потребление.
Наконец, есть возможность реализации точек и матриц в виде библиотек C, хотя это усложнит управление памятью и приведет к работе с FFI (чужим интерфейсом функций). Я пожалуй воздержусь от этого.
На самом деле, я, вероятно, отложу дальнейшую оптимизацию до тех пор, пока (когда-нибудь) не реорганизую код в значительной степени, возможно, изменив реализации Common Lisp в процессе. Следите за обновлениями.
