Игры делать — не игрушки!

Название: Эндрю Роллингз, Дэйв Моррис «Архитектура и проектирование игр»

Издательство: Издательский дом «Вильямс». Москва — Санкт-Петербург — Киев, 2006.

Эту книгу — как минимум, отдельные главы — хочется раздергать на цитаты, а цитаты — озвучить голосами постоянных авторов журнала. Но не все, а только некоторые. Еще ряд цитат хочется высечь на скрижалях и поместить в офисах компаний, производящих игры. Причем часть разработчиков должна эти скрижали затащить туда без помощи лифта, чтобы запомнилось.

Кому адресована эта книга? Я затрудняюсь назвать людей, принимающих участие в разработке игры, которым не стоило бы ее читать: издатели, и менеджеры, архитекторы и программисты, тестеры, музыканты и художники — каждый найдет что-то для себя.

Через всю книгу красной нитью проходит несколько идей. Часть из них — например, идея применения в разработке игр тех же методов, которые применяются при написании банальных приложений с базами данных — может вызвать удивление и отторжение. Идеи о повторном использовании кода и экономии времени за счет хорошего документирования кода — вздох сожаления: плюсы этой идеи понятны и очевидны, а вот в жизнь они воплощаются с большим трудом. Но в любом случае прислушаться к авторам стоит, даже если вы сочтете их жуткими занудами.

Age of Empires, похоже, одна из любимых игр авторов.

Перейдем непосредственно к рассказу о книге. Начнем с конца. В конце книги расположен не только предметный указатель, без которого при таком объеме очень тяжело, но и словари — глоссарий и англо- русский. Рекомендую сразу сделать закладку в районе глоссария и периодически к нему обращаться.

А теперь — по порядку. Порядок глав соответствует идеальной с точки зрения авторов последовательности действий при написании игры. Итак, глава первая — концепция. Итогом чтения этой главы должен стать манифест объемом 5-6 страниц, описывающий авторское понимание игры. В дальнейших главах первой части он будет детализироваться, пока не вырастет в полноценную проектную документацию. Да-да, в актуальную документацию, сколь бы фантастичным это не казалось.

Это цитата: в основе любой игры лежит мечта. Игра начинает создаваться с момента возникновения идеи в голове у автора.

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

После полета творчества приходится приземляться и смотреть уже сначала взглядом критика, а потом — еще и разбираться, не подрежут ли крылья программисты. Но уже есть предмет для разговора с издателями.

От манифеста мы переходим к эскизному проекту. Среди примеров этой главы — Baldur’s Gate и Grim Fandango, Dungeon Keeper, Warrior Kings и другие игры.

Это цитата: хорошая игра — это игра, в которую вы можете выиграть, используя неожиданные вещи и заставляя их работать.

Итак, что должно быть в эскизном проекте? Авторы называют 5 основных разделов:

Игровые возможности, точнее, отличия от других игр. Геймплей — хотя хорошая игра, по мнению авторов, без геймплея возможна, это скорее исключение. Интерфейс, который должен помогать игроку, а не украшать игру. Правила, которые должны служить игровым возможностям и устранять нежелательные, с точки зрения авторов, особенности. Проектирование уровней, которые в хорошей игре должны оставлять за игроком свободу действий при решении задач.

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

Геймплей описан во второй главе очень кратко. И это не случайно — ему и интерактивности вообще посвящена вся третья глава. При этом интерактивность авторы справедливо ставят куда выше геймплея.

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

Это цитата: игра — последовательность интересных вариантов выбора. Сид Мейер, между прочим...

Итак, у игрока должен быть выбор. От выбора может зависеть исход игры, пусть даже ошибку можно исправить. Или же можно просто принять решение и посмотреть, к чему оно приведет по законам игрового мира — например, выбор самой красивой из десятка одинаковых по функциональности ламп, как в The Sims. Но если часть вариантов бессмысленна или явно не выгодна для игрока, если только он не стремится преодолевать трудности, — значит, часть работы сделана зря и зря потрачены деньги и время разработчиков. Поэтому на каждое достоинство должен находиться недостаток: высокая цена, низкая маневренность, исчезновение через короткое время — в зависимости от конкретной игры.

Следующая глава посвящена созданию полной документации проектировщика. Ее я пропущу и перейду к пятой главе, посвященной достижению баланса.

