|
|
|
|
|
Просмотр каталога:
Простой | Подробный
Статья Тома Леонарда (Tom Leonard) в журнале Game Developer в июле 1999 года
Перепечатано в интернет-журнале Gamasutra под заголовком "Postmortem: Looking Glass's Thief: The Dark Project".
Thief: The Dark Project - одна из тех игр что чуть было не пропали. на своем длинном пути на полки магазинов над проектом дважды нависала угроза отмены. Looking Glass чуть было не закрылась из-за денежного кризиса. В течение семи месяцев ушли продюсер, директор проекта, ведущий программист, ведущий художник, ведущий дизайнер и автор движка. Более того, над нами постоянно висел страх, что мы можем выпустить игру, которая никому не принесет удовольствия. Но в конце концов, мы выпустили относительно безглючную игру, которую было интересно создавать, которой мы гордились надеялись, что она понравится и другим.
Конепция
Что было хорошо
Что было плохо
Оглядывая проект в целом
Концепция
Команда Thief хотела создать игру от первого лица, которая бы представляла абсолютно новый стиль игры, по сравнению с уже представленным на рынке стилем first-person action. Thief должен был представлять собой игру с минимальной заскриптованностью, и по степенью интерактивности и импровизации со стороны игрока превышающую все наши предыдущие проекты. Коллектив надеялся соблазнить геймера глубоким погружением в мир, создав логичные возможности влиять на окружающую среду.
Основная механика игры Thief резко отличалась от традиционного стиля 3D игр от первого лица, представленных на рынке. Шутеры рассчитаны на быстрое прохождение, где игрок обладает невероятной силой и скоростью, и непреодолимым стремлением к конфликту. Однако игрок в Thief двигается медленно, избегая конфликтов, для него существуют наказания за убийство людей, а его самого убить весьма легко. Это стиль игры, который, как полагали многие эксперты, не будет привлекательным для геймеров, и даже те, кто был близко знаком с игрой, иногда сомневались в успехе.
Проект начался весной 1996 года под названием "Dark Camelot". Тогда это был экшн с драками на мечах с элементами ролевой игры, основанной на инверсии легенды о короле Артуре. Хотя официально проект уже разрабатывался в течение года, настоящий Thief родился только в начале 1997 года, когда игра была перепозиционирована как экшн-игра вором в мрачном фэнтези-мире. До этого момента у нас было совсем немного рисунков, дизайна уровней и кода, которые в конечном итоге должны были составить играбельный продукт. Настоящая разработка началась в мае 1997 года коллективом, состоящим практически полностью из людей, не участвовавших в первоначальном проекте. В течение следующего года команда создала огромное количество концепт-арта, кода и дизайна.
К началу лета 1998 года игра еще вовсе не была "играбельной", команда сильно устала, и настроение издателя было весьма скептическим. Философия построения игры в Looking Glass включает в себя постулат, что увлекательный геймплей порождается миром, богатым активными объектами и построенном на высококачественном самодостаточном движке-симуляторе. Создание игр в Looking Glass требует твердой веры, поскольку на разработку подобных движков требуется значительное количество времени, движок не всегда оказывается готов вовремя и требует последующей настройки и доработки. Для Thief движок был собран только в середине лета, лишь через 15 месяцев после начала полномасштабной разработки проекта, и лишь за 3 месяца до запланированной даты выхода.
Когда игра была собрана окончательно, мы начали чувствовать, что она не просто не выглядит отвратительно, но даже в нее весьма интересно играть. Выход игр с элементами стелса (например, Metal Gear Solid и Commandos) и шутеров с бОльшим наполнением уровней (Half-Life) рассеяло сомнения коллектива относительно готовности аудитории принять нестандартные стили игры. Команда ощутила прилив сил. Последние месяцы разработки проекта были наполнены энтузиазмом и твердой уверенностью. В последние недели к нам присоединились менеджеры и тестеры Eidos, чтобы сделать последний рывок. Матрица диска была создана в начале ноября. как раз к Рождеству.
По многим параметрам, Thief был типичным проектом. С ним было связано удовольствие работы над крупномасштабной игрой: преодоление трудностей, талантливый коллектив, простор для творчества и неожиданные забавные глюки. У него также было несколько стандартных проблем: недооценка сложностей, приступы апатии, необходимость срочно создать демо, нереалистичные планы, выдающие желаемое за действительное, проблемы с документацией и неопределенности в ТЗ.
Однако Thief также во многом отличался от других проектов тем, что он принял на себя большой риск того, что наши усилия не будут оценены по достоинству. Мы хотели раздвинуть рамки почти в каждом элементе кода или дизайна. Экспериментальная сущность этой игры, и время, которое нам потребовалось для того, чтобы осознать эту сущность, наложило особые требования на процесс разработки. Команда, работавшая над проектом, была больше любой другой из предыдущих проектов, и иногда проект оказывался "у семи нянек". Привести видение игры каждого к общему знаменателю заняло гораздо больше времени, чем ожидалось. Стремление создать хороший и практичный движок для игры обычно выливается в то, что он не всегда оказывается готов в сроки показ демо-версий. Множество опасностей поглотило бы проект, если бы не преданность, креативность и самопожертвование коллектива.
За время разработки над проектом поработало более 50 людей: кто-то из проекта "Camelot", кто-то из аудио-видео отделов Looking Glass, кто-то помогал по возможности, работая параллельно над другими проектами. Костяк команды составляли ветераны предыдущих проектов Looking Glass (Underworld I и II, System Shock, Flight Unlimited, Terra Nova, British Open Championship Golf, и не вышедший Star Trek: Voyager), а также несколько новичков. Над проектом работали люди с большим талантом и твердыми убеждениями. Хотя коллективу потребовалось некоторое время, чтобы превратиться в ударную креативную силу, последние 6 месяцев были невероятно продуктивными, инициативными и бесстыдно веселыми.
Что было хорошо
1. Создание инструментов, управляемых данными. Опыт создания предыдущих тайтлов показал, что одно из препятствий своевременному выходу игры - зависимость художников, дизайнеров и программистов друг от друга на каждом этапе работы. Одной из целей в ТЗ на Dark Engine - движке, на котором построен Thief - было создание набора инструментов, который позволял бы программистам, художникам и дизайнерам работать эффективно и независимо. Усилия были сконцентрированы на том, чтобы сделать игру управляемой в основном данными и дать непрограммистам высокую степень контроля над внесением в игру результатов их работы. Нужно было обеспечить возможность вносить в игру элементы дизайна и скрипты непосредственно их создателями, без необходимости подключать к этому процессу программистов.
Система Dark Object составляла основу нашей стратегии. Первоначально созданная программистом Марком ЛеБланком (Marc "Mahk" LeBlanc), система объектов была основной базой данных для управления отдельными объектами при моделировании. Она задавала основные свойства, которыми может обладать объект, и взаимодействия, которые могут происходить между двумя объектами. Это позволило легко создавать для внутриигровых систем новые типы свойств и взаимодействий, и позволила автоматизировать процесс сохранения, загрузки, синхронизации версий и редактирования свойств и взаимодействий. Программисты устанавливали доступные свойства и типы взаимодействий, и интерфейс для редактирования, используя набор простых классов и структур. Используя инструменты с графическим интерфейсом, дизайнеры устанавливали иерархию и структуру объектов независимо от программистов. В Thief полностью отсутствует иерархия объектов, заданная программным кодом.
Хотя внедрение системы потребовало гораздо больше работы, чем мы ожидали, и организация объектной иерархии потребовала огромных усилий со стороны ведущего дизайнера Тима Стеллмака (Tim Stellmach), она оказалась одной из лучших достижений проекта. Как только сформировался набор свойств и взаимодействий, сделанный программистами, система объектов позволила дизайнерам создать бОльшую часть поведения объектов, без использования скриптом и вмешательства программистов. Кроме того, та легкость, с которой можно было сделать переменные доступными для изменения и настройки игры, позволила программистам основательно расширить возможности дизайнеров.
Вторым главным компонентом нашей стратегии была наша система управления ресурсами. Система управления ресурсами позволила вести высокоуровневый контроль над исходным материалом, таким как текстуры, модели и цифровые звуки. Это позволило распределять использование памяти игрой, и добавило функции передачи данных, необходимые для управления конфигурациями.
Предыдущая система управления ресурсами в Looking Glass имела схожую функциональность, но идентифицировала ресурсы по цифровому индексу и требовала отдельной операции компиляции ресурсов. Эта технология часто требовала рекомпиляции программных файлов игры, чтобы внести новые текстуры, и требовала, чтобы команда выключала игру, когда в сеть помещаются новые ресурсы. Новая система определяла ресурсы по имени файла, без разрешения, использовала иерархическую систему папок, не оставляла открытых файлов при работе и не требовала дополнительной компиляции. Разработчики просто помещали текстуру в нужную локальную папку и начинали с ней работать. Чтобы продемонстрировать текстуру остальным членам команды, Марк Лизотт (Mark Lizotte) просто копировал ее в папку с общим доступом. Также в дополнение к системе управления ресурсами использовались скомпонованные пакеты ресурсов. построенные с использованием стандартного формата .zip. Это позволило использовать стандартные инструменты для создания, сжатия и просмотра файлов ресурсов. В общем, система сильно облегчила разработку, позволив программистам, художникам и дизайнерам добавлять в игру новое содержимое.
Подход, основанный на управлении данными показал себя настолько успешно, что на протяжении всей разработки Thief и System Shock 2 (двух совершенно разных игр) мы использовали одни и те же программные файлы, просто выбирая перед запуском объектную иерархию и набор данных
2. Звук как основа дизайна. Звук играет в Thief более важную роль, чем в любой другой игре, которую я мог бы назвать. Руководитель проекта Грег ЛоПикколо (Greg LoPiccolo) представлял себе Thief как игру с богатым акустическим окружением, где звук не только обогащает окружающую среду, но и является частью геймплея. Коллектив принял и развил эту точку зрения, и особая заслуга в этом принадлежит звукорежиссеру Эрику Бросиусу (Eric Brosius).
Звук как элемент дизайна выполняет в Thief две функции. Во-первых, это основной способ, которым ИИ (персонажи с искусственным интеллектом) сообщают как о своем местоположении, так и о своем состоянии. В Thief мы попытались создать ИИ с большим количеством уровней осведомленности о присутствии игрока вместо обычных двух "ничего не знаю" и "знаю все". Подобное разделение было бы бессмысленным, если бы игрок не мог его воспринимать, поэтому мы создали обширный массив реплик ИИ, чтобы информировать игрока. Это было легко сделать для гуманоидных персонажей, но в случае не-человеческих созданий мы были сильно ограниченны в возможности их самовыражения, и потому многим геймерам не понравились наши "миссии с монстрами".
Во-вторых, система в процессе игры использует звуки, создаваемые объектами, в особенности самим игроком, для информирования ИИ о происходящем. В Thief ИИ редко "читерствуют" в вопросах знания об окружающем мире. Немало усилий было затрачено чтобы построить органы чувств ИИ, позволяющие им принимать решения только на основании сведений о мире, которые они сами получают. Это позволило нам использовать звуки, порождаемые игроком как часть геймплея, и как возможность для игрока неожиданно выдать себя, так и способ привлечь внимание или отвлечь ИИ. Более того, ИИ общались друг с другом преимущественно посредством звука. Речи ИИ и звукам издаваем ими, таким как звон мечей, были присвоены семантические значения. Ввязавшись в драку, игрок мог ожидать, что ближайшие ИИ будут потревожены звуками боя или криками о помощи, и поэтому он вынужден разбираться с противниками как можно тише.
Чтобы звук в игре работал как положено, нам пришлось сделать звуковую систему игры значительно более сложной, чем в других играх. При создании миссии для Thief, дизайнеры построили вторую "базу данных комнат" (room database), которая отражала сообщение между пространствами на более высоком уровне, нежели простая геометрия. Хотя она также использовалась для установки триггеров и оптимизации ИИ, основная роль этой базы была в достаточно простом представлении окружения, позволяющем просчитывать распространение звука в реальном времени через пространства. Без этого было бы невозможно создать звуковую систему, которая позволяла бы игроку и ИИ реалистично слышать звуки, чтобы определять местоположение противников.
3. Фокус, фокус, фокус. В самом начале проект Thief был битком набит фичами и игровыми элементами: множество инструментов в руках игрока и диалоговый интерфейс управления ими. Мультиплеерные режимы: кооперативный, поединок и "укради быстрее" (TheftMatch). Что-то вроде "шестого чувства" игрока. Возможность игрока комбинировать объекты для создания новых инструментов. Ветвления в структуре миссий. От этих и некоторых других "прикольных идей" мы отказались.
Вместо этого, мы сфокусировались на создании игры для одного игрока, линейной, с жесткой последовательностью миссий, и целиком сконцентрированной вокруг стелса, и с инвентарем игрока, построенном по принципу Quake. Идея воплотилась в реальность посредством двух решений, которые мы приняли за семь месяцев до сдачи проекта. Во-первых, проект был переименован в Thief вместо рабочего названия "The Dark Project". Вроде бы малозначительное решение, но оно дало команде твердую идеологию. Во вторых, мы решили заранее отказаться от поддержки мультиплеера, не только из-за опасности не уложиться в сроки, но и для того, чтобы полностью сконцентрироваться на впечатлениях одиночного игрока. В итоге не все миссии получили такую ориентированность на стелс, как мы этого хотели, особенно те, что изначально были созданы для "Dark Camelot", но в общем задачи были выполнены.
 Миссия "Гильдия Воров" — изначально задумывалась
