Геймдизайн. Рецепты успеха лучших компьютерных игр от Super Mario и Doom до Assassin’s Creed и дальше - [125]

Шрифт
Интервал

Когда компания-разработчик BioWare создала Mass Effect 3, дизайнеры тестировали существ методом «серого ящика». На раннем этапе разработки гигантский боевой робот представлялся в виде большого куба с двумя длинными прямоугольниками внизу и двумя кубами, прикрепленными к бокам для оружия. Другой враг – высокий желтый блок – хватал героя с длинными желтыми блоками, прикрепленными к бокам. Это выглядит странно, но именно так и происходит. Эти «серые ящики» позволили дизайнерам BioWare тестировать и итерировать свои работы, не вкладывая средства в графику непроверенных проектов.

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

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


Что не нужно тестировать методом «серого ящика»

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

Поэтому чем более аудиовизуально насыщенным является игровой опыт, тем менее полезным становится тестирование методом «серого ящика». Такие игры, как LIMBO и Flower, сильно пострадают в «сером ящике», поскольку в основном они основаны на аудиовизуальных эмоциональных триггерах. Однако этот метод весьма хорошо подходит для Counter-Strike и StarCraft II, так как эти игры всегда были основаны на механике.


Преждевременный продакшн

Всегда остается соблазн «сломать серый ящик» и начать использовать лучшие возможности слишком рано. Я называю это «преждевременный продакшн».

ПРЕЖДЕВРЕМЕННЫЙ ПРОДАКШН – преждевременное добавление дизайнером графики и звука к дизайну «серого ящика» для того, чтобы получить следующий набор контрольных данных.

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

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

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


Навык оценки «серого ящика»

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


Рекомендуем почитать
Изучаем Java EE 7

Java Enterprise Edition (Java EE) остается одной из ведущих технологий и платформ на основе Java. Данная книга представляет собой логичное пошаговое руководство, в котором подробно описаны многие спецификации и эталонные реализации Java EE 7. Работа с ними продемонстрирована на практических примерах. В этом фундаментальном издании также используется новейшая версия инструмента GlassFish, предназначенного для развертывания и администрирования примеров кода. Книга написана ведущим специалистом по обработке запросов на спецификацию Java EE, членом наблюдательного совета организации Java Community Process (JCP)


Pro Git

Разработчику часто требуется много сторонних инструментов, чтобы создавать и поддерживать проект. Система Git — один из таких инструментов и используется для контроля промежуточных версий вашего приложения, позволяя вам исправлять ошибки, откатывать к старой версии, разрабатывать проект в команде и сливать его потом. В книге вы узнаете об основах работы с Git: установка, ключевые команды, gitHub и многое другое.В книге рассматриваются следующие темы:основы Git;ветвление в Git;Git на сервере;распределённый Git;GitHub;инструменты Git;настройка Git;Git и другие системы контроля версий.


Java 7

Рассмотрено все необходимое для разработки, компиляции, отладки и запуска приложений Java. Изложены практические приемы использования как традиционных, так и новейших конструкций объектно-ориентированного языка Java, графической библиотеки классов Swing, расширенной библиотеки Java 2D, работа со звуком, печать, способы русификации программ. Приведено полное описание нововведений Java SE 7: двоичная запись чисел, строковые варианты разветвлений, "ромбовидный оператор", NIO2, новые средства многопоточности и др.


Фундаментальные алгоритмы и структуры данных в Delphi

Книга "Фундаментальные алгоритмы и структуры данных в Delphi" представляет собой уникальное учебное и справочное пособие по наиболее распространенным алгоритмам манипулирования данными, которые зарекомендовали себя как надежные и проверенные многими поколениями программистов. По данным журнала "Delphi Informant" за 2002 год, эта книга была признана сообществом разработчиков прикладных приложений на Delphi как «самая лучшая книга по практическому применению всех версий Delphi».В книге подробно рассматриваются базовые понятия алгоритмов и основополагающие структуры данных, алгоритмы сортировки, поиска, хеширования, синтаксического разбора, сжатия данных, а также многие другие темы, тесно связанные с прикладным программированием.


Питон — модули, пакеты, классы, экземпляры

Python - объектно-ориентированный язык сверхвысокого уровня. Python, в отличии от Java, не требует исключительно объектной ориентированности, но классы в Python так просто изучить и так удобно использовать, что даже новые и неискушенные пользователи быстро переходят на ОО-подход.


Как пасти котов. Наставление для программистов, руководящих другими программистами

«Как пасти котов» – это книга о лидерстве и руководстве, о том, как первое совмещать со вторым. Это, если хотите, словарь трудных случаев управления IT-проектами. Программист подобен кошке, которая гуляет сама по себе. Так уж исторически сложилось. Именно поэтому так непросто быть руководителем команды разработчиков. Даже если вы еще месяц назад были блестящим и дисциплинированным программистом и вдруг оказались в роли менеджера, вряд ли вы знаете, с чего надо начать, какой выбрать стиль руководства, как нанимать и увольнять сотрудников, проводить совещания, добиваться своевременного выполнения задач.