Сценарий ВН. Структура с точки зрения ветвлений и вариативности
Приготовьтесь к душной, но важной статье, над которой я уже очень давно работала. Я пыталась разработать её, учитывая свой текущий опыт, и сделать её как можно более понятной.
ВВЕДЕНИЕ
Так как я занимаюсь в основном визуальными новеллами, эта статья больше подойдёт "виноделам", но базовые принципы могут применяться и в других случаях: например, в любой другой сюжетной игре, а, может, и в прозе.
Также скажу, что буду показывать вам примеры на базе программирования, потому что, так или иначе, принципы ветвления ВН связаны именно с ним. Если вы думали в школе на уроке информатики «зачем мы проходим эти грёбаные алгоритмы?», а потом сели за сценарий визуальной новеллы и не знаете, как прописать руты и ветки — эта статья для вас.
Для начала, стоит сказать пару слов об алгоритме. Грубо говоря, алгоритм — это последовательность действий, направленная на решение конкретной задачи. Очень часто неясные с первого взгляда задачи становятся куда проще, когда мы записываем пути их решения, например, при помощи блок-схемы. Блок-схема в программировании — это способ написания алгоритмов (иными словами, программы или куска кода в графическом виде). У блок-схемы есть общепринятые обозначения различных операций. Выглядят они так:
Эти обозначения пригодятся нам в будущем для наглядности. (Само-собой вы не обязаны использовать именно такие символы при своей работе).
СЦЕНАРИЙ
Про форматирование текста для визуальной новеллы я уже говорила в статье “Сценарий и проза. Какая разница?”. Форматирование или соблюдение хотя бы структуры при написании сценария значительно облегчит работу вам и/или вашей команде. Если мы откроем пьесу, она будет разительно отличаться от обычной прозы. Точно также сценарий ВН разительно отличается от обычного художественного текста (грабли, на которые и я также наступала какое-то время). Каким образом принципы программирования связаны со сценарием визуальной новеллы? Если вы всё ещё задаётесь этим вопросом, я объясню.
В сценарии визуальной новеллы учитываются все данные, которые необходимы для функционирования истории. На базовом уровне линейной истории у нас уже есть потребность обозначить героев внутри самой программы, что выглядит в RenPy вот так:
Это уже задача для программы: «выведи текст, напиши это имя».
А если вы решили добавить вариативность? А как программа будет решать, что ей показывать? Будет она перепрыгивать с одного куска кода на другой сразу или накапливать данные в переменах? Всё это так или иначе должно отображаться внутри сценария визуальной новеллы. Из-за этого многие используют свои собственные блок-схемы с понятными им обозначениями, чтобы не запутаться. Но то, как подобное можно обозначать в письменном виде — отдельная большая тема.
ВЕТВЛЕНИЯ И ВАРИАТИВНОСТЬ
Для начала, давайте разграничим эти два понятия для ясности.
Ветвление — это выполнение некого условия, для перехода на одну из предлагаемых веток повествования.
Вариативность — то, сколько последствий/исходов содержится в сценарии, вследствие ветвлений/выполнения условий.
Ветвление можно представить в виде дерева. Но существует два вида ветвлений: истинные и ложные (которые, скорее, выглядят, как сросшиеся ветви, дерево-мутант получается).
Истинное ветвление предполагает, что действие неминуемо свернёт с одной тропы на другую и никогда не вернётся на прежнюю.
Ложное ветвление предполагает, что действие влияет лишь на какой-то отрезок истории или создаёт некий цикл, а затем возвращается на изначальную тропу.
Из-за внешнего вида, ложное ветвление можно назвать «алмазом».
(Конечно, вам не обязательно соблюдать язык алгоритма в вашей личной блок-схеме. Это лишь пример.)
То есть при исходном A в первом случае, выбирая B или C, ты получишь либо B, либо C. Во втором случае при исходном A, выбирая B или C, ты в любом случае получишь только D. То, что называют в народе «ложные выборы», — это и есть ложное ветвление, которое условно «ни к чему не ведёт». Однако даже «алмаз» можно грамотно применить, особенно там, где нужно подсчитывать баллы и запоминать определённые выборы для будущих развилок.
Таким образом, я могу назвать вариативной ту визуальную новеллу, где последствия вариативности явные. Например, когда ГГ не только открывает новые реплики в диалоге, но и выстраивает отношение к чему-либо/кому-либо, что может повлиять на его действия в дальнейшем. ГГ может навсегда свернуть с одной развилки к другой, где будет выражать последствия действий игрока. (Много канцелярита, но надеюсь, понятно, что я имею ввиду.)
То есть, даже если в общем прослеживается «алмаз», применяемые решения влияют на что-то, раскрывают больше истории, дают посмотреть на происходящее с иной стороны. Или позволяют прийти к одной концовке разными путями.
ИСТИННОЕ ВЕТВЛЕНИЕ В СЦЕНАРИИ
Пожалуй, самый простой способ разнообразить визуальную новеллу и добавить несколько концовок. RenPy предлагает нам уже заложенную в нём функцию «menu».
Но независимо от того, какой код и какой движок будет использован, в виде блок-схемы это будет выглядеть примерно так:
Упрощая:
Плюсы: вы действительно прописываете различные варианты событий, контент разнообразнее; простой для понимания.
Сомнительный минус: ваше дерево ветвлений может очень сильно разрастись в геометрической прогрессии.
Минусы: если требуется, чтобы герой пережил одно и то же событие в разных ветках, такое ветвление не подходит, т.к. в коде оно НЕ предполагает возвращения к определённой точке сюжета.
Сомнительный минус: ваше дерево ветвлений может очень сильно разрастись в геометрической прогрессии.
Минусы: если требуется, чтобы герой пережил одно и то же событие в разных ветках, такое ветвление не подходит, т.к. в коде оно НЕ предполагает возвращения к определённой точке сюжета.
Бывает такое, что люди просто копируют кусок текста в разные ветки. В RenPy эти строки считаются новыми при прохождении, их невозможно скипнуть «пропуском», можно случайно пролистать новое. Это не только раздражает, но и создаёт ненужные дополнительные строки в скрипте. Редактор кода не «ворд», в нём можно и нужно использовать доступные методы упрощения. Это не даст вам запутаться в коде и уменьшит вес финального билда (если это важно, конечно).
Если вы хотите, чтобы разветвление было, но в какой-то момент персонаж пережил одно и то же как в одном, так и другом случае, то здесь вам поможет «алмаз». Но есть нюанс…
ЛОЖНОЕ ВЕТВЛЕНИЕ. «АЛМАЗ»
Добавим ещё одно событие в нашу историю про звонок.
Дополню свою блок-схему.
Однако «алмаз» сам по себе не даёт возможность повернуть на иную ветку. К тому же, вдруг мы хотим не просто, чтобы разговор прошёл с разными людьми, но чтобы это повлияло на концовку? Необходимо сохранить выбор где-нибудь.
Есть несколько способов, как это сделать.
1. Булева переменная — способна хранить только одно из двух значений, задействует меньше вычислений. Для неё достаточно в сценарии обозначить название переменной и значение «Истина» или «Ложь» (или «Да» /«Нет», или True/False).
Например:
2. Переменная — может хранить больше значений. В разных языках программирования существуют разные виды, с разным диапазоном данных, которые она способна хранить. Сильнее нагружает компьютер. Можно использовать одну переменную вместо нескольких булевых.
Например:
Имейте в виду, что переменные не сохраняются перманентно для всей игры, а лишь для сессии игрока, которую он проходит в данный момент.
3. Постоянная (константа) — хранит заданное постоянное значение. В отличие от переменных сохраняется вне сессии игрока (например, в RenPy именно так). Она может быть применена, если вам необходимо запомнить выбор для следующей сессии (перепрохождения), например, чтобы убрать уже выбранный вариант из предыдущего прохождения.
4. Баллы (следующая подтема)
Вернёмся к ложным ветвлениям. Их за отрезок повествования может быть сколько угодно, хоть 5, хоть 20. Но если вы забудете запомнить ключевые выборы в каком-либо виде, не пропишите реакцию второстепенных персонажей на предыдущие выборы, то доверие игрока подорвётся. Велик риск ввести его в заблуждение. Вы можете запросто забыть, что ваш герой в какой-то момент не взял с собой нож, чтобы потом вытащить его, когда будет необходимо. Для вас и для игры где-то в коде есть этот «взять нож с собой», но игрок от него отказался, а предмет почему-то оказался в руках. Согласитесь, неприятно, да?
«Алмаз» — палочка выручалочка, когда вам необходим выбор, который в данный момент не повлияет на что-то, но в будущем сыграет свою роль. Пренебрегать ей и пихать просто ради выборов — мне лично кажется — не уважение к игроку.
Можно ли создать относительно линейную ВН, где важен путь, а не конец? Конечно. Просто представим, что ваш «алмаз» разросся до большего масштаба. Вы хотите привести все ветки повествования к одному концу? Сведите их все вместе в конце. И тут мне стало интересно, будет ли эта ВН и вправду линейной? Вопрос на подумать.
БАЛЛЫ
Ветвление, основанное на балловой системе запоминает действия игрока, обычно, в переменную, при проверке значения которой выбирается дальнейший путь повествования в ключевой момент. Очень часто применяется в симуляторах свиданий, где нужно набрать сколько-то баллов героини, чтобы выбраться на её рут. Само собой баллы можно применять не только в романтической новелле.
Баллы удобно использовать при разбивании сценария на несколько секторов. Возьмём за единицу сектора — день. Допустим два дня герой знакомится с другими персонажами, а на третий день должно что-то кардинально поменяться. В эти два дня мы поместим несколько «алмазов», где тот или иной выбор будет складывать баллы в пользу разных исходов.
Я привела утрированный пример ситуации. Замечаете, что-то не так? Не смотря на то, что есть выбор «помочь девушке», не прописано, что герой помогает ей. Он сразу покидает школу. То есть мы провели операции за кадром, что может сбить с толку. Вот так это выглядит в схеме на самом деле:
То есть на выходе игрок не увидит, помог он на самом деле, или нет, хотя для игры, он совершил определённое действие. И если попросить программу вывести значение переменной nas — она покажет значение 1. Однако мы не вывели последствий этого решения. Сейчас это кажется глупым. Но представим ситуацию, где героиня Аня в руках игрока должна полюбить определённого Петю. Однако на протяжении всего дня она почему-то флиртует с Сашей. Странно? Странно. Мы дадим и себе, и игре запомнить момент, где Аня решает подружиться с Петей. И при взаимодействии с Сашей не дадим ей просто так флиртовать с Сашей. (Если вы конечно не хотите, чтобы вашу Аню колбасило от каждого встречного намеренно).
Исправляем сценарий.
Таким образом мы создали «алмаз», где при выборе «помочь», герой переживает какой-то опыт, а затем этот выбор влияет на реакцию его друга. В противном случае, когда выбрано «уйти», герой просто уходит с другом из школы. Мы можем развивать этот сюжет и дальше. Дать шанс игроку познакомиться с Настей позже, дать им возможность сходить на свидание и т.д. И можем сделать альтернативную ветку дружбы со Стасом.
КОМБИНАЦИИ
При использовании баллов, ложных ветвлений ради разнообразия концовок вы неизбежно смешаете их с первым основным методом, если сюжет должен прийти к тому или иному окончанию. Либо же всё сойдётся в один цельный «алмаз» (смерть — для всех один конец, не так ли?). Смысл и нарратив, которые вам необходимы описываются не только художественным текстом, изображениями и музыкой, но и геймплеем.
Кратко повторим вышеописанные способы добавления вариативности:
• Истинное ветвление — самый простой способ разбить сценарий на разные ветки с абсолютно разными событиями и концовками.
• Ложное ветвление — способ, позволяющий включить дополнительный интерактив, использовать баллы, запомнить выбор игрока для события в будущем.
Как правило, ложное ветвление комбинируют с истинным. Чтобы не запутаться, стоит идти от простого к сложному. Так, выпекая торт, сначала запекают коржи, а затем покрывают их сливками и украшают.
Простой пример комбинации, похожее мы уже встречали выше:
К тому же не обязательно использовать стандартное меню выбора, например в RenPy. Это может быть графический выбор на интерактивном изображении (комната с дверьми, карта и т.д.), похожий на элемент квеста, это может быть мини-игра, исход которой влияет на дальнейшее событие (выигрыш или проигрыш).
Комбинации позволяют глубже раскрыть разные стороны истории, определённого персонажа или обозначить важные изменения в поведении главного героя. Дать игроку больше власти и взаимной отдачи.
Но помните, чем больше вы добавляете интерактивности, тем тоньше лёд.
Не всегда сценарист является программистом, не всегда сценарист разбирается в коде, не всегда сценарист учил информатику. Поэтому при коммуникации с программистом важно понятно донести до него, чего вы хотите. И полезно знать, как обычно думают программисты, составляя код для вашей новеллы. Если же вы сами себе программист, но только начали — полезно изучить блок-схемы и алгоритмы даже для такой простой ВН, где не используется запись баллов в переменные, чтобы было легче систематизировать в голове сюжет.
Не всегда сценарист является программистом, не всегда сценарист разбирается в коде, не всегда сценарист учил информатику. Поэтому при коммуникации с программистом важно понятно донести до него, чего вы хотите. И полезно знать, как обычно думают программисты, составляя код для вашей новеллы. Если же вы сами себе программист, но только начали — полезно изучить блок-схемы и алгоритмы даже для такой простой ВН, где не используется запись баллов в переменные, чтобы было легче систематизировать в голове сюжет.
ЗАКЛЮЧЕНИЕ
Я очень надеюсь, что вы не растеклись, пока читали, а я не слишком надушнила. Возможно, в чём-то я не права. Помните, никто вам никогда не запретит делать так, как вы хотите. Я лишь делюсь идеями, которые могут помочь. И надеюсь, что помогут.
Эта статья пылилась оч долго. Год? Но её нельзя было выпустить раньше, предыдущих. Без них, она выглядит, как кусок истории, вырванный из середины книги. И я уже потеряла кое-какие скриншоты на ПК. Пришлось их искать и восстанавливать. Надеюсь, некоторые скрины не выглядят слишком мыльно.
Эта статья пылилась оч долго. Год? Но её нельзя было выпустить раньше, предыдущих. Без них, она выглядит, как кусок истории, вырванный из середины книги. И я уже потеряла кое-какие скриншоты на ПК. Пришлось их искать и восстанавливать. Надеюсь, некоторые скрины не выглядят слишком мыльно.
Почему я решила сделать такую статью? Во-первых, я хотела упорядочить собственные знания, дать им физическое воплощение. А во-вторых, я видела запрос у некоторых людей. Просто сталкивалась с вопросами "да как делать эту вашу вариативность?". С первого взгляда это сложно. Но, как и любая задача, если делать по чуть-чуть, что-нибудь да сделается.
Желаю вам творческих успехов!
Спасибо за внимание! Всем чай~