как арена для мультиплеерного TheftMatch?
4. Задания и сложность. Одной из любимых игр коллектива во время работы над Thief была Goldeneye на Nintendo64. Мы были поражены тем, как были построены уровни сложности. На каждом из них были различные задания, некоторые из которых совпадали, и миссии немного изменялись в зависимости от уровня в смысле расположения и количества объектов. Несколько позже при разработке Thief мы решили, что такая система будет неплохо работать и в нашей игре. Расширяя идею, мы принял решение, что по мере увеличения сложности будет уменьшаться уровень толерантности к убийству людей. Мы также позволили игрокам менять уровень сложности в начале каждой миссии. Преимуществ у такой системы было два. Во-первых, игроку было предельно понятно, что означает понятие "сложность". Во-вторых, она позволяла дизайнерам изменять прохождение игры на каждом уровне сложности, без необходимости изменять общую геометрию уровня и структуру миссии. Это позволило сформировать интерес к повторному прохождению, с минимальными затратами при разработке.
5. Множество узкоспециализированных скриптов. Хотя система объектов была весьма гибкой, нам также нужен был скриптовой язык, так что мы создали более точные инструменты для написания скриптов. Наша многоуровневая скриптовая система прекрасно зарекомендовала себя.
Создавая нашу "превосходную" технологию скриптования на уровне объектов, мы хотели дать дизайнерам с небольшими познаниями в программировании возможность легко создавать сложное поведение объектов. Скрипты представляли собой событийно-управляемые объекты, привязанные к игровым объектам, и содержали данные, методы и обработчики сообщений (message handlers). Игра предоставляла набор служб, позволяющих скрипту опрашивать состояние мира, а также выполнять сложные задачи. Нашей целью было создать язык скрипта, позволяющий проводить тестирование на уровне исходного кода (source-level debugging), быстрый и функциональный. Решением оказалось по существу применение С++ в библиотеках DLL, скомпилированных компилятором С++, с применением сочетания классов и препроцессорных макросов для облегчения освоения интерфейса, поддержки динамического подключения и предоставления дизайнерам ясной модели программирования. Хотя он и мог использоваться смыслящими в программировании дизайнерами совместно с программистами, фактически это был настоящий язык программирования, что не позволяло многим пользоваться им.
Многие дизайнеры хотели настраивать поведение ИИ. Для ИИ мы создали более простую систему скриптования, "Псевдо-скрипты" ("Pseudo-scripts"), которые были применены как свойства в Системе Объектов. Псевдо-скрипты сняли с дизайнеров необходимость писать программный код. В ИИ встроено несколько триггеров, например "Я вижу игрока около объекта" или "Я вижу тело". Дизайнер определяет последствия срабатывания триггера. Каждый Псевдо-скрипт редактировался в диалоговом окне, предоставляющим параметры для настройки условия "или" триггера, и пространство для простых, безусловных действий, которые нужно произвести по срабатыванию триггера. Таким образом, поведение ИИ в каждый момент времени было определено набором псевдо-скриптов, закрепленных за данным персонажем. У такого подхода было три преимущества. Во первых, он был достаточно прост и удобен для дизайнера без опыта программирования. Во-вторых, количество триггеров уменьшилось до нормального набора, составленного заранее, вместо бесконечной системы, которая вряд ли смогла бы работать. И, наконец, время и место срабатывания триггеров - потенциальная проблема в прохождении в случае ошибки в построении - могут быть скорректированы программистом.
Последней скриптовой системой, встроенной в Thief, была система Теговых Схем (Tagged Schema system). Когда в игре нужно было воспроизвести звук или анимацию, они запрашивались не напрямую, а в виде шаблонов, измененных опциональными определителями. Например, ИИ, который только что услышал игрока, запрашивает шаблон "средний уровень тревоги", определенный опциональным тегом "+sense:sound" (т.е. определяет, что тревога вызвана звуком). С помощью шаблона совпадений выбирается возможный набор ресурсов. В нашем примере, это будут все стандартные звуки типа "что-то не так", все звуки, выражающие "я слышал что-то странное", а вот звуки, выражающие "Я видел что-то странное", выбраны не будут. Из этого набора выбирается один звук посредством взвешенного случайного выбора. Условия соответствия определяются дизайнерами на простом языке. Указывая таким образом звуки и анимацию, дизайнеры создали множество изменяющихся окружений и моделей поведения без необходимости менять программный код игры.
Что было плохо
1. Проблемы с ИИ. Если и можно назвать причину, по которой геймплей Thief не сходился до самого окончания процесса разработки, то это ИИ. ИИ как помеха игроку является центральным элементом игры Thief, и ИИ, который мы хотели бы получить, не был готов вплоть до весны 1998 г. Как ведущий программист и автор окончательного ИИ, я беру всю ответственность за это на себя.
Оригинальный ИИ для Thief был разработан другим программистом до того, как было определен основной упор на стелс. Через 6 месяцев после начала разработки, проект покинули руководитель проекта и ответственный за игровую систему, а также большая часть программистов была временно переведена на помощь по другой игре, выпуск которой задерживался. В течение следующих месяцев работа над ИИ продолжалась без всякого надзора и привязке к дизайну игры. Вскоре после этого также ушел и программист, работавший над ИИ. Тогда как основные функции поиска пути и алгоритмы были в основном стабильны, код, отвечающий за формирование базы данных поиска пути был полон ошибок. Алгоритмы поиска решения ИИ были заточены под боевую игру, требуя минимального вмешательства со стороны дизайнера, тогда как стелсовая игра требует гораздо более тонкой настройки. Более того, высокоуровневый процесс принятия решения ИИ не был тщательно проработан, и код был весьма нестабильным. В целом ситуация была катастрофической.
Возможно, все эти проблемы и не были бы столь серьезными, если бы не одна ключевая ошибка: я не осознал глубину проблемы достаточно рано, и, несмотря на сомнения, высказанные дизайнером и программистом Дагом Черчем (Doug Church), я действовал недостаточно быстро. Я был высокого мнения о программисте, изначально работавшем над ИИ, и хотел побороть естественное желание программиста все переписать по-своему. Поэтому, я посчитал, что система хоть и содержит ошибки, она в целом стабильна. Спустя несколько месяцев и множество бессонных ночей я понял, что жестоко ошибался.
К ноябрю 1997 года у меня была основа нового дизайна и я начал с ней работать. Но работу пришлось прекратить из-за необходимости выпустить демо к концу декабря, чтобы опровергнуть заявления со стороны, что у команды нет четкого понятия об игре. Это вылилось в выход демки в середине января, за которой последовало демо для издателя, и затем еще одно демо в стиле "дайте что-нибудь, а то всех разгоним". Все это время единственной возможностью было всеми силами прикручивать дополнения к существующему ИИ. Хотя они и сохранили финансирование для нас, эти демо здорово повредили проекту.
В итоге, работа над новым ИИ началась только в середине марта. Несмотря на то, что до сдачи проекта оставалось всего 6 месяцев, мы выбросили четыре пятых существовавшего кода ИИ и взялись за работу. После жуткого двенадцатинедельного периода напряженной работы, ИИ был готов для тестирования. Если бы предыдущей осенью я осознал необходимость переработки на пару месяцев раньше, полагаю, ИИ был бы готов к использованию на 3-5 месяцев раньше.
2. Сомнительный рендерер. Проект начался из-за рендерера, а не наоборот. Основа рендерера Thief была написана в конце 1995 г. как вольный эксперимент программиста Шона Барретта (Sean Barrett).  В течение следующего года рендерер и инструменты редактирования геометрии обрели форму и должны были выйти в свет где-то в 1997 году с "Dark Camelot", и тогда он выглядел весьма привлекательно. Затем, в конце 1996 года Шон решил уйти из Looking Glass. Хотя он периодически общался с нами и дорабатывал некоторые функции, и у нас появилась возможность добавить поддержку аппаратного рендеринга и другие небольшие дополнения, рендереру не уделяли достаточного внимания, чтобы в 1998 году он мог выглядеть современно. Перспектива отсутствия программиста, ответственного за рендерер, порядком угнетала команду. К счастью Шон работал с нами на контрактной основе, а остальные члены команды приобрели достаточные знания о рендерере, чтобы успешно завершить разработку. В итоге, в продажу пошел рендерер, подходящий для геймплея, но не столь привлекательный, как у остальных выдающихся игр от первого лица.
Может возникнуть вопрос, а почему мы просто не воспользовались сторонним рендерером. Когда проект стартовал в 1996 году, волна соглашений по использованию движка Quake еще не началась, а до выхода Unreal было еще два года. К тому времени, когда такой договор стал бы подходящим выбором, игра и рендерер оказались слишком привязаны друг к другу, чтобы что-то менять.
3. Потери ключевых фигур из персонала помимо нашей воли. В середине 1997 года Thief только начал разгоняться. Команда была полной и стелс-ориентированность действительно начала проявляться. К сожалению, финансовое положение Looking Glass было весьма безрадостным. Мало что может сравниться с чувством неизвестности, когда идешь на работу и гадаешь, кого уволят, и ты не исключение из списка претендентов, или ты придешь уже к закрытым дверям. За шесть месяцем компания потеряла половину своих сотрудников, и, хотя коллективы старались сосредоточиться на работе, это было нелегко, когда в один день исчезали растения, в другой кофеварка, а потом и бачок с питьевой водой.
Многие из команды Thief не смогли работать в таких условиях. Мы потеряли двоих программистов, включая бывшего ведущего программиста, и дизайнера. Когда нам пришлось закрыть наш офис в Остине, мы потеряли продюсера, Уоррена Спектора (Warren Spector), а также многих программистов, кто внес большой вклад в разработку нашего движка. Все они собрались в компании Ion Storm и работают над Deus Ex. Хотя потребовалось несколько месяцев на то, чтобы восстановить дух оставшихся в команде, мы сплотились и компания вернулась к жизни. Возможно, терпения прибавлялось от осознания того, что как бы ни было плохо, ты видел и худшее.
4. Недооценка важности редактора. Один из нарывов, что не был вскрыт, был наш редактор, Dromed. Хотя он был достаточно мощным и предоставлял достаточную функциональность для выпуска игры, Dromed был плохо документирован и иногда был откровенно недружелюбным. Изначально Dromed был создан для демонстрации, когда платформой для игры планировалась DOS. Так как это было демо, он не учитывал опыт дизайнеров и их пожелания. Как и любое DOS-приложение, ему не хватало цельного и легкого в использовании интерфейса, как в Windows. Нашей ранней ошибкой была недооценка важности редактора, и затем мы просто преобразовали его на основе опыта построения демо-редактора. Нам стоило сделать нормальный каркас редактора и пригласить специалиста по созданию интерфейса в Windows, который мог бы осуществлять поддержку во время разработки. Оглядываясь назад, могу сказать, что время, потраченное на доводку редактора, было бы не лишним в конце проекта.
5. Неадекватное планирование. Хотя говорить, что графики и бюджетное планирование было совершенно неадекватным, уже стало клише в программной индустрии, Thief очень сильно пострадал от этой болезни. Было несколько элементов, сделавших планы несоответствующими.
Во время "Dark Camelot" и в первую половину работы над Thief мы набирали команду до того, как определились с дизайном и технологией. В Thief это привело к стремлению завершить работы по дизайну, тогда как направление дизайна и технологий не было определено. Из-за нечетких ТЗ на программный код и дизайн миссий, мы оказались в ситуации, когда было сделано много содержимого, которое не подходило создаваемой нами для игры. Был написан код и построены уровни, которые не отвечали целям проекта.
Что еще хуже, нам не удалось произвести переоценку планов, когда сроки перестали выполняться. Будучи зажатыми нереальными планами, мы не оставили себе времени для экспериментов, согласований и макетирования, которые нужны в проектах типа Thief. Позднее зимой 1998 года многие из ошибок планирования были исправлены. Но все же, в оставшееся время, из-за наследия наших ранних ошибок нам приходилось удалять миссии, которые были рассчитаны на технологию, которой у нас не было, и перерабатывать миссии, не рассчитанные на основной геймплей.
Оглядывая проект в целом
Thief был построен как конструктор из абстрактных компонентов, позволяющий создать игры, богатые объектами и управляемые данными. Хотя это и увеличило стоимость разработки, такой подход позволил Looking Glass использовать технологии для совершенно разных типов игр, от System Shock 2 до симулятора Flight Combat. В наших следующих проектах некоторые системы, например, ИИ и Система объектов, будет доработана, но не переписана с нуля. Мы планируем продолжить разработку будущих игр в таком ключе.
В следующий раз, подход к построению движка будет отличаться. Для движка будут созданы отдельные планы, выделены средства, набран персонал. К редактору будут относиться как к VIP-персоне в отличие от первого Thief. Наконец, разработка контента не будет подгоняться, пока технология не будет достаточно стабильна для цельного процесса разработки дизайна.
Да, планы у нас будут нормальными — правда-правда.
|
|
|
|
