Как написать свою новеллу

Об этой статье

Была ли эта статья полезной?

Как написать впечатляющую новеллу, чтобы её хотелось пройти на разные концовки?

Написание цепляющей визуальной новеллы непростая задача для писателя вне зависимости от его опыта.

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

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

Но как сделать новеллу настолько увлекательной для чтения?

Погружайте в историю

Начало вашей новеллы — самая важная часть работы. Она создаёт антураж, задаёт ритм повествования и знакомит с сюжетом. У неё главная роль — зацепить внимание читателя. Если он не увидит что-то интересное, то перестанет читать, отвлечётся на окружающие факторы. Даже если ваш сценарий гениален, игрок может попросту отвлечься и забыть почему начал читать.

Рассказывая о сеттинге и героях, начните играть на человеческих эмоциях. Есть несколько простых способов как это сделать:

1. Задайте загадку.

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

Чтобы суметь использовать этот приём, посмотрите на ваш сценарий, структуру новеллы, и подумайте: какой интересный поворот можно вытащить в начало? Что вызвало бы любопытство у меня или моих друзей?

Вы можете намеренно создать странную «дыру» в сюжете, но помните, что в развязке (или развязках, если у вас несколько концовок) вы должны дать ответы на все вопросы и закрыть все дыры. Иначе любопытство превратится в разочарование.

1. Пощекочите нервы.

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

Вызовите тревогу, страх, непонимание, чтобы читатель задумался, мол, «если такое происходит в начале, то что будет дальше?»

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

1. Уроните главную проблему.

Популярный приём, используемый в сценариях фильмов, сериалах, аниме. Вы начинаете с центральной проблемы, конфликта, чтобы читатель задал вопросы: «как это произошло?» и “как быть дальше?” Следом возвращаетесь к событиям как такое могло произойти, порционно даёте ответы и интригуете развязкой.

1. Истина или ложь?

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

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

1. Сломайте ожидания.

Создайте небольшую рутину, чтобы читатель подумал, что предвидит следующий шаг героя, а затем сделайте внезапный поворот. Главный герой может быть добропорядочным гражданином, совершать справедливые поступки, но вдруг делает неожиданное исключение, исходя из своей мотивации или биографии. Его поступок сдвигает сюжет с мёртвой точки и вызывает вопрос читателя «Почему он так поступил?» раскрыть который необходимо во время повествования

Какие выборы захватят внимание читателя?

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

Алексей Скребнёв, автор новелл для BestNovels:

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

Могу посоветовать основное внимание уделить как самой истории (она должна быть яркой, интриговать, обладать живыми персонажами), так и её интерактивности. У игрока должны быть логичные выборы и развилки. Каждая ветка, пусть и тупиковая (ведущая к проигрышу), должна быть ценна эмоциями и информацией. Расширять вашу историю.

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

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

Антон Пашков, автор новелл для BestNovels:

Я стараюсь делать выборы по ходу истории, чтобы играя, человек неосознанно собирал собственную модель поведения, которая ему приятна.

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

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

Хорошие выборы в новеллах:

• исходят из контекста сцены

• влияют на развитие сюжета

• имеют последствия

• раскрывают модель поведения близкую игроку

Плохие выборы бессмысленно водят по локациям, где не даётся ни одной зацепки, ничего не происходит.

Например, персонаж находится в зале гостинной, он детектив, решает обыскать место. Есть выбор — выйти в коридор, в спальную комнату, в столовую. Игрок заходит в выбранное место. Снова даётся выбор обыскать местность, везде — пусто. Предлагается выбор других локаций доступных для поиска. Снова пусто, никаких значимых предметов, зацепок. Лишь спустя время находится ключ. Читатель тратит время, а автор тянет хронометраж новеллы.

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

Сделайте интересные концовки

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

Модель поведение, отношение к окружающим, действия по ходу истории — все последствия должны присутствовать в финале.

Читателю хочет узнать какое влияние на сюжет он оказал.

Если вы упустите хотя бы одно последствий выборов в новелле, это окажет негативное влияние на работу, а весь вложенный труд останется недооценённым.

Выводы

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

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

Как создать свою новеллу в одиночку?

Содержание:

__ __ __ __ __ __ __ __

| •Идеи

| •Персонажи

| •Выбор движка

| •Графика

| •Аудио

★•°•.•°•★•°•.•°•★

Идеи

Начните с выбора жанра. Подумайте, будет ли ваша новелла ужастиком, или может симулятором свиданий с хентай сценами? От жанра зависит целевая аудитория новеллы (возраст, пол, люди, принадлежащие к каким-либо обществам и т.п.) Лично я делаю новеллу для подростков и детей моего возраста (11-16 лет). Выбрал я жанр, как вы поняли квест, психология и повседневность. Так же немного хоррора.

