От идеи к реализации
Эмили Шорт, 23 августа 2009 г.
оригинал статьи
Одним из наиболее сложных аспектов разработки любительской игры является выработка способа, который вы будете использовать, чтобы попасть из точки А, вашего зародыша идеи, в точку Б, законченную игру, готовую к выходу в свет. (Кстати, это не всегда решённая проблема и при коммерческой разработке игр, но коммерческий проект обычно включает в себя людей с определённым опытом в «формировании» игры, у которых есть план – хороший или не очень – по поводу того, что должно происходить и в каком порядке.)
Недавно я приняла на вооружение новый подход к разработке, и это заставило меня взглянуть назад, на то, как я делала все эти вещи в прошлом и на всю кровопролитную эволюцию (которая, вероятно, ещё не закончилась) моей стратегии разработки игр.
Делай сейчас! Планировать будем потом!: Вы открываете свой любимый ИЛ-редактор и просто начинаете. Делаете комнату или две, что-то в них, может, персонажа. Пишете то, что приходит в голову, потом смотрите, во что это всё складывается.
По моему опыту реально трудно закончить такую игру. Я начинала очень много игр таким образом, особенно когда только знакомилась с написанием ИЛ, и это был полезный опыт в том смысле, что он познакомил меня с инструментами и был своего рода игрой. Но рано или поздно ты врезаешься в стену, когда понимаешь, что твои почеркушки ни во что не складываются. И никакого конкретного завершения у тебя в голове тоже нет. Или он есть, но нет связного сюжета, последовательной предыстории и путь неясен. Никакое планирование не касалось проекта и, рано или поздно, это становится очевидной проблемой. В этой точке ты можешь либо забросить проект и начать новый, либо сделать шаг назад, приложить усилия для того, чтобы спланировать работу над проектом, а потом вернуться обратно к реализации.
Впрочем, существует реальный риск, что, перемежая реализацию с всё увеличивающимися порциями планирования, вы будете постоянно избегать трудных кусков. «Здесь будет конец». «Что-то интересное должно случиться, я не уверен что, и игрока забросит на Альфу Центавра». «Случится чудо кодинга, потому что я даже не представляю, как написать это». Вы можете даже не понимать, что делаете это… пока рано или поздно вы не осознаете, что всё просто не складывается воедино. И даже не собирается это делать.
Создай сначала прототип трудной части (обычно это механика): Вы определяете наиболее важные/трудные элементы в задумываемой игре и кодируете их, трудитесь над ними, пока они не заработают. Потом разрабатываете пазлы, которые основываются на этих элементах и строите на этой основе всю игру.
Я пришла к такому подходу, когда «Делай сейчас!» исчерпал себя. Я работала над огромной игрой-песочницей, это был мой первый реальный масштабный ИЛ-проект, который включал в себя: детальную реализацию сжигания и разрезания объектов на части, а также камеру-полароид, которая могла точно запечатлеть состояние объектов, включая те из них, которые были разрезаны или сожжены; дым, который пачкал вещи; жидкости, которые можно было смешивать; различные уровни освещённости; персонажи, которые имели собственные цели, реагировали не только на слова главного героя, но и на большое количество жестов и другие действия, например, на то, что игрок уничтожает важный объект в их присутствии. (Лет через десять, я думаю, я буду знать достаточно, чтобы написать эту игру. Увы, но мне больше уже не хочется. Концепция геймплея была полным отстоем.)
Было слишком трудно сделать прототип системы общения с персонажами и моделирования материалов внутри большой игры, и я отошла немного в сторону и написала тестовые игры для каждой из них, где я разработала каждую из систем и написала кое-что для их проверки. Первый из этих тестов стал игрой Galatea, а второй – Metamorphoses. Какое-то время я говорила себе, что собираюсь вернуться к большой игре позже, но я не могла не заметить, что, в отличие от моего обычного подхода, этот позволил мне на самом деле создать нечто, что уже можно было выпустить в свет. Я решила сохранить подход «Делай сейчас!» в качестве мозгового штурма – я до сих пор иногда прикидываю несколько комнат, чтобы лучше представить себе новый сеттинг, или создаваемое в игре настроение, или голос главного персонажа – но не полагаюсь на этот подход, как на главный метод разработки.
Закавыка же в том, что «сделай-прототип-сложных-вещей-вначале» всё равно создаёт массу ненужной работы и заставляет терять время. Metamorphoses изначально была намного, намного большей игрой, и её пришлось беспощадно обрезать до её теперешнего размера – оставляя за собой массу отброшенного кода и дизайна. Я решила, что мне нужен более последовательный, нисходящий подход.
Полностью распиши всё на бумаге, потом реализуй: Вы садитесь в кофейне с тетрадкой и начинаете записывать всё, что вам надо знать о вашей игре. Карты и диаграммы пазлов, если они нужны в игре; план сюжета и список сцен, если это игра такого рода. Описания персонажей, временные шкалы истории, проработка сеттинга, если это такая игра. (Или всё это сразу.) Затем начинаете кодировать, сверяясь с планом – до тех пор, пока не закончите.
Это сильно похоже на то, как я написала Savoir-Faire. Сеттинг пришёл из свободного мозгового штурма над Информом, и я сначала сделала прототип магической системы. Но затем усадила себя за стол и расписала список пазлов, расположив их на большой диаграмме, и реализовала эту диаграмму. Это был необычайно приятный процесс, потому что он создавал чувство продвижения вперёд. Я знала, что дело продвигается и у меня было довольно ясное представление о том, когда я смогу всё завершить. Я меняла дизайн в процессе работы, немножко – было несколько пазлов, которые я посчитала слишком случайными и выбросила, и, отвечая на отзывы тестировщиков, я расширила раннюю версию игры несколькими простыми загадками, поскольку она в целом была несколько трудна в начале.
Тем не менее, мне не удалось заставить этот подход работать так же хорошо хотя бы ещё раз. В целом, мои неудачи можно свести к трём вещам:
Недостаток самодисплины на стадии планирования. Я позволяла себе продолжать работу над диаграммой, когда в неё были неясные моменты, какая-то магия, с которой я думала разобраться «позже», и конечно позже эти вещи становились особенно упрямыми, точно как если бы я пыталась писать без плана вообще. Особенно соблазнительно было расписать классическую трехактовую структуру и распланировать начало и середину игры, оставив финал на «потом». Причина, по которой это ужасно: отвратительно иметь 2/3 полностью реализованной игры и пялиться на перспективу неспособности закончить её вообще. И даже потом иногда ты можешь закончить её, но твой финал небрежен и увечен по сравнению с началом и серединой игры, что печально, ведь ты (и твои игроки) надеялась на мощный финал.
Диспропорция усилий, способностей или других ресурсов. Весьма вероятно, что вы заставите себя работать очень упорно над начальными частями игры и приведёте их в хорошую форму, возможно даже проведёте альфа-тест до того, как начнёте писать финал. Даже если конец игры полностью продуман, вы можете обнаружить, что у вас заканчиваются силы, остаётся мало времени до крайнего срока приёма игр на конкурс и/или бета-тестеры устали или не могут проверить вашу игру. Или же, с другой стороны, ваше мастерство значительно выросло к моменту, когда вы принялись за финал и, как результат, конец игры намного лучше начала – но не так много людей добираются до него, потому что их отталкивает невыразительное начало. Я играла в игры обоего рода и написала несколько первого. (Я не уверена, есть ли среди моих игр такие, где финал сильнее начала.)
Немного другая проблема, но из той же серии: в Savoir-Faire у меня закончился лимит на размер файла игры приблизительно к моменту, когда я писала последние пазлы, в этом причина того, что они выглядят странно скудными по сравнению с остальной игрой.
Слишком большие амбиции. Вы пишете большую диаграмму, она выглядит круто, но когда вы начинаете реализацию, вы понимаете, что это слишком, слишком много и вашей энергии и интереса попросту не хватит так надолго. Вы можете, как решение, навалиться на план и порезать его до размера чего-нибудь более управляемого – я делала так много раз – но всё равно остаётся много потерянных усилий в поцессе, вещей, которых вы закодировали и не можете использовать, пазлы, над которыми вы работали и их теперь придётся бросить. Особенно больно, если приходится отрывать те куски, которые вам действительно нравились. Ранние наброски игры Floatpoint были более насыщены загадками и юмором, потому что я хотела подчеркнуть, насколько протагонист был не в своей тарелке, заставляя его курьёзно сражатся с местными обычаями и машинами. Там было несколько кусочков, которые сильно смешили меня. Но их пришлось отбросить, потому что из-за них игра писалась слишком медленно, чтобы успеть на конкурс, и потому что они отвлекали игрока от настоящей темы вещи в целом. Если вы не сможете заставить себя отрезать подобные вещи, проект может полностью остановиться.
Поэтому сейчас я перешла к:
Напиши сначала центральную линию игры: Разработайте сеттинг и любые прототипы, которые нужны, а также, возможно, сделайте список пазлов/элементов, которые вы хотите видеть в законченной игре. Затем создайте простой набросок игры и воплотите его, так чтобы у вас было что-то, во что можно сыграть (даже если очень быстро) с начала и до конца и что содержит наиболее важные поворотные моменты сюжета. С таким скелетом в руках, разберитесь что вам нравится и что не нравится в структуре; вы усложняете игру постепенно, наращивая плоть новыми загадками или усложняя простые пазлы/разговоры, с которых вы начали. Вы можете рисовать в списке пазлы или ситуации, с которых вы хотели бы начать, но вам необязательно прорисовывать всю структуру изначально.
Что замечательно в таком подходе – на конец первой недели или около того у вас будет полностью играбельная игра. Она всегда в определённом смысле «закончена» - о, нет, разумеется, не в том состоянии, когда вы готовы выпустить её в свет, но у неё достаточно ясная форма и вы не ломаете в ужасе голову, беспокойства по поводу того, что там будет в какой-то из частей.
Финал получает столько же внимания, как и вступление и навряд ли будет фуднаментально отличаться от него по стилю, теме или качеству исполнения.
В то же время, вы получаете необычайно гибкий процесс разработки, потому что вы можете добавлять новые элементы, чтобы закрыть прорехи дизайна, которые вы заметите. Слишком крута кривая обучения? Хорошо, добавим несколько несложных загадок в начале игры. Недостаточно мотивации для главного NPC? Добавим ещё одну разговорную сцену, которая прольёт неожиданный свет на его биографию. (Странная вещь насчёт ИЛ: в целом, проще добавить что-то, чем убрать. Если вы реализовали важную возможность или сложный пазл, то они могут иметь включения по всему коду. Убрать его из кода будет похоже на вырывание сорняка, что пустил свои корни повсюду, и может стоить вам нескольких ошибок в коде игры.)
И наконец, этот процесс даёт наилучший результат в обмен на ваши усилия. На каждом этапе разработки у вас будет нечто, что вы можете остановить, протестировать, отполировать и выпустить. Если вы сделаете это рано, то получите крошечную мини-игру с несложной историей, сделаете позже – можете получить 15-часовой шедевр. Но процесс движения от того, что у вас есть, к игре, которую вы можете выпустить, всегда чёток и ясен.
Я натолкнулась на этот метод с Bronze, главным образом потому, что это была игра на Speed-IF, которую я решила переделать в полноценную игру. Я вернулась к ней, как к ещё одной проблемной «игре-в-процессе-разработки» и испытала большое облегчение, когда применила подход, описанный выше.
Возможно, я обнаружу недочёты и в этом методе тоже. Но в настоящий момент он работает для меня лучше, чем любой из предыдущих подходов, так что я буду делать так. Прописывать сначала центральную линию.
Существует ещё одна возможность, которую я должна упомянуть:
Напишите полный транскрипт, затем реализуйте: Вы садитесь за текстовый редактор и пишете транскрипт идеального прохождения вашей игры. Затем реализуете его.
Я пишу это здесь как альтернативу потому, что, хотя я никогда не делала этого для целой игры, это звучит как жизнеспособный подход. J. Robinson Wheeler использовал его. Он описывает процесс в некоторых деталях в своей статье «Make IF Fast». Также Stephen Bond пишет о применении этого подхода при написании The Cabal. Настоящая сила этого подхода в том, что он подталкивает автора думать как игрока: записывать подсказки и лёгкие знаки в текст, который выдаёт «игра», что провоцирует на исследование мира игры и создаёт сильное чувство направления движения. Я не думаю, что является совпадением тот факт, что (а) Wheeler какое-то время назад был независимым кинорежиссёром, был знаком со сценарием и процессом воплощения его в конечную форму; и (б) что игры, которые он написал этим способом, среди наиболее кинематографичных и ровных в продвижении из всех, что я встречала.