Мы ждем, что игроки будут в равных условиях, пока не сделают разных ошибок, что достигнутые цели будут адекватны затраченным усилиям, а, скажем, самое сильное заклинание не будет доступно на первом уровне. Чтобы понять, как достигается баланс, авторы используют знакомую всем нам с детства игру «Камень-ножницы-бумага». А чтобы объяснить, как баланс рассчитывать, привлекают аппарат теории игр.

Это цитата: исход игры не должен определяться факторами, которые не контролируются игроком.

Dungeon Keeper — кладезь удачных решений.

Самый очевидный метод обеспечения баланса — симметрия. И лучше, если одинаковые возможности достигаются по-разному — скажем, фланг одного участника противостояния защищен морем, а другого — непреодолимыми горами. Гораздо лучше (но и гораздо реже — мне приходят в голову только Vga Planets и ряд космических стратегий), если возможности сторон — а следовательно, и тактика — принципиально разные, но при этом шансы равны.

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

Это — авторский пример: то, что в Might&Magic II глобальная катастрофа магического мира оказывается следствием того, что барахлит компьютер, управляющий планетой, — совершенно неадекватная развязка.

Не буду пересказывать седьмую главу, название которой покажется вам знакомым — «Советы мастеров». Скажу только, что она сделана в форме интервью с разработчиками ряда игр, уже ставших классическими.

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

Про вторую часть (главы с 9 по 15) я скажу достаточно мало. Она посвящена в основном описанию правильной организации процесса — найму правильных людей (и содержит достаточно забавную и полезную классификацию людей, для проекта в целом опасных), правильной организации производственного цикла и ряду других аспектов.

Основная мысль этой части книги, с которой я полностью согласен, — что с точки зрения организации разработки, несмотря на более привлекательный результат, производство игр почти не отличается от организации написаний скучных приложений, опирающихся, скажем, на базы данных. И проблемы при разработке игр возникают те же самые, что в более скучных проектах. Решения возникших проблем должны быть применимы более чем в одном проекте. Один и тот же код должен писаться один раз, а не каждый раз заново, и при этом быть понятным каждому. Технические задания должны быть достаточно строгими, иначе потом придется все переделывать. Программисты не должны проводить в офисе по 20 часов в сутки, потому что сверхурочные работы до добра все равно не доведут.

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

Я такой организацией не занят и поэтому с наибольшим удовольствием читал авторские примеры. Они достаточно разные по уровню — от модельных историй успеха и провала до реальных примеров из практики. Хотя, надо сказать, стилизация под Конан Дойла в главе 14 — «Дело о глухом менеджере» — меня позабавила. Разве что Перри Мейсон в качестве главного героя был бы более уместен.

Outcast тоже очень часто упоминается на страницах книги.

Третья часть посвящена разработке архитектуры игр, и на ней я остановлюсь несколько подробнее. На протяжении всей этой части авторы вспоминают о том, как изменилась разработка игр за последние 20 с лишним лет. Увы, проекты перестали умещаться в голове у одного человека. Ура, появились новые замечательные средства для воплощения ваших идей.

Глава 16, с которой она начинается, содержит очень неплохой исторический обзор игрового программирования, описывающий путь от написания игр в машинных кодах для Spectrum до программирования на C++ для любой реально присутствующей на игровом рынке платформы. Замечу в скобках, что C++ — не рекордсмен по накладным расходам, тут все-таки скриптовые языки его опережают — но писать на них куда как проще, и поэтому для, скажем, искусственного интеллекта они применяются гораздо чаще.

Следующая глава посвящена созданию технического проекта — речь идет уже о получении базовых элементов и понятий, характерных для вашей игры, со всеми их характеристиками. Рассказывается это на примере игры Pac-Man, которую видели все мои ровесники, да и большая часть молодого поколения, наверное, тоже. А еще на страницах этой главы мы знакомимся с конечными автоматами.

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

Идеи, использованные при создании Creatures и Creatures 2, были использованы и в ряде бизнес-приложений.