Далее придумайте, о чём повествует ваша новелла? Придумайте сеттинг, в котором будут происходить действия. Продумайте его тщательно, ибо музыка, графика и прочие элементы игры подстраиваются под сеттинг, чтобы создать атмосферу.

Когда будет достаточно идей, приступайте к персонажам.

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

★•°•.•°•★•°•.•°•★

Персонажи

Как вы наверное заметили, персонажи в новеллах очень разнообразны и контрастируют между собой. Например беспечная Ульяна и ответственная Славя, или робкая Лена и смелая, бойкая Алиса. Придумайте побольше самых разных персонажей, особенно, если это симулятор свиданийг, или эроге. На выбор но в таком случае будет несколько персонажей, среди которых он может выбрать кого-то и выйти на его рут. Можно также добавить популярных клише, типо родственницы, лоли, лучшая тян в классе, староста тян, можете даже трапа туда закинуть) Главное, чтобы персонажи были раскрытыми и реагировали на ситуацию по разному.

★•°•.•°•★•°•.•°•★

Сценарий

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

★•°•.•°•★•°•.•°•★

Выбор движка

На свете есть множество удобных движков для создания визуальных новелл, правда большинство из них японские. Вот некоторые движки, которые наиболее известны в интернете:

PONScripter / ONSlaugh

Blade Engine

KiriKiri Adventure Game System

Novelty

Ren’Py.

Большинство из движков сложны в освоении, поэтому сегодня я расскажу вам про последний. Ren’Py — движок для создания визуальных новелл и прочих похожих игр, написанный разработчиком Py’Tom на языке программирования Python. Программирование осуществляется максимально просто, движок поддерживает управление переменными, постоянными переменными, возможностью добавлять картинки, аудио и некоторые другие игровые элементы. Движок поддерживает многие языки, включая русский. В движок так-же встроен пример новеллы и новелла — туториал. Лично я тоже использую данный движок. Достаточно посмотреть пару туториалов на Ютубе и уже начать что-то понимать в программировании на ренпае.

Факт: Такие новеллы, как Тук тук литературный клуб, или Бесконечное лето были сделаны на движке ренпай.

★•°•.•°•★•°•.•°•★

Графика

Как наверное уже многие заметили, почти ВСЕ новеллы имеют анимешную графику. Поэтому, если хотите иметь прямо очень новельную графику, вам придется научиться рисовать японские мультики. Или же пойти по моим стопам и отклониться от традиции. Я например рисую новеллу в своём стиле (векторный мультяшный лайн-арт мышкой :3).

Итак, что вам придется отрисовывать? Все игровые элементы, элементы меню, настроек, самой игры на всём её протяжении. Всех персонажей, по нескольким эмоциям на каждого. Также множество фонов. В общем, работы много, но графика есть графика.

Кстати, я рисую в sai2.

★•°•.•°•★•°•.•°•★

Аудио

Да, конечно написать самому музыку, когда тебе на ухо наступил медведь проблематично, но если ты знаешь базовые вещи, например строения тонического, субдоминантного и доминантного аккорда, или из чего состоит простейший бит. Есть множество удобных программ, таких как caustic, fl studio и подобные. Лично я пользуюсь именно ими)

Вам нужно написать большое количество треков, на разные моменты игры. Они должны быть разными по характеру, чтобы их можно было везде распихать. Звуки можно брать с сайтов с бесплатными звуками (не поверите, но все звуки из БЛ взяты с таких сайтов).

Приветствую. Так получилось, что уже три года подряд в качестве подарка на Новый год определенным людям я делаю игру. В 2018-ом году это был платформер с элементами головоломки, о котором я писал на хабре. В 2019-ом — сетевая RTS для двух игроков, о которой я ничего не писал. И наконец, в 2020-ом — визуальная новелла, о которой далее и пойдет речь, созданная в условиях сильно ограниченного времени.

В этой статье:

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

Интересно? Тогда добро пожаловать под кат.

Осторожно: тут много текста и ~3.5мб изображений

Содержание:

    0. Обоснование разработки движка.

1. Выбор платформы.
2. Архитектура движка и его реализация:
   2.1. Постановка задачи.
   2.2. Архитектура и реализация.
3. Скриптовый язык:
   3.1. Язык.
   3.2. Интерпретатор.
4. Разработка игры:
   4.1. История и разработка логики игры.
   4.2. Графика.
5. Статистика и итоги.

Примечание: Если вам по каким-то причинам неинтересны технические подробности, можете переходить сразу к п. 4 «Разработка игры», однако Вы пропустите основную часть контента

0. Обоснование разработки движка

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

1. Выбор платформы

Выбор, собственно, был невелик: либо Java, либо C++. Недолго думая, я решил реализовывать задуманное на Java, т.к. для быстрой разработки она даёт все возможности (а именно: автоматическое управление памятью и большую, по сравнению с C++, простоту, которая скрывает много низкоуровневых деталей и, как следствие, позволяет меньше акцентировать внимание на самом языке и думать только о бизнес-логике), а также обеспечивает поддержку окон, графики и аудио из коробки.

