Десять советов для продуктивного прототипирования
Все знают, что своевременное создание прототипов – важное условие качественной разработки игр. Вот несколько советов, которые помогут вам создать самые лучшие и самые полезные опытные образцы вашей игры.
Совет 1: Ответьте на вопрос
Каждый прототип создается для того, чтобы получить ответ на вопрос или на несколько вопросов. Вы должны научиться четко формулировать вопрос. В противном случае вы рискуете не сэкономить время, как изначально планировалось, а потерять его. Вот некоторые примеры вопросов, на которые может отвечать прототип:
• Сколько анимированных персонажей может поддержать ваша технология?
• Увлекателен ли основной гейм-плей? Как долго он может оставаться увлекательным?
• Насколько хорошо персонажи и окружающий мир сочетаются в эстетическом плане?
• Насколько большими должны быть уровни?
Не поддавайтесь соблазну создавать свой прототип заново и сконцентрируйтесь на том, чтобы он отвечал на основные вопросы.
Совет 2: Забудьте о качестве
Разработчики всех мастей имеют одну общую черту: они гордятся своим ремеслом. Поэтому большинству из них претит даже мысль о создании прототипа «на скорую руку». Художники потратят слишком много времени на наброски сырого концепта, а программисты слишком долго будут делать из этого более-менее качественную игру. В работе над прототипом имеет значение только одно – отвечает ли он на вопрос. Чем быстрее прототип ответит на вопрос, тем лучше – даже если он лишь наполовину рабочий и выглядит угловато. Шлифование прототипа может ухудшить положение вещей. Плейтестеры (и коллеги) скорее укажут на недостатки опытного образца, который выглядит как черновик, чем на проблемы того, который выглядит как готовая игра. Отшлифованный прототип может скрыть настоящие проблемы за привлекательной внешней оболочкой.
Здесь вам нужно забыть о Правиле цикла. Чем быстрее вы сделаете отвечающий на ваш вопрос прототип, тем лучше, и неважно, как плохо он выглядит.
Совет 3: Никаких привязанностей
В книге «Мифический человеко-месяц, или Как создаются программные системы» (The Mythical Man-Month) Фред Брукс впервые употребляет свое знаменитое выражение «Отпускайте легко, так как это неизбежно». Этим он хотел сказать, что нравится вам это или нет, но первая версия вашего проекта – это не конечный продукт, а прототип, от которого впоследствии придется отказаться и создать «правильно» работающую систему. Но по правде, «отпустить», возможно, придется много прототипов. Для разработчиков с небольшим опытом такое дается непросто – они воспринимают это как провал. Создавая опытный образец, убедите себя в том, что прототип – временное явление и его жизненный цикл заканчивается в тот самый момент, когда вы получаете ответ на свой вопрос. Смотрите на каждый прототип как на возможность чему-то научиться – потренироваться перед созданием «настоящей» игры. Конечно, отказываться от всего не нужно – собирайте работающие «кусочки», чтобы впоследствии слепить из них что-то действительно стоящее. Иногда это больно. Дизайнер Николь Эппс сказала следующее: «Это как зарезать собственное дитя, но этому нужно научиться».
Совет 4: Расположите прототипы в порядке их важности
В процессе формирования списка рисков вы можете прийти к выводу, что нужно несколько прототипов для оптимизации всех возможных рисков. Разумнее всего будет разместить их в порядке важности, так чтобы в первую очередь справиться с самыми приоритетными из них. Также принимайте во внимание зависимости: если результаты одного прототипа в перспективе могут нивелировать значение другого, то первый определенно является самым важным.
Совет 5: Совмещайте прототипы эффективно
Отличный способ задействовать больше циклов – делать по несколько штук одновременно. Пока программисты работают над прототипом, отвечающим на вопросы по технологии, художники могут создавать графические прототипы, а геймдизайнеры – прототипы гейм-плея. Чем больше различных прототипов вы имеете на руках – тем быстрее получите ответы на большее число поставленных вопросов.
Совет 6: Они не должны быть цифровыми
Ваша цель – пройти максимальное количество циклов с максимальной эффективностью. Почему бы нам на время не отказаться от использования ПО? Немного смекалки, и вы сможете создать настольную версию вашей видеоигры, или, как ее еще называют, бумажный прототип. Зачем нам это? Ради экономии времени. Настольная игра спроецирует основные черты гейм-плея, но на ее создание вы потратите гораздо меньше времени. Основной целью создания прототипов являются поиск, обнаружение и устранение проблем, и бумажные прототипы помогут сэкономить время и раньше добиться результатов. Особенно к месту они будут, если ваша игра – пошаговая. Прототипом пошаговой системы боя для Toontown Online стала очень простая настольная игра, позволившая тщательно сбалансировать многие виды атак и комбо-ударов. Мы отслеживали очки на бумаге или на доске и играли снова и снова, добавляя новые правила и убирая ненужные до тех пор, пока игра не стала сбалансированной.
Даже онлайн-игры в реальном времени можно представить в виде бумажного прототипа. Из некоторых также можно сделать пошаговые версии, способные передать гейм-плей. В иных случаях можно сымитировать игру в реальном времени или нечто похожее на нее. Для этого вам потребуется помощь других людей. Сейчас мы рассмотрим два примера, и вы все поймете.
Tetris: Бумажный прототип
Предположим, вы захотели сделать бумажный прототип «Тетриса». Вырежьте из картона маленькие кусочки и сложите их в кучу. Попросите кого-то разложить их в случайном порядке и постепенно опускать на «доску» (набросок, который вы сделали на листе бумаги), а вы в это время «перехватывайте» фигуры и поворачивайте их в нужном вам направлении. Чтобы заставить собранный ряд исчезнуть, используйте свое воображение или приостановите игру и отрежьте ненужный ряд ножницами. Возможно, это не идеальный «Тетрис», но такой симуляции достаточно для того, чтобы понять, правильные ли формы у ваших фигур и с какой скоростью они должны спускаться. Отличный результат, если учесть, что вы потратите на бумажную симуляцию не больше 15 минут.
Halo: Бумажный прототип
Можно ли создать бумажный прототип шутера от первого лица? Конечно! Сначала найдите помощников и разделите их на тех, кто играет за компьютерных персонажей и за других игроков. На большом листе миллиметровки нарисуйте карту и расставьте по ней фишки, которые будут вашими игроками и монстрами. Каждым виртуальным персонажем должен управлять отдельный человек. Далее можно придумать некое подобие пошаговых правил для вашей игры или воспользоваться метрономом. Программу-метроном можно легко найти в интернете. Настройте частоту ударов метронома на 5 секунд и введите правило, согласно которому персонаж делает шаг вперед на одну клетку после каждого удара. Когда на прицеле появляется враг, вы можете в него выстрелить, но только с расчетом один выстрел на один удар метронома. Это даст вам отличную возможность посмотреть на вашу игру в замедленном действии: вы сможете оценить плюсы и минусы, не переставая при этом играть. Вы сможете понять, насколько большой должна быть ваша карта; какой должна быть форма комнат и коридоров, в которых игроку было бы интересно бегать; какими свойствами должно обладать оружие, и многое другое – и для всего этого вам понадобится совсем немного времени.
Совет 7: Прототип не должен быть интерактивным
Ваши прототипы не обязаны быть цифровыми; они даже не обязаны быть интерактивными. Простых скетчей и анимаций может быть более чем достаточно для ответов на часть вопросов по гейм-плею. Ранние прототипы игры «Принц Персии: Пески времени» (Prince of Persia: Sands of Time) с ее инновационными механиками прыжков и перемотки времени были сделаны в виде неинтерактивных анимаций, демонстрирующих всевозможные акробатические трюки. В результате у команды была возможность быстро проверить, как будут выглядеть их идеи, и обсудить, как лучше сделать раскрывающую потенциал этих идей интерактивную систему.
Совет 8: Выберите легко редактируемый игровой движок
Традиционный метод разработки ПО чем-то напоминает выпекание хлеба.
1. Написание кода.
2. Компиляция и компоновка.
3. Запуск игры.
4. Поиск в игре той части, которую нужно протестировать.
5. Тестирование.
6. Возврат к шагу 1.
Если вам не понравился хлеб (результаты тестирования), все, что вы можете сделать, – запустить процесс по новой. Это отнимет чересчур много времени, особенно при работе над крупным проектом. Но, выбрав движок с правильной системой скриптов, вы сможете вносить изменения в код, когда игра все еще запущена. Это больше напоминает работу с глиной – вы можете все время что-то менять.
1. Запуск игры.
2. Поиск в игре той части, которую нужно протестировать.
3. Тестирование.
4. Написание кода.
5. Возврат к шагу 3.
Меняя код запущенной игры, вы ускоряете весь процесс и проходите больше циклов в день, что, в свою очередь, повышает качество вашей игры. Раньше я использовал Scheme, Smalltalk и Python, но в целом подойдут любые языки программирования высокого уровня. Связать все воедино поможет Javascript. Если вы боитесь, что эти языки медленно запускаются, помните, что игры можно писать на нескольких языках одновременно: напишите второстепенный контент, который не нужно будет сильно изменять, на чем-то быстром и статическом (Ассемблер, C++ и т. д.), а для написания более важного контента используйте медленный, но динамичный язык. Это может потребовать дополнительных усилий, но оно того стоит, так как у вас появляется возможность воспользоваться преимуществами Правила цикла.
Совет 9: Сначала делайте игрушку
Вернемся к главе 4, в которой мы обсуждали отличия игры от игрушки. В игрушки весело играть просто потому, что они интересны сами по себе. В играх есть цель, и они позволяют пользователю приобрести гораздо более глубокий опыт, основанный на процессе решения проблем. Тем не менее не стоит забывать, что многие игры были созданы на основе игрушек. Мяч – это игрушка, но бейсбол – это игра. Маленькая фигурка, которая бегает и прыгает, – это игрушка, а Donkey Kong – игра. Вы должны убедиться, что с вашей игрушкой весело играть, до того как вы приступите к процессу создания игры вокруг нее. Может оказаться так, что, сделав игрушку, вы с удивлением откроете для себя новые аспекты ее привлекательности и сгенерируете десяток подходящих идей.
Геймдизайнер Дэвид Джонс признается, что для создания игры Lemmings его команда воспользовалась именно этим методом. Они просто подумали, что будет интересно создать маленький мир с толпами маленьких созданий, которые ходят туда-сюда и занимаются своими делами. У них не было четкого видения игры, но идея такого мира звучала интересно, поэтому они взялись за ее воплощение. Как только у них появилась «игрушка», начались серьезные обсуждения того, какую игру можно создать вокруг нее. Джонс говорит, что в случае с Grand Theft Auto все было так же: «GTA не делали как GTA. GTA делали как средство. Задача была – построить живой полноценный город, в котором было бы интересно играть». Как только удалось разработать «средство» и команда убедилась, что это действительно хорошая игрушка, нужно было решить, какую игру из нее можно сделать. Им показалось, что город похож на лабиринт, поэтому они решили взять механику лабиринта из достаточно надежного, на их взгляд, источника. Джонс продолжает: «GTA произошла от Pac-Man. Точки – это маленькие люди. Вот я еду в своей маленькой желтой машинке. А привидения – это полицейские».
Сделав сначала игрушку, а уж потом приступив к созданию игры, вы сможете радикально изменить качество вашего проекта в лучшую сторону, потому что на выходе вы получите фан сразу по двум аспектам. Но если ваш гейм-плей создан на основе самых интересных частей игрушки, вы сможете добиться того, что эти два аспекта будут дополнять друг друга в наивысшей степени. Геймдизайнеры часто забывают об этом ракурсе. Чтобы не повторять их ошибок, ознакомьтесь с призмой 17.
Призма 17: Призма игрушки
Чтобы воспользоваться этой призмой, думайте не о том, насколько интересно играть в вашу игру, а о том, насколько интересно играть с ней. Спросите себя:
• Если бы в моей игре не было цели, была бы она такой же интересной? Если нет, как я могу это изменить?
• Возникает ли у людей желание поиграть в мою игру еще до того, как они поймут, что им нужно будет делать? Если нет – как я могу это изменить?
Есть два способа использовать Призму игрушки. Первый способ: применить ее к уже существующей игре с целью понять, можно ли придать ей больше «игрушечных» качеств, – иными словами, как ее можно сделать более понятной и «приятной в обращении». Но если быть достаточно смелым и пойти по второму пути, можно изобрести абсолютно новую игрушку еще до того, как вы решите, какую игру будете создавать на ее основе. Реализовывать подобное в сжатые сроки – рискованно, но, если вы располагаете временем, эта призма может стать вашей персональной «волшебной палочкой», открывающей для вас чудесный мир перспективных идей.
Совет 10: Хватайтесь за возможность повторить цикл
Иногда в процессе разработки могут измениться условия, и это дает больше времени на доработку игры. В игровой индустрии бывали случаи, когда игра добивалась успеха благодаря тому, что у разработчиков внезапно появлялась возможность провести новые эксперименты с игрой. Например, Halo изначально разрабатывалась для Macintosh. Но позже компания-разработчик заключила контракт с Microsoft и игру стали портировать на ПК. Команда воспользовалась этим, чтобы доработать продукт. Второй такой шанс компания получила, когда Microsoft попросили их портировать игру с ПК на Xbox! Дополнительного времени хватило не только на то, чтобы внести все необходимые технические изменения, но также и на доработки гейм-плея. Дизайнеры здраво распорядились временем изначально не запланированных итераций, и это позволило им значительно повысить качество игры.