Глава, повествующая о влиянии технологии на архитектуру игры, опирается на историю трехмерных игр — начиная даже не с Elite, а с еще более древней игры Battlezone, когда на экране были видны все ребра всех присутствующих моделей объектов (да-да, невидимые ребра не удалялись). А в современных играх красоты движка, к сожалению, воспринимаются разработчиками как самоценный результат. И причина — в том, что в отличие от баланса и глубины миссий графику не заметить невозможно. Но любые новые для разработчиков технологии нуждаются в исследованиях, и в главе подробно рассказывается о подстерегающих при этом опасностях — свободный полет в никуда или постоянное изобретение велосипеда давно и хорошо знакомы и программистам, и менеджерам. Еще одно проявление развития технологий — уход в никуда ассемблера: у компиляторов теперь получается лучше. Так что, оптимизируя, есть смысл сосредотачиваться на алгоритмах — туда компиляторы пока не дотянулись и дотянутся не скоро.

Из главы 19 можно узнать об использовании шаблонов проектирования. На эту тему написано уже достаточно много книг, и останавливаться на этом сейчас мы не будем. А в следующей главе, помимо прочего, нас ждет шокирующее признание: у всех игр практически одинаковый набор компонентов. И часть из них — вы уже догадались, правда, — можно и нужно использовать повторно, лишь незначительно дорабатывая. И разумеется, документируя способы взаимодействия.

Глава 21 называется «Разработка». Да, это самая важная часть изготовления игры — и подготовке этого этапа была посвящена вся предыдущая часть книги. И проблемы, которые характерны именно для этого этапа, тоже известны. Низкое качество кода. Нечитаемый код — неважно, по глупости ли или в угоду быстродействию. Оптимизация функциональности, которую можно было бы не трогать, вместо реально тормозящего кода. Недостаточное тестирование. И всего этого надо избегать. Тут я не могу не согласиться с авторами: методы, описанные для бизнес-приложений, действительно эффективны и при разработке игр способны существенно улучшить код — а значит, уменьшить проблемы, которые всплывут на этапе тестирования или, что хуже, когда игра уже появится в продаже.

Но вот проект вступает в финальную фазу. Факторы, которые надо оценить на этом этапе, куда менее очевидны. Не сдулся ли как дырявая шина столь перспективный в начале разработки проект? Если нет, то не затмевает ли слишком хорошо смоделированный главный герой все прочие модели? Не изменился ли рынок настолько, что у проекта не осталось никаких шансов? Если же все эти неприятности миновали и есть перспектива издания за границей, то об этом тоже стоит задуматься: например, фразы на разных языках звучат разное время. А сколько глупостей можно сделать при подготовке финальной демо-версии — не счесть! И кто знает, что принесет предрелизное тестирование... Об этом вы узнаете из 22-й главы.

Теория игр

Джон Нэш. Теория игр — раздел математики, изучающий оптимальные стратегии сторон в играх в зависимости от их возможностей. Игрой при этом считают почти что угодно, где есть стороны со своими интересами — так, большинство задач по теории игр, которые приводятся в популярных книгах, берутся из военной практики. Каждый участник разрабатывает с учетом своих ресурсов и ресурсов противников собственную стратегию. Мы можем знать о ресурсах противника все — и тогда, как в случае шахмат, речь идет об игре с полной информацией — или только догадываться, как в покере, — и тогда будем играть в игру с неполной информацией. Мы можем выигрывать ровно столько, сколько противник проигрывает, — скажем, в Heroes of Might & Magic каждый замок, который мы завоевали, отнят у противника, и тогда речь идет об играх с нулевой суммой. В онлайновых играх, договорившись о сотрудничестве, вместе можно получить гораздо больше, чем каждый мог бы достичь по отдельности, — и тогда это игра с ненулевой суммой. Игры с нулевой суммой легче поддаются анализу, и первые работы на эту тему написаны Джоном фон Нейманом и Оскаром Моргенштерном. Теория игр с ненулевой суммой зародилась в начале 1950-х годов, когда свои первые работы на эту тему опубликовал Джон Нэш. За одну из этих работ в 1994 году Джон Нэш удостоился Нобелевской премии по экономике. Многие читатели, я думаю, видели фильм «Игры разума», посвященный Нэшу и получивший четыре Оскара.

Уф! Проект закончен? Нет, всего лишь выпущен релиз. Теперь — самое время понять, что удалось, а чего следует избегать в следующих проектах. И каким он будет, этот следующий проект? Об этом можно прочитать в следующей главе. Пожалуй, несколько беллетристичной по построению.

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

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

Даже и не знаю. Вообще-то в рецензии положено книгу слегка поругать. Эту — не получается, несмотря на некоторую затянутость, проколы переводчика и то, что скриншоты в русской версии не цветные (не знаю, что было в оригинале). Так что покупайте и читайте с удовольствием!