Для реализации графического интерфейса был выбран Swing, так как я использовал Java 13, где JavaFX уже не входит в библиотеку, а добавлять в зависимости десятки мегабайт OpenJFX было лень. Возможно, это было не лучшим решением, но тем не менее.

Вероятно, возникает вопрос: что это за игровой движок, да без аппаратного ускорения? Ответ заключается в отсутствии времени для борьбы с OpenGL, а также абсолютной её бессмысленности: для визуальной новеллы неважен FPS (во всяком случае, с таким количеством анимации и графики, как в данном кейсе).

2. Архитектура движка и его реализация

2.1 Постановка задачи

Для того чтобы решить, как что-либо делать, нужно определиться с тем, зачем это делать. Это я о постановке задачи, т.к. архитектура не универсального, а «домен-специфичного» движка по определению напрямую зависит от задумываемой игры.

Под универсальным движком я понимаю движок, поддерживающий относительно низкоуровневые понятия, типа «Игровой объект», «Сцена», «Компонент». Делать было решено именно не универсальный движок, потому что это значительно сократило бы время разработки.

По задумке, игра должна была состоять из следующих частей:

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

Примечание: Под сценой я понимаю логически выделенную часть игры. Критерием сцены может служить одинаковый фон на протяжении этой самой части.

Также среди требований к движку была возможность воспроизведения аудио и показа сообщений (с опциональной функцией пользовательского ввода).

Пожалуй, самым важным желанием было желание писать логику игры не на Java, а на каком-нибудь простом декларативном ЯП.

Также было желание реализовать возможность процедурного анимирования, а именно элементарного движения изображений, при этом чтобы можно было на уровне Java определять функцию, по которой считается текущая скорость движения (например, чтобы график скорости был прямой, либо синусоидой, либо ещё чем-то).

По задумке, всё взаимодействие с пользователем должно было производиться через систему диалогов. При этом диалогом считался не обязательно диалог с NPC или что-то подобное, а вообще реакция на любой пользовательский ввод, для которого был зарегистрирован соответствующий обработчик. Непонятно? Скоро станет яснее.

2.2. Архитектура и реализация

Учитывая всё вышесказанное, можно поделить движок на три относительно большие части, которые соответствуют одноимённым java-пакетам:

1. display — содержит всё, что касается вывода пользователю любой информации (графической, текстовой и звуковой), а также приёма ввода от него. Своего рода вид (View), если говорить о MVC/MVP/etc.
2. initializer — содержит классы, в которых производится инициализация и запуск движка.
3. sl — содержит инструменты для работы со скриптовым языком (далее — SL).

В данном пункте я рассмотрю первые две части. Начну со второй.

В классе инициализатора есть два основных метода: initialize() и run(). Изначально управление приходит в класс лаунчера, откуда и вызывается initialize(). После вызова инициализатор анализируют переданные программе параметры (путь к директории с квестами и имя квеста для запуска), загружает манифест выбранного квеста (о нём чуть позже), инициализирует дисплей, выполняет проверку на то, является ли требуемая квестом версия языка (SL) поддерживаемой данным интерпретатором, и, наконец, запускает отдельный поток для консоли разработчика.

Сразу же после этого, если всё прошло гладко, лаунчер вызывает метод run(), который и приводит в движение фактическую загрузку квеста. Сначала находятся все скрипты, относящиеся к загружаемому квесту (о файловой структуре квеста — ниже), они скармливаются анализатору, результат работы которого отдается интерпретатору. Затем запускается инициализация всех сцен и инициализатор завершает выполнение своего потока, напоследок повесив на дисплей обработчик нажатия Enter’а. И вот когда пользователь нажимает Enter, загружается первая сцена, но об этом позже.

Файловая структура квеста следующая:

Имеется отдельная папка для квеста, в корне которой лежит манифест, а также три дополнительные папки: audio — для звукового сопровождения, graphics — для визуальной части и scenes — для скрипто, описывающих сцены.

Хотелось бы в двух словах описать манифест. Он содержит следующие поля:

• sl_version_req — версия SL, необходимая для запуска квеста,
• init_scene — имя сцены, с которой начнется квест,
• quest_name — красивое название квеста, которое отображается в заголовке окна,
• resolution — разрешение экрана, для которого предназначен квест (об этом пару слов чуть позже),
• font_size — размер шрифта для всего текста,
• font_name — имя шрифта для всего текста.

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

• соотношение ширины к высоте (aspect ratio) оставалось таким, как в разрешении из манифеста,
• было занято всё доступное пространство либо по ширине, либо по высоте.
  Благодаря этому разработчик квеста может быть уверен, что его изображения, например 16:9, будут показаны на любом экране именно в таком соотношении.

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

