Однако эта тенденция проявится лишь через год, потому что разработчикам ПО давали прототипы новых компьютеров для работы задолго до того, как выпустить их в продажу. Так что я возился со своим 3D-движком и фантазировал о том, какие игры мы когда-нибудь сможем на нем делать, пока вся остальная команда в других комнатах офиса продолжала работать с зарекомендовавшими себя платформами.
Один из находившихся тогда в работе проектов для Commodore назывался Gunship, его создателями были Энди Холлис и наш новый дизайнер графики Арнольд Хендрик. Gunship в существенной степени был вдохновлен ролевыми играми, для которых требовались лишь ручка и бумага: именно такие игры Арнольд создавал в начале своей карьеры. Помимо прочего, Gunship унаследовал от них довольно радикальную идею «перманентной смерти». У игрока была возможность сохранять свой прогресс и продолжать набирать победы, загрузившись с сейва в любое удобное время, но в случае провала миссии в Gunship нельзя было восстановить игру на месте последнего сохранения. Если вы умирали, то вы умирали. Некоторые, правда, умудрялись спастись, быстро вытаскивая дискету из дисковода до того, как компьютер успевал перезаписать данные на ней. Среди прочих необычных особенностей игры можно отметить возможность давать имя своему персонажу и набирать вооружение вертолета, не выходя при этом за пределы требования по максимально допустимой нагрузке: схожим образом в традиционных ролевых играх распределяются очки навыков. Волшебник 20-го уровня в «Подземельях и драконах» (Dungeons & Dragons) мог убежать с поля битвы или проспать всю ночь в таверне, чтобы восполнить показатели; в Gunship же пилот вертолета мог переждать миссию, взяв больничный, или передохнуть вне базы. Подобные приемы в поведении персонажа оттачивались на протяжении более десяти лет ветеранами настольных игр, и Gunship стал одним из первых примеров удачного перенесения их в цифровую вселенную.
Интересно еще и то, что игроки сами могли выбирать, управлять посадкой самостоятельно или выполнить ее на автопилоте, – на этот раз мы не забыли описать этот процесс в руководстве пользователя.
Но в то время как механика игры ломала сложившиеся представления о разработке игр, механика полета в ней просто ломалась без посторонней помощи. Мы понимали, что на незнакомой территории у игроков наверняка возникнут проблемы, ведь это был один из первых вертолетных симуляторов, появившихся на рынке. Мы старались сделать процесс обучения максимально простым, придумав для этого разноцветную рамку с напоминаниями – накладную клавиатуру, давно забытый пережиток прошлого в современном мире эргономичных внешних устройств, которые уже и сами не толще картона. Однако наши плейтестеры уверяли нас, что джойстик управления вертолетом был известен игрокам и в достаточной степени интуитивно понятен. Основной проблемой, по их словам, была скорость.
Вертолеты хоть и летали медленнее, чем их крылатые собратья, но обладали большей маневренностью при разворотах, а для разработчика, пишущего код игры, поворачивать окружающий пейзаж труднее, чем приближать его по горизонтали. Самолету потребовалось бы несколько секунд для поворота из одного положения в другое, а вот вертолет мог резко поворачиваться и даже кружиться на месте, а значит, нам нужно было рендерить 360 градусов окружающего пейзажа в трехмерной дуге быстрее, чем когда-либо раньше.
Я предложил свой 3D-движок, и команда с радостью согласилась, хотя для его использования и требовалось полностью переделать весь базовый код. Commodore 64 уступал в мощности Amigа, на котором я сделал свой движок, но даже на менее мощном компьютере все работало намного эффективнее, чем раньше. На протяжении нескольких месяцев мы с Энди Холлисом меняли код и пытались заставить старый компьютер работать как новый.
Все сводилось к частоте кадров (то есть сколько раз компьютер успевал отрисовать экран за секунду). Изменение одной крошечной детали на переднем плане, например стрелки высотомера, компьютером обсчитывалось быстро. Но изменение всего заднего фона приводило к тому, что смена изображения на экране начинала значительно тормозить.
Мы решили отследить частоту кадров в наших играх, и она оказалась не очень-то высокой. Даже первоначальная версия моей игры по вселенной «Звездный путь» на серверах General Instruments работала с той же скоростью, хотя по сложности перемещение текста было, конечно же, несравнимо с поворотом склона горы. Другие игры, сделанные нами в MicroProse, шли с большей частотой, но минимально допустимой оказалась частота 4 кадра в секунду. С более низкой частотой игры становились неиграбельными.
В Gunman у нас была частота 3 кадра в секунду.
«Мне нужно провести еще один цикл оптимизации, – стенал Энди поздними вечерами и умолял меня найти какую-нибудь вычислительную операцию, которую не обязательно было выполнять, или фрагмент данных, которые не обязательно было хранить в определенный момент игрового времени. – Я уверен, ты сможешь еще что-нибудь придумать!»
Мы и так уже сильно отставали от графика из-за смены движка, и если бы проблемы со скоростью не получилось решить в кратчайшие сроки, нам пришлось бы начать вышвыривать куски игры как балласт с воздушного шара, чтобы оставшаяся масса могла оставаться в воздухе.
К счастью, у нас все получилось: игра вышла тиражом 250 тысяч копий и завоевала награду «Экшн-игра года», присуждаемую журналом Computer Gaming World. Я хотел бы описать здесь методы, которые мы использовали для достижения результата, но для этого пришлось бы приводить длинные, сложные и, как меня заверили, скучные математические выкладки. Отмечу лишь, что нам помогло не какое-то одно гениальное прозрение, а десятки небольших изменений, многие из которых придумали вовсе не мы. Нам пришлось придумывать, как делать свою работу более качественно, но, помимо этого, мы пользовались плодами деятельности тех, кто уже делал что-то лучше нас: новыми технологиями, новыми алгоритмами сжатия данных, новыми методами внедрения стандартных подпрограмм. Создание игр – коллективный труд, и смешно думать, что кто-то один может взять на себя все регалии. Как показал мой первый опыт участия в Международной выставке потребительской электроники в Лас-Вегасе, наша отрасль состояла не из одного неподражаемого монолитного стенда, а из тысяч стендов-малышей: возможно, у некоторых из них не нашлось одинаковых столов, но каждый вносил свой вклад в общее дело.
Единственным местом, где я чувствовал некую смутную причастность к профессиональному сообществу сильнее, чем на выставке, была Computer Game Developers Conference (CGDC, Конференция разработчиков компьютерных игр). Меня не было на первой конференции, основанной гейм-дизайнером Крисом Кроуфордом, который на тот момент был известен в профессиональном сообществе главным образом по игре Balance of Power и по книге The Art of Computer Game Design («Искусство разработки компьютерных игр»). Мероприятие проходило дома у Криса, где 27 участников заседали на полу в его гостиной. Но уже на втором собрании, прошедшем через шесть месяцев после первого, я присутствовал лично: дело было в гостинице Holiday Inn в пригороде Сан-Хосе в сентябре 1988 года. Количество участников выросло в пять раз, и на конференции даже угощали едой, хотя присутствующим и приходилось есть стоя и брать по две бумажные тарелки, чтобы ничего не расплескать. Плата за участие носила символический характер, и в какой-то момент организаторам пришлось бежать в банк с набранными на входе деньгами, чтобы чек, которым они расплатились с отелем, не отклонили. Я почти уверен, что именно в том году Крис впервые стал облачаться в специальные костюмы для своей вступительной речи. В ходе одной из своих речей он щелкнул перед нами кнутом, изображая силу подсознательных творческих устремлений; в другой год он выдал полное страсти театральное представление, в котором сравнил разработчиков игр с Дон Кихотом: в конце выступления он схватил тяжелый металлический меч и понесся с ним по аудитории.