Как сконструировать игровой прототип за 7 дней. Часть 1

 

Части 2-3 | Часть 4

Авторы: Шалин Шодан, Мэтт Кукик, Кайл Грей, Кайл Гэблер

Примечание. Данная статья была написана в октябре 2005-го года, задолго до выхода World of Goo, поэтому не стоит удивляться, что она ни разу не упомянута.

---

 

Вступление

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

"Tower of Goo" была скачана более 100,000 раз за месяц после попадания в Сеть, стала "Интернет-Игрой Месяца" в одном из журналов, была показана на G4 (американский игровой телеканал) и на Experimental Gameplay Workshop во время GDC, и являлась одной из пятидесяти игр, сделанных нами для Experimental Gameplay Project в Центре Развлекательных Технологий Университета Карнеги — Меллон.

И, как и все остальные, она была сделана одним человеком меньше чем за неделю.

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

1. Каждая игра должна быть сделана менее, чем за семь дней,
2. Каждая игра должна быть сделана одним человеком,
3. Каждая игра должна быть основана на общей теме, например "гравитация", "растительность", "рой", и т.д.

По мере развития проекта, мы все больше поражались и восторгались натиску веб-трафика, вниманию игровых журналов и профессионалам индустрии и академикам, задающим одни и те же вопросы: "Как вы так быстро делаете эти игры?" и "Как нам делать так же?"

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

Для удобства просмотра, все советы и рекомендации разделены на четыре раздела: Подготовка, Дизайн, Разработка и Основы Геймплея. Наслаждайтесь!

---

 

Часть 1. Подготовка: Быстрота - Это состояние разума

 

Быстрое прототипирование это нечто большее, чем полезный инструмент в пред-производстве - оно может стать образом жизни! В этом разделе будет рассказано, как настроиться и думать как быстрый прототипировщик.

Принимайте возможность неудачи - это помогает пойти на творческий риск!

Вся соль прототипирования лежит в маленькой штучке, которую мы называем "риск". Боязнь провала - вот причина того, что продолжают появляться игры на основе фильмов и франшизы с двузначными числами после названий. Это вроде посещения МакДоналдс вместо неизведанного нового ресторана - всегда надежнее положиться на проверенный вариант, чем рискованно окунуться в неизвестное, но, возможно, очень вкусное.

Хороший быстрый прототипировщик понимает, что потерпеть неудачу не страшно! Для этого и нужно прототипирование, так что делайте, что душе угодно! Если не получится одно, то получится другое, более того, вы станете опытнее благодаря неудаче. Принимая возможность неудачи, мы открываем дорогу эксперементированию.

Кайл Грей: "Mime After Mime" и "A Mime to Kill" были двумя попытками создания геймплея на основе звука без визуальной части. Хоть они и стали полным провалом, вся команда не решалась пойти на смелый риск - доказать неиграбельность такого геймплея, а я теперь могу с гордостью указывать на свои отвратительные творения. По мере получения опыта в процессе работы над проектом, я смог идти на более целенаправленные риски, ведущие к успешным играм."

Ускоряйте циклы разработки (Больше времени != Больше качества)

Вам нужно всего несколько дней. Кажется вполне логичным утверждать: "Мы сделали отличную игру за неделю. Следовательно, если мы потратим на это ДВЕ недели, то она будет В ДВА РАЗА отличнее!" Это совсем не так. Мы обнаружили, что любая идея для геймплея может быть качественно прототипирована менее, чем за неделю. Лишнее время простоя ведет к уменьшению эффективности. Некоторые прототипы заняли всего лишь один вечер чтобы собрать их, в то время как другие отхватили себе лишнюю неделю-другую. К нашему удивлению, мы обнаружили, что не было никакой взаимосвязи между потраченным на разработку временем и тем, насколько успешной игра стала в конечном итоге.

Ограничивайте свое творчество, и вы будете желать творить еще больше

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

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

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

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

Соберите крутую команду и консультанта - мышление не менее важно, чем талант

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

Джесси Шелл, консультант проекта: "Я всегда увлечен творческим процессом создания новых идей для игр, поэтому я был очень заинтригован, когда Шалин, Мэтт и Кайлы предложили этот проект. Я видел его как возможность бок-о-бок проводить творческие эксперименты, надеясь извлечь полезные уроки гейм-дизайна. В качестве консультанта я следил, чтобы команда пробовала различные методы, училась на своих ошибках, чтобы никто не возился слишком долго с идеями, которые явно не сработают, и чтобы каждый находил свой творческий процесс.

Иногда я давал советы, что можно улучшить в той или иной игре, но в основном я старался держаться в стороне. Я чувствовал себя кем-то вроде садовника: немного поливал и полол, но цвели они сами по себе. Как показывает эта статья, команда была в состоянии делать для себя некоторые полезные выводы - и в итоге получила несколько отличных игр! Существует еще несколько неизученных аспектов оптимизации творческого процесса, и Центр Развлекательных Технологий планирует продолжить этот проект."

Разрабатывайте параллельно для максимального эффекта

И вот, после того, как мы собрали нашу команду, что же мы сделали? Мы перестали работать друг с другом! Это может показаться странным, но преимущества не-сотрудничества были слишком хороши, чтобы проигнорировать их:

• Снижение риска - Разрабатывая четыре прототипа одновременно, мы могли спокойно принимать рискованные решения, рассчитывая, что по крайней мере один или двое из нас будут успешными.

• Дружеское соревнование - Каждый получает выгоду, выжимая из себя по максимуму. Прямо как в капитализме!

• Широкое исследование темы - Четыре ума, сосредоточенные на одной теме, заставляли нас копать как можно глубже внутрь каждой из них. Как неловко было бы, если бы мы все сделали одинаковые игры! Это направляло нас в разные творческие сферы и позволяло избегать очевидностей.

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

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

Части 2-3 | Часть 4

Перевод - Terzalo. Ссылка на оригинал