В двух словах о консоли разработчика. Она была разработана по следующим причинам:

1. Для дебага.
2. Если вдруг во время игры что-то пойдёт не так, оно может быть исправлено через консоль разработчика.
   В ней было реализовано всего несколько команд, а именно: вывод дескрипторов конкретного типа и их состояния, вывод работающих потоков, перезапуск дисплея и самая важная команда — exec, которая позволяла выполнить какой-либо SL-код в текущей сцене.

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

Его финальная структура имеет следующий вид:

Из постановки задачи можно сделать вывод, что всё, что придется делать, — это рисовать изображения, рисовать текст, воспроизводить аудио.

Каким образом обычно рисуется текст/изображения в движках универсального назначения и не только? Имеется метод типа update(), который вызывается каждый тик/шаг/фрейм/рендер/кадр/etc и в котором присутствует вызов метода типа drawText()/drawImage() — таким образом обеспечивается появление текста/изображения в данном кадре. Однако как только вызов таких методов прекращается, отрисовка соответствующих вещей останавливается.

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

Объект (с точки зрения ООП), который описывает текст/изображение, назовём дескриптором. То есть для пользователя API движка существуют лишь дескрипторы, которые можно добавить в состояние дисплея и удалить из него. Таким образом, в финальном варианте дисплея имеются следующие дескрипторы (они соответствуют одноименным классам):

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

Игровой цикл выглядит примерно так:

1. Обработка аудио — вызов метода update() на аудио-дескрипторах, который проверяет текущее состояние аудио, освобождает память (при необходимости) и выполняет другую техническую работу.
2. Обработка нажатий клавиш — передача введенных символов в дескриптор для приема ввода, обработка нажатий на клавиши скролла (стрелки вверх и вниз) и Backspace.
3. Обработка анимаций.
4. Очистка фона в буфере для рендеринга (в качестве буфера выступал BufferedImage).
5. Отрисовка изображений.
6. Отрисовка текста.
7. Отрисовка полей для ввода.
8. Вывод буфера на экран.
9. Обработка PostWorkDescriptor‘ов.
10. Кое-какая работа по замене состояний дисплея, о которой я расскажу позже (в разделе про интерпретатор SL).
11. Остановка потока на динамически вычисляемое время, чтобы FPS было равно заданному (30 по умолчанию).

Примечание: Возможно, возникает вопрос «Зачем рендерить поля для ввода, если для них созданы соответствующие текстовые дескрипторы, которые рендерятся на шаг раньше?» На самом деле рендеринга в пункте 7 не происходит — происходит лишь синхронизация параметров InputDescriptor‘а с параметрами TextDescriptor‘а — такие как видимость на экране, позиция, размер и другие. Это было сделано, как указывалось выше, по той причине, что пользователь не управляет напрямую соответствующим дескриптору ввода дескриптором текста и вообще о нём ничего не знает.

Стоит отметить, что задание размеров и позиций элементов на экране происходит не в пикселях, а в относительных размерах — числах от 0 до 1 (схема ниже). То есть вся ширина для рендеринга — это 1, и вся высота — это 1 (причем они не равны, о чем я несколько раз забыл и позже пожалел). Также стоило бы сделать, чтобы (0,0) был центром, и ширина/высота были равны двум, но я почему-то про это забыл/не подумал. Однако даже вариант с шириной/высотой равной 1 упрощал жизнь разработчику квестов.

Пару слов о системе освобождения памяти.

Каждый дескриптор имел метод setDoFree(boolean), который должен был вызываться пользователем, если он хотел уничтожить данный дексриптор. «Сборка мусора» для дескрипторов какого-то типа происходила сразу после обработки всех дескрипторов этого типа. Также аудио, которое проигрывалось один раз, автоматически удалялось после окончания воспроизведения. Ровно так же, как и не зацикленная анимация.

Таким образом, на данный момент можно рисовать всё, что захочется, однако это совсем не та картинка выше, на которой есть лишь фон, основной текст и поле для ввода. И тут вступает в дело обёртка над дисплеем, которой соответствует класс DefaultDisplayToolkit.

При её инициализации она как раз и добавляет в дисплей дескрипторы для фона, текста и т. д. Также она умеет показывать сообщения с опциональными иконкой, полем ввода и колбэком.

Тут всплыл небольшой баг, полное исправление которого потребовало бы переделывания половины системы рендеринга: если посмотреть на порядок отрисовки в игровом цикле, видно, что сначала рисуются изображения и только потом текст. В то же время, когда тулкит показывает изображение, он располагает его посередине экрана по ширине и по высоте. И если текста в сообщении достаточно много, то он должен частично перекрывать основной текст сцены. Однако так как фон сообщения — это изображение (полностью черное, но тем не менее), а изображения отрисовываются до текста — то один текст накладывается на другой (скриншот ниже). Проблема была частично решена вертикальным центрированием не по экрану, а по области над основным текстом. Полное решение включало бы в себя введение параметра глубины и переделывание рендереров от слова «совсем».

Пожалуй, на этом о дисплее, наконец, всё. Можно переходить к языку, весь API для работы с которым содержится в пакете sl.

3. Скриптовый язык

Примечание: Если уважаемый %USERNAME% дочитал досюда, то он молодец, и я попросил бы его не бросать это делать: сейчас будет значительно интересней, чем было до этого.

3.1. Язык

Изначально хотелось сделать декларативный язык, в котором нужно было бы лишь указать все необходимые параметры для сцены, и всё. Всю логику бы на себя брал движок. Однако в итоге я пришёл к процедурному языку, даже с элементами ООП (едва различимыми), — и это было хорошим решением, так как, по сравнению с декларативным вариантом, давало возможность многократно большей гибкости игровой логики.

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

Итак, код хранится в текстовых файлах с расширением SSF; каждый файл содержит описание одной либо больше сцен; каждая сцена содержит ноль или больше действий (action); каждое действие содержит ноль или больше операторов.

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

Возможно, вы жаждете увидеть наконец исходный код на SL, вот он:

scene dungeon {
    action init {
        load_image "background" "dungeon/background.png"
        load_image "key" "dungeon/key.png"
        load_audio "background" "dungeon/background.wav"
        load_audio "got_key" "dungeon/got_key.wav"
    }

    action first_come {
        play "background" loop

        set_background "background"
        set_text "some text"

        add_dialog "(оглядеться|осмотреться|(пошарить|поискать) (кругом|вокруг|что-нибудь))" "dial_look_around" dial_look_around on
    }
    //some comment
    action dial_look_around {
        play "got_key" once
        show "some text 2" "key" none

        tag "key"

        switch_dialog "dial_look_around" off
    }
}

Теперь становится ясно, что такое оператор. Видно также, что каждое действие есть блок высказываний (statement) (при этом высказыванием может быть и блок высказываний), а также то, что поддерживаются однострочные комментарии (вводить многострочные не имело смысла, к тому же я и однострочными не пользовался).

Ради упрощения такое понятие, как «переменная», в язык не вводилось; как следствие, все значения, используемые в коде, — литералы. В зависимости от типа выделяются следующие литералы:

Пару слов про парсинг языка. Имеется несколько уровней «загрузки» кода (схема ниже):

1. Токенизатор — модульный класс для разбиения исходного кода на токены (минимальные смысловые единицы языка). Каждый вид токенов сопоставлен с числом — его типом. Почему модульная? Потому что те части токенизатора, которые и проверяют, является ли какая-либо часть исходного кода токеном определенного типа, выделены из токенизатора и загружаются извне (из второго пункта).
2. Надстройка над токенизатором — класс, который определяет внешний вид каждого типа токенов в SL; на нижнем уровне использует токенизатор. Также именно тут происходит отсеивание пробельных токенов и пропуск однострочных комментариев. На выходе даёт чистый поток токенов, который и используется в…
3. … синтаксическом анализаторе (он тоже модульный), который и выдаёт абстрактное синтаксическое дерево на выходе. Модульный — потому что сам по себе умеет парсить только сцены и действия, но не умеет анализировать операторы. Поэтому в него загружаются (на самом деле, он сам их загружает в конструкторе, что не очень хорошо) модули, которые умеют парсить каждый свой оператор.

Теперь вкратце об операторах, чтобы появилось представление о функциональности языка. Изначально имелось 11 операторов, затем в процессе продумывания игры некоторые из них слились в один, некоторые изменились, и добавилось ещё 9 штук. Вот сводная таблица:

Операторы для работы со счётчиками — специфичными для сцены целочисленными переменными.

Была также мысль ввести оператор return (на уровне ядра интерпретатора даже была добавлена соответствующая функциональность), однако я забыл, да он и не пригодился.

Во время разработки квеста также возникла необходимость в таймерах с колбэками, но вводить новый оператор было лень, поэтому пришлось использовать следующий костыль: запускался show_motion с движением минимальной по размерам (ширина, например, 0.01) картинки за пределами сцены и временем таймера в duration.

На этом операторы заканчиваются и хочется сказать про такую возможность, как поиск (lookup) сущностей (ресурсов времени исполнения): многие операторы требуют указания названия аудио/изображения/счётчика/диалога, которые задаются в качестве параметра в операторах load_audio/load_image/counter_set/add_dialog соответственно. Фича в том, что можно указывать не только имя сущности, но и сцену, в которой он находится, — т. е. имеется возможность взаимодействовать не только с текущей сценой, но и с любой другой. Например, так: «scene_coast.dialog_1» — диалог dialog_1 в сцене scene_coast.

