В начале осени я анонсировал что уже некоторое время работаю над инструментарием, который позволит создавать продвинутые текстовые новеллы с помощью визуального программирования. Прошлый раз я наскоком пробежался по основным моментам, сейчас я могу рассказать обо всем более детально.
Наглядная демонстрация из старой статьи:
Кстати, теперь есть название — Qito: a narrative-driven game engine.
Думаю, стоит начать с основных изменений и нововведений. Уточни, что я не работал над проектом все время, часто делая перерывы и переключаясь на что-то другое.
Сейчас я делаю основной упор на удобный, приятный и быстрый интерфейс — это для меня наиболее важные характеристики. По итогу я смог перенести и адаптировать работу управляющих нод прямо из рабочего пространства: все данные «игровых выборов» и «менеджеров повествования» можно изменять в реальном времени, здесь и сейчас, без каких либо отдельных меню настроек..
Игровой выбор — игрок должен сделать выбор из нескольких вариантов, каждый вариант — это набор изменений и требований, которые игрок должен соблюсти, чтобы вариант был доступен.
Вы наверняка видели подобное во многих играх, визуально это выглядит примерно так:
Менеджер повествования — нода, которая также содержит набор вариантов. В отличии от «выбора» — менеджер работает автоматически.
Пример. Автор добавил развилку в середине второй главы:
1. Если игрок сделал [A, Б,С] то повествование будет идти по линии 1.
2. Если игрок сделал [A, В] то уже линия 2.
3. Если ничего не подошло — то автоматически выбирается третий вариант.
Также есть третья нода — и основная — контент. Один блок может содержать неограниченное количество книжных «разверток»: левая и правая страницы. Поддерживается форматирование текста, персонажей, изображений и подобного. Реализовано на основе открытого проекта editor. js
Копаем вглубь
А теперь к более интересным тектоническим особенностям: )
В версии от сентября еще не было поддержки локальных ассетов — да, можно было вставлять изображения, но они работали только по ссылкам. Теперь же есть полноценная загрузка изображений в локальное хранилище проекта, и соответсвенно подгрузка файлов их него. Сейчас. поддерживаюся только изображения, но аудио файлы также будут.
Сжатие и кодирование изображений сделано на основе замечательного squoosh.
Вторая большая доработка — написан базовый универсальный редактор базы данных. Основное требование — реал тайм. Изменения должны прилетать и отображаться во всех местах, где отображается или используются измененные данные.
Из важного — пришло понимание что без пользовательских переменных никуда, так что да, теперь есть базовые number, string и boolean.
Сделана базовая поддержка ключевых слов для нод и поиск:
Последние крупное изменение, — сложно заметить слона в комнате, — полностью переработан внешний вид редактора. Да, то тут то там есть недоработки и временные решения, но на фоне прошлой версии — это мелочи.
Планы
На самом деле большая часть работы так и осталась за кадром — я переписывал ядро, упрощая архитектуру и код, правил оптимизацию, придумывал и пробовал десятки разных идей для визуального взаимодействия с нодами.
Одних только набросков отображения данных в выборах было с десяток — стоит ли все действия выводить в контекстное меню? Стоит отображать данные в свернутом виде? А если контекстное меню, то для контейнеров и правил в контейнерах они должны быть разные? А как лучше обозначить что это — переменная, а это — персонаж?… А что насчет производительности?…
Морока с блоками правил и изменений и правда была большая, но теперь это отличная основа для всех возможных будущих типов нод, в которых есть переключатели или нечто подобное.
Сейчас я планирую начать работу над новой основой для игрового клиента, которая также будет включена как режим «предпросмотр» в игровой редактор. Изменений в ядре уже набралось так много, что лучше написать клиент снова с нуля, учитывая найденные проблемы спустя время: D
А дальше длинный список фич, вроде аудио дорожек, вложенных переменных, игровых событий и прочего-прочего-прочего. В далекой перспективе — поддержка визуальных новелл.
А теперь ложка дегтя: (
Пощупать пока нельзя, исходники также закрыты. Я сейчас стал неуверен в каком именно состоянии я планирую выпустить (когда, и если, это произойдет) проект в публичный доступ. Пока думаю об ограничено отрытых исходниках и бесплатных билдах на их основе, без контроля что и где будет выпускать на основе движка — хотите хентай, делайте. Хотите в стим — будет сборка для стима.
Но до ранних билдов и исходников пока рано, меня не устраивает качество кода и состояние проекта. Следующий большой новостной апдейт будет ближе весне, думаю. Вообще, я нашел столько разных подводных каменей и их решений, что думаю написать серию статей на английском и для более специализированных площадок.
— Пустой дискорд сервер для связи, чтобы не теряться.
— Загрушка-репозиторий на гитхабе:
На чем делается: Electron, vue3, открытые библиотеки вроде editor. js, tippy. js, uuid […] и много-много своего кода.
В итоге у тебя должно получится нечто вроде генератора текстовых квестов о для космических рейнджеров?
Очень похоже, но на спидах, большой кастомизацией и возможностью собирать билд в отдельные приложения
Что тебе плохого юзеры сделали....
Спустя полгода я могу сказать что он норм, даже большой вес из-за оверхеда можно уменьшить до 110мб, что не так критично.
Но нужно иметь бэкграунд, с большим опытом оптимизации производительности под веб, из-за сотен подводных камней, которые человек извне просто не может знать.
Согласен, лучше просто онлайн версия
На это мы подписываемся и репостим 👍
Выглядит прям мощно! Ждём релиза в Стиме)
Хороший инструмент для подобного, кому предпочтительнее редактирование в текстовом виде:
https://yarnspinner.dev/
Вообще, под прошлой статьей много хороших советов набралось, даже некоторые визуальные решения есть. (Есть кто-то ищет — может помочь)
Нечто похожее было для создания собственных квестов в Космических Рейнджерах 2.
На чем пишешь и что используешь?
Это мы ждем, куплю даже за... ДЕНЬГИ)
Для мастера ДнД хорошо подойдёт)
Приятно видеть, что-то действительно масштабное и интересное для разработки
Ждём релиз)
Обязательно попробую.
Если есть толковый гайд по использованию. И задоначу👍
Комментарий недоступен
А как ты ещё предлагаешь структурировать диалоги и писать их чтобы не упустить повествование? Диалоги — есть ветвление с вариативностью в зависимости от обстоятельств.
не согласен, если есть поддержка переменных и условные переходы.
Такая структура позволяет хотябы удержать в голове 100500 развилок.
Сейчас тоже делаю проект, но завис на стадии выбора фреймворка.
Изначально делал на электрон+реакт, но получил свою долю критики изза выбор х_х все же электрон прожорливый.
Интересно, почему был выбран именно этот стек?
Электрон прожорлив, здесь трудно что-то отрицать. Но плохая репутация в основном из-за простой точки входа в js в целом. Наибольшая проблема из-за физического объема сборок — +110мб оверхеда при почти что всех разумных оптимизациях.
Выбор обусловлен в первую очередь большим опытом с вебом, интересом к typescript и необходимостью кроссплатформенности
На первый взгляд не понятно в чем отличие от самого популярного, пожалуй, инструмента Twine - https://twinery.org/
https://itch.io/games/tag-twine
Если же это не альтернатива Twine, большой вопрос - как это интегрируется в игровые движки? Без них тулза будет не так важна: stand alone решений хватает, а полноценный игровой движок с высокой гибкостью ты сам не сможешь сделать.
Еще один момент - насколько удобный синтаксис, чтобы править файлы по живому и проверять результат в редакторе, используя воспроизведение. Ручками ориентироваться может быть сложнее (например, хотим изменить одинаковый текст/условие в 50 местах).
https://www.inklestudios.com/ink/
Есть такой инструмент Ink, от создателей серии Sorcery! и ряда других игр
(https://store.steampowered.com/developer/inkle)
Его синтаксис очень гибкий и продвинутый, поэтому графический редактор там, пожалуй, будет даже менее эффективным. Все рассчитано на написание повествования и логики условий в виде текста. Из минусов - нет встроенного инструмента визуализации флоу истории, что все-таки является плюсом для быстрой оценки логики больших проектов.
Он интегрируется в другие движки, и позволяет разделить игровую логику и стори теллинг.
Под прошлой статьей обсуждалось, если правильно помню, то:
1. Twine публикация в html, кривоват, нет билда в stand-alone, нет многих штук из коробки plug-n-play (возможно их можно сделать самому через js).
2. Ink — совершенно другая аудитория; ориентация на работу с текстом через подобие markdown, и работает только-только инструмент для последующей конвертации к себе.
Интеграция в игровые движки — в первую очередь делается самодостаточный инструментарий со сборкой под win/macos/linux из-за кроссплатформенности электрона, это уже сделано. Но формат не проприетарный, все игровые данные это json конфиги и папка с ассетами — это не закрывают возможность для написания плагина для того юнити.
От правки руками я как раз стараюсь убежать, это оказалось адом при работе с большим количеством текста; правка в 50-ю местах исправляется либо вложенными нодами, либо нодами-шаблонами. Это не анонсировано, но есть.
Что отображается в поддержке 3D? там есть возможность запуска анимаций или прокрутка камер?
Да, полноценная поддержка простых шейкеров, 3д объектов и освещения + камера. Работает через прослойку к three.js
Degrees of Lewdity собрать можно будет? Тогда нормально.
Короче:
- возможность задать иллюстрацию с использованием отпозиционированных gif файлов на основании внутренних переменных
- виджеты (типа функции) и теги, стопорящие выполнение каких-то вещей.
А что у тебя там под капотом - узбагойся, это как дырявые труселя под бальным платьем: никто не видит.
Кстати, могу предложить небольшой коллаб, я хочу свою идею закончить, а для тебя - как раз USP будет.
Ну и из критиканства:
1. Не хватает точек для кривых безье и разрывы линий.
Блок-схема растягивается до неприличия и не хватает инструмента для контроля.
2. Не хватает поддержки ГОСТ 19.701-90 + небольшого гайд по Дракону.
Блок-схематика она и есть блок-схематика. Всегда удобная штука, а Дракон - это методика, корорая позволяет дебажиться эффективнее.
https://habr.com/ru/post/541478/
3. Опционально: не хватает поддержки стековых сценариев по типу форта (либо собственно, минимальную реализацию форта на 27 команд от GA144 + каждый текстовый блок = "слово"). Иногда строку "?жив если !сходни иначе !дальше тогда" ввести проще.
PS: ну нафига электрон?? Может ещё денуво накатить сверху, так, чисто для проформы? Чем ванильный яваскрипт в HTML не устраивает?
Отзываю предложение коллаба, мараться об Электрон желания нет.
Забыл ответить, управляемые токи для кривых Безье есть, просто их отображение сейчас скрыто.
Блоксхемы нежизнеспособны вне визуализации алгоритмов; занимают слишком много места, интуитивность умирает из-за четких выделяющихся форм.
Электрон позволяет собирать билды и дает полноценный доступ к файловой системе через ноду :)
Это мы поощряем) Вот столько инструментов для разработки игр, бери да делай. Разбередил мечты о визуальной новелле) Осталось всего лишь силы и время найти))
Чел, есть fb2, лол
Это абсолютно другое ._о
Интересный проект. Я делал проекты на TWINE, Renpy, Celtix, и щупал несколько не визуальных движков типа Ink и еще сколько-то. Я сейчас пишу в Scrivener. Много чего можно сказать. Но пока больше вопросов.
Сейчас вообще все реализую в почтовой рассылке, включая ветвления и т.п. Там много минусов, но и много плюсов.
Хочется узнать больше, и главное какой output? К примеру TWINE дает HTML+JS, Renpy, а Renpy b какой-нить Visual Novel Maker - билд.
Ориентируюсь именно на сам редактор и уже клиент, как второстепенно. Редактор работает с json конфигами, в которых прописывается вся информация; рядом с json’ами лежит ассеты вроде изображений. Будет документация для возможности встроить в другой движок.
Встроенная сборка будет на основе электрон клиента без сильной кастомизации.