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

 

Часть 1 | Часть 4

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

---

 

2. Дизайн: Творчество и Мифы о мозговом штурме

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

Обычный мозговой штурм - 0% вероятности успеха

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

Почему нет? Это весьма шокировало нас, но после долгих исследований оказалось, что невозможно запланировать творчество. Вы не можете просто взять и сказать: "Эй, ребята, давайте соберемся в 4:15 для мозгового штурма, и в 5:00 у нас будет четыре обалденных идеи для игр, готовые к разработке!"

Но все не так безнадежно. Есть (по крайней мере) две разумные вещи, которые можно ожидать от хорошо проведенной сессии мозгового штурма. Во-первых, она, конечно же, заставит всех думать. Еще есть вероятность, что позже, может быть по дороге домой, или во время прогулки с любимым Шариком, блестящая идея вдруг пронзит вашу голову. А может и не пронзит. Можем лишь заметить, что ваш загадочный мозг может работать больше всего тогда, когда вы этого меньше всего ожидаете.

Во-вторых, мозговой штурм может быть полезен, если обсуждается что-то конкретное. Например, "Как мы можем улучшить это?" вместо "Эй, ребята, давайте придумаем что-нибудь крутое!" Если, например, у кого-то была половина идеи для игры, то было полезно обсудить ее с остальной командой, чтобы окончательно укрепить. Кто угодно является лучшим критиком, чем создатель, верно?

Скапливайте концепт-арты и музыку, чтобы создать эмоциональный настрой

Мы обнаружили, что плодотворной альтернативой мозговому штурму может стать сбор арта и музыки для формирования идей. Люди отмечали, что многие игры вроде "Gravity Head" и "On a Rainy Day" создают сильное впечатление и имеют особую эмоциональную привлекательность. Это не случайно. В этих и многих других случаях, саундтрек и концепт-арт, совмещаясь, создавали у нас особые ощущения, которые влияли на большинство решений в геймплее, сюжете, и окончательном игровом арте.

Кайл Гэблер: "Идея "Tower of Goo" пришла ко мне, когда я (зачем-то) слушал вступление к "Tango Apasionado" Астора Пьяццоллы, придя домой, и в моей голове возникло видение – небольшой городок в лучах заката, и все жители покидают свои дома, забирая с собой столы, стулья, и все, что могут унести, чтобы построить гигантскую башню в центре города. Я не знаю почему, но они очень хотели лезть выше и выше – но они были не очень хорошими инженерами-строителями, поэтому вы должны были им помогать. Окончательный прототип оказался чуть веселее, поэтому я заменил музыку на более энергичную "Libertango" Пьяццоллы, но это все равно является примером случая, когда изначальный эмоциональный настрой определил всю игру."

Симулируйте игру в своей голове – Пред-прототипируйте прототип

Это очень просто! Все, что нужно сделать – это представить, что ваша игровая аудитория говорит: "Ого!" - а потом пойти от этого назад и заполнять пробелы. Что заставляет их наслаждаться игрой? Что происходит в игре такого, чтобы они говорили так?

Для каждой из наших самых успешных игр не было неожиданностью, когда оказывалось, что в них весело играть – в лучших случаях мы, не написав и строки кода, знали, что идея хороша, благодаря симуляции игры в голове в качестве небольшого мысленного эксперимента. Верно и обратное. Не было ни одной игры, которая случайно или неожиданно стала успешной. Мы всегда знали это заранее. (К сожалению, это не помешало нам гоняться за сырыми идеями.)

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

Один из членов команды признается: "Для меня не было ничего необычного продурачиться первые 3 или 4 дня, просматривая клипы O-Zone в поисках "вдохновения" или валяться на пуфе вверх ногами, слушая музыку и наполняя голову кровью, иногда прогоняя в мозгу дурацкие симуляции. И вот, когда наступал четверг или пятница, я начинал паниковать, потому что я все еще понятия не имел, что приготовить к понедельнику, и я брал самую сильную из идей, подправлял ее, основываясь на тематике недели, пока она не начинала выглядеть как интересная игра, а потом следующие несколько бессоных суток вбивал ее в компьютер и рисовал красивые картинки. Для меня, (и, наверное, для всех нас) дни, проведенные в "пред-разработке" были, несомненно, ценнее, чем дни, потраченные на саму разработку."

---

 

3. Разработка: Никто не знает, как ты это сделал, и никому до этого нет дела

 

Как только вы нашли отличную идею, вам пора приступать к созданию демки. Вот несколько уловок, чтобы набросать ее в кратчайшие сроки!

Сначала сделайте игрушку

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

Кайл Гэблер: "В случае с "Super Tummy Bubble" игрушка была просто кучкой пузырьков наваленных в небольшом контейнере. После того, как я, играя с параметрами пузырьков, дошел до момента, когда копошиться в них стало действительно весело, пришло время работать над геймплеем. Особенностями геймплея стали пузырьки с разными видами паразитов, концепция "лопанья", концепция "цепочек", счетчики очков, и т. д."

Если  что-то может завести вас слишком далеко, подделайте это

Это, возможно, один из самых важных уроков проекта. Часто "корректное" решение не является лучшим. Хитрая подделка этого решения сохранит ваше время и деньги; ваша игра будет сделана быстрее, а зубы станут белее. Подделывайте совершенно свободно и часто! Не создавайте сложную систему освещения и затенения, когда подготовленная падающая тень и заранее отрендеренные текстуры могут быть не менее эффективными ("Darwin Hill"). Не создавайте сложную систему распознавания шаблонов для анализа рисунков пользователя, когда вы можете сделать ее подобие на скорую руку с тем же эффектом ("Suburban Brawl"). Не рисуйте сплайны и не создавайте свою собственную библиотеку для работы с векторной графикой, когда растягивающиеся растровые изображения дают тот же эффект быстрее и проще ("Tower of Goo"). Как оказалось, это правило также является и отличным уроком в реальной жизни. Бездельники, возьмите на заметку.

Сокращайте потери и "Знайте, когда стоит застрелить своего ребенка"

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

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

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

Обильное оформление не спасет плохой гейм-дизайн (или "Вам не удастся сделать конфетку из дерьма")

Мы выяснили, что игроки оказываются куда умнее, чем вы думаете, и могут понять, что вы пытаетесь подсунуть им посредственную игру. Если геймплей ужасен, то его ничего не спасет – самые прекрасные арт, музыка и популярные франшизы не сделают из него хорошую игру. Так же, как и с персонажами из последнего 3D-мультфильма, налепленными на устаревшую игровую механику, вам не удастся никого обмануть.

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

Но в целом оформление имеет значение! Используйте добротный набор изображений, звуков и музыки

На самом деле это противоречит одной из наших первоначальных гипотез. Мы думали, что арты или звуки не будут иметь никакого значения вообще, но мы ошибались! Играть в хорошо отполированную игру несомненно приятнее, чем играть в игру с тем же кодом, но небрежными изображениями и плохим звуком. Но важно учесть следующее – полировка и оформление (как описано выше) не спасут плохой гейм-дизайн, но могут сделать хорошую игру еще играбельней. Это не значит, что вам необходимы высококачественная графика или передовые звуковые технологии. Это значит, что вы можете получить выгоду, упаковав все в единую сплоченную композицию. Помните, даже нарочито низкокачественное оформление может стать успешным инструментом, если вы правильно его преподнесете (Например, визуальное оформление в "RunMan" или звуковая часть в "Time Fcuk" - прим. перев.).

Всем плевать на ваши прекрасные навыки программирования

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

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

Часть 1 | Часть 4

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