В загрузчик скриптов встроено не так много проверок на правильность SL-программы, как хотелось бы. Например, всё, что может выброситься на этапе загрузки скрипта, — это исключение о непредвиденном либо неизвестном токене. Во времени исполнения ситуация лучше: есть проверки на типы аргументов операторов (да-да, операндов), на их количество, на наличие запрашиваемой сущности во время lookup‘а, возможно, и другие, не помню. Однако нет таких проверок времени загрузки, как вызов только существующих действий или использование только существующих сцен в goto и lookup‘ах, а также проверки типов аргументов и многих других.

Кратко о диалогах. Приведу синтаксис оператора добавления диалога:

add_dialog "regexp" "dialog_name" callback on/off

Как я прочитал в википедии, очень важной частью любого движка для визуальных новелл с произвольным пользовательским вводом является анализатор ввода на естественном языке. Разумеется, я решил несколько упростить задачу: игра реагировала не на смысл, заложенный во фразе, а лишь на форму самой фразы, которая задавалась регулярным выражением (схема ниже).

Таким образом, если пользователь вводил текст, который совпадал с одним из регулярных выражений (первый аргумент) одного из включенных (последний аргумент) диалогов данной сцены, то выполнялся колбэк (третий аргумент). Для упрощения регулярных выражений пользовательский ввод подвергался следующей обработке: один и более пробельных символов заменялись на один пробел, боковые пробельные символы удалялись, текст переводился в нижний регистр, «ё» заменялось на «е».

Возможно, стоило сделать ещё удаление знаков препинания (знаков вопроса, в частности)

Пример регулярного выражения для диалога, обозначающее «осмотреться»:

(оглядеться|осмотреться|((посмотреть|пошарить|поискать|осмотреть) (все )?(кругом|вокруг|все)?)|(обыскать|осмотреть|обшарить)( кусты)?|осмотреть все вокруг)

***

Учитывая всё вышесказанное, можно увидеть аналогию с ООП: сцены — классы, все члены которых статичны и публичны, а действия — методы.

Полагаю, в максимальном упрощении языка был и плюс: порог вхождения в него очень низок

3.2. Интерпретатор

Рассказывать про сам интерпретатор особо нечего: он тоже модульный, модули — это «исполнители» операторов (по одному для каждого). Больший смысл имеет рассказать про специальные действия и смену состояний дисплея.

Для самого SL специальных действий не существует, но для интерпретатора они все-таки есть. Вот они:

1. init — вызывается во время загрузки ресурсов и предназначен только для загрузки ресурсов, и ничего более (как уже описывалось, загрузка производится до показа первой сцены, следовательно, выполнение любых других операций небезопасно).
2. first_come — вызывается, когда игрок впервые посещает данную сцену. В ней обычно устанавливается фон, основной текст, включается музыка и добавляются диалоги.
3. Во время работы над игрой стало понятно, что не хватает следующего действия: come — вызывается всякий раз когда, игрок посещает данную сцену (является опциональным).

Примечание: init и first_come — вместе составляют некое подобие конструктора, что ещё раз намекает на легкий объектно ориентированный оттенок языка.

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

Таким образом, в памяти наличествует одновременно n сцен, и для первой из них уже выполнено first_come-действие (то есть какие-то сущности уже добавлены в сцену и какие-то дескрипторы уже имеются в дисплее). Теперь нужно сделать систему переходов между сценами. Казалось бы, что здесь сложного: требуется лишь поддерживать список уже загруженных сцен, и если сцена еще ни разу не посещалась, вызывать first_come и come, иначе только come (если имеется). Но было важное требование: если в сцену переходят не в первый раз, то ее состояние должно полностью соответствовать состоянию во время последнего выхода из нее, вплоть до продолжения воспроизведение аудио с той же секунды, на которой оно было остановлено при выходе.

Это состояние состоит из состояния дисплея и состояния тулкита (обертки, которая добавляет понятие «фон», «основной текст», «поле для ввода» и т. д.). Стало понятно, что нельзя просто выбрасывать эти состояния, а их где-то надо хранить и как-то заменять. Проблема была в том, что все дескрипторы дисплея и тулкита хранились прямо в классах их представляющих (в полях), а сохранять вручную с десяток объектов никоим образом не хотелось.

На помощь пришла композиция и выделение состояния дисплея и тулкита в отдельный класс (что, вероятно, нужно было сделать сразу). Оставалась одна проблема: каким образом заменять состояния с текущего на старое? Ведь нельзя же во время игрового цикла, а именно во время итерации по спискам дескрипторов, просто взять и заменить эти списки. Поэтому тут пришлось добавить метод provideState в дисплей, в который передавался колбэк и состояние для загрузки; а после завершения очередной итерации игрового цикла это состояние заменялось и вызывался колбэк, в котором происходила замена состояния тулкита.

Ещё был нюанс с остановкой воспроизведения аудио, да так, чтобы само аудио не подумало, что оно было полностью воспроизведено, и не самоуничтожилось (так как оно автоматически очищается, если было полностью проиграно), но это решилось введением пары методов и флагов (которые, вероятно, были избыточными и заменялись уже существующими, но это не точно).

4. Разработка игры

Тут я кратко опишу саму игру и процесс её разработки. Как в 2019-м и 2018-м, я решил начать с чего угодно, кроме графики, и начал с истории.

4.1. История и разработка логики игры

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

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

Как оказалось, для разработки задуманной игры мне не понадобилось 25% (5) существующих операторов, а именно: все операторы, связанные со счётчиками; оператор анимирования (animate), а также оператор внешнего вызова (call_extern).

Помимо основной игры, для ознакомления игроков с кор-механиками игры был разработан демоуровень (скриншот ниже), который состоял из одной сцены (двух, если быть точным, но вторая — просто заглушка, типа «You won»).

4.2. Графика

Во время разработки логики и тестирования вместо изображений использовались заглушки, как видно на скриншоте ниже:

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

• Рисовалось всё на графическом планшете (4×2.23»), во многом только благодаря ему с графикой многое удалось.
• Для рисования были выбраны только три цвета: черный, почти белый и оранжевый, — что сформировало достаточно интересный стиль.
• После рисования обычными круглыми кистями использовалась обработка художественными для придания эффекта царапин/тумана/шума/реалистичности/etc.

• Персонажи рисовались без лиц, что сильно ускорило работу, при этом ничего не испортив.

• Интересно, что некоторые части фонов рисовать не было надобности. Как видно на скриншоте до ката, они скрываются черной подложкой текста, следовательно, в этой месте фон можно оставить пустым. Это также дало значительное ускорение.

5. Статистика и итоги

На разработку первой версии движка и языка (с 11 операторами) у меня ушло 30 часов 40 минут. На реализацию дополнительных 9 операторов ушло ещё 4 часа 55 минут. Разработка логики непосредственно игры (вместе с демо) потребовала 7 часов 41 минуты. Рисование графики — ~4-6 часов (графика не учтена в 45 часах из заголовка).

Примечание: Время кодинга мерялось через расширение «Darkyen’s Time Tracker» для продуктов JetBrains (абсолютно не реклама).
Примечание: Я начал писать это все за 2 дня до Нового года, но не успел — релиз пришлось перенести на Рождество. Так что 45 часов из заголовка были распределены примерно на 8 дней.

Количество чистых строк кода для движка: 4777, для игры (без демо) — 637.

Примечание: Количество строк мерялось через cloc.

Целью было создать 30 минут игрового времени. В итоге прохождение (с моими подсказками) заняло: демо — ~8 минут, основная игра на первую концовку — ~24 минуты, на вторую (с быстрым прохождением до момента разветвления) — ~8 минут. То есть план был выполнен.

Размер квеста — 232 мегабайта (так много из-за музыки, записанной в WAV).

Было нарисовано 28 изображений (и ещё 3 для демо). Это была моя первая игра с адекватным аудио сопровождением — всего с просторов интернета было скачано и запихнуто в игру 17 единиц звуков/музыки.

Все жалобы на игру заключались в абсолютно не юзер-френдли интерфейсе ввода: очень часто регулярные выражения не покрывали вводимых фраз, хотя смысл этих фраз был более чем верный. То есть, например, игрок вводил «вставить ключ в дверь», а предусмотрено было лишь «вставить ключ». Однако были и моменты (один, насколько я помню), когда пользовательский ввод с первого раза совпадал с задуманным (и это было даже не «да»/»нет» или что-то очевидное).

Также я считаю, что не смог адекватно раскрыть историю: остались недосказанности, непонятные моменты и даже маленькие противоречия.

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

Теперь к коду. В целом качество кода меня устраивает (хотя это ещё ни о чём особо не говорит), однако есть следующие моменты:

• Нет тестов. Совсем нет. Это плохо.
• Имхо в коде многовато колбэков. И хоть они все вроде бы очевидны и еще не превратились в колбэк хэл, но тем не менее.
• Много мелких вещей, которые разбросаны в коде тут и там.

Кстати, во время игры багов выявлено не было и всё отработало без единого краша, что приятно.

Исходный код движка может быть найден по данной ссылке на GitHub.

Демо и основная игра находится в файлах (assets) в разделе «Releases» для версии «v1.0» там же.

Создай свою визуальную новеллу, не умея рисовать/создавать музыку и программировать.

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

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

– Но как быть, – спросите вы, – если я совсем не умею программировать, и при этом у меня нет знакомых художников/музыкантов/кодеров?

– Ответ прост: создать новеллу на сайте «BestNovels», как это сделал я.

Что такое «BestNovels» и с чем их едят?

«BestNovels» – сборник интерактивных историй, который открылся совсем недавно, что дает возможность новым авторам быстро занять лидирующие позиции в ТОПе (если ваша история в достаточной степени хороша, разумеется).

Жанры. В каталоге сайта присутствует 8 жанров на выбор: Боевики и приключения; романтика; детективы и триллеры; ужасы и мистика; фэнтези; юмор и расслабление; фантастика; фонд SCP. При этом, создавая новеллу, вы можете выбирать до 3-х включительно – например, фэнтези и романтика, как сделал я.

Кроссплатформенность. Безусловным плюсом сайта «BestNovels» является тот факт, что проходить любимые визуальные новеллы можно не только на компьютере, но и на телефоне, когда едешь в общественном транспорте, не испытывая никаких подвисаний и даже не переворачивая свое устройство, – а это значительно расширяет аудиторию автора.

Конкурсы. Создатели сайта активно привлекают новых авторов, в связи с чем часто проводятся конкурсы с крупными призовыми (а это ли не возможность для молодых рассказчиков?). Причем номинаций очень много, начиная от создания статей и заканчивая летсплеями.

Свобода. Модераторы зорко следят за тем, чтобы не пропустить некачественный контент на сайт, но вместе с этим к авторским правам здесь относятся не так жестко, как в том же Steam. По этой причине автор на 90% свободен в выборе музыки, фонов и артов персонажей, что позволяет полностью придерживаться первоначальной задумки, не опасаясь того, что вас могут забанить.

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

Мозговой штурм. Данный плюс распространяется не столько на сайт, сколько на жанр визуальной новеллы в целом. Если вы делаете новеллу из уже готовой истории в виде, например, рассказа (как сделал я), то для вас это будет отличной тренировкой и мозговым штурмом – необходимо же придумать развилки и то, куда могла бы привести история, если бы что-то пошло по-другому. Это опять-таки заинтересует читателя и заставит его по-другому посмотреть на вашу историю –– например, кто-то злобно высказался по поводу вашей работы из-за ее финала, и вы тут же отсылаете его на «BestNovels», где он сможет сам решить, как поступит протагонист.

Как работать с «BestNovels»?

Пожалуй, еще нигде и никогда нельзя было так просто создать свою визуальную новеллу, как на сайте «BestNovels». Все, что вам нужно, как автору и разработчику, сводится к написанию истории и подбору для нее музыки и фонов. Вам не нужно знать никаких языков программирования! Только свобода творчества и фокусировка на том, что вы умеете делать лучше всего – писать.

В движке сайта все интуитивно понятно и до безобразия просто (говорю как человек, раннее создававший модификацию для «Бесконечного лета», где все-таки приходилось учить обозначения и некоторые команды).

Кликом создаете клеточку (т. е. сцену), ставите фон, персонажа (если нужно) и музыку. Пишете текст и вуаля – отправная точка вашей истории готова!

Нужен выбор? Без проблем. Нажимаете соответствующую кнопку в виде развилки, пишете варианты ответа/действия и ставите направление, куда перекинет игрока в зависимости от его решения – вправо, влево, вниз или даже вверх.

А что, если после выбора игрока нужно отправить не в следующий эпизод, а, скажем, на другую линию вообще? Не беда, есть такой замечательный инструмент как «портал», где мы прописываем номер столбца и строки, куда отправится игрок.

– А что насчет переменных? Можно ли делать в новелле романтические линии, от которых будет зависеть концовка? – настойчиво спрашиваете вы.

– Конечно, – отвечу я.

Создаете в соответствующей вкладке переменную. Например, «отношение», как делал я. Затем создаете развилку и привязываете ее к нужной переменной – направо пойдешь, +1 получишь; налево пойдешь, ничего хорошего не получишь.

И именно здесь на сцену выходит такой элемент как «рельсы». Вы связываете их с переменной; затем движок сам высчитывает сколько всего очков можно набрать; и затем вы делаете полноценную сюжетную развилку, связанную с переменной! Например, если герой не сблизился с героиней вообще (0 очков), игра отсылает его налево; если сблизился средне (1 очко), отсылает его вниз; и наконец если сблизился как надо (2 очка), отсылает его направо. Как вы поняли, это прямо влияет на концовку.

Наконец ваше детище готово. Что делать дальше? Отправлять на модерацию, прописав аннотацию, выбрав жанры и поставив обложку. Модераторы проверят и вынесут вердикт, после чего ваша новелла попадет на сайт.

Подводя итог, скажу, что создание полноценной визуальной новеллы на движке «BestNovels» – процесс хоть и монотонный (особенно, когда дело доходит до расставления музыки и проверки общей работоспособности), но весьма интересный. Очень приятно сделать какую-то сцену, потом открыть ее и увидеть, что все в ней – текст, музыка, виузал, – работает так, как ты хотел, погружает в невероятную атмосферу и не дает оторваться от чтения. Ведь согласитесь, книга кажется куда увлекательнее, если на фоне играет подходящая музыка.

Дополнительные ссылки