|
#вопрос
#визуальные_новеллы #вн Появился вопрос по проектированию визуальных новелл, но этот вопрос скорее не к писателям, а к инженерам или даже математикам. Если кто-то удивлён, то попробуйте прочитать постановку задачи. Вдруг заинтересуетесь? Такая вот занятная штука, эти визуальные новеллы. Одна из ключевых особенностей ВН — возможность читателя выбирать варианты действий протагониста, тем самым выбирая разные ветки сюжета. И вот тут возникла задача, которую я не смог так сразу решить. Для примера рассмотрим простейшую ВН, где главный герой кун выбирает одну из двух тян. Самый примитивный случай — это тупо предложить читателю выбор в духе: Я выбираю: После выбора из этого меню дать прочитать соответствующий вариант сюжета.1. A-chan 2. B-chan Очевидно, что такой примитивный способ выбора не содержит никакой интриги — получится максимально унылое говно, какое только можно представить. Намного менее унылым будет следующий подход. Надо предусмотреть нечётное количество выборов с двумя вариантами ответов. Каждый такой ответ ведёт к небольшим отличиям в тексте, после чего сюжет возвращается к общей линии (это важно, чтобы не было десятков и сотен вариантов сюжета). Но при этом, в зависимости от выбранного варианта увеличивается один из счётчиков, AChan_count или BChan_count. Поскольку таких выборов нечётное количество, то в итоге AChan_count никогда не будет равен BChan_count. И вот потом общий сюжет идёт до драматической развилки, где кун задаётся вопросом, кого же ему выбрать. Долго и драматично думает и уже без участия читателя выбирает ту тян, у которой счётчик больше — предпочитал её в тех вариантах выбора, значит она ему больше нравится, после чего сюжет сворачивает на одну из концовок. А вот теперь этот подход надо обобщить. Во-первых, у нас может быть не две концовки, а больше. Например: 1. A-chan 2. B-chan 3. C-chan 4. D-chan 5. Bad end (так и не смог выбрать и остался ни с чем) 6. True end (сознательно решил, что «нафиг эти тян, поищу другую»). Во-вторых, предлагая читателю сделать выбор, мы можем давать больше двух вариантов ответов. В-третьих, предыдущие ответы могут влиять на то, будет ли доступен какой-то выбор вообще. Просто наличие выбора должно быть уместно для сюжета, а предыдущие ответы могут это исключать. И вот как обобщить предыдущее правило? С двумя концовками и двумя вариантами ответов было просто — нечётное количество выборов. А здесь как подойти к проектированию, чтобы можно было выходить на все концовки, причём каким-то управляемым способом? А не так, что почти все варианты ведут к одной концовке, а на некоторые вообще выйти нельзя и надо всё переписывать. Вроде для подсчёта путей должен получиться граф или какая-то ещё комбинаторная конструкция. Но у меня ступор — я никак не могу сообразить, как формализовать эту задачу. 2 ноября в 12:42
|
|
nullitte, вы совершенно верно рассуждаете с точки зрения художественной части. Но вы упустили из виду условие задачи. Вот та примитивная гипотетическая ВН имеет только две концовки (A-chan и B-chan). Там вообще нет никакого Bad End. И там каждый выбор просто добавляет 1 в один из счётчиков (считаем для примитивной ВН, что все ответы равнозначны). Именно в этом случае такой простой приём, как нечётное количество выборов, позволит избежать ничейного исхода — иначе бы пришлось добавлять Bad End, либо при равенстве принудительно «нечестно» выбирать одну из концовок.
Показать полностью
И вот эту же идею я распространяю на более сложные случаи. Например, если один персонаж более сложный, то за правильный выбор для него будет добавляться меньше баллов в его переменную. Поэтому надо сделать больше выборов в его сторону, чтобы он победил — вроде того. Но это всё равно не исключит возможность ничейного исхода. Например, если есть 6 выборов, сложному персонажу добавляется по 1 баллу, а простому по 2. И если читатель выберет 4 за сложного и 2 за простого, то мы получим 4 и 4 у обоих — опять ничья. А если сложный персонаж сложнее не в 2 раза, а в 2.5? А если вопросы неравнозначны и надо добавлять баллы в разных пропорциях? А если персонажей несколько, и у всех разные уровни сложности? Как предусмотреть все варианты, чтобы никогда не выходила «ничья»? Если ввести Bad End и сливать в него все непредусмотренные случаи, то так можно решить задачу на практике. Так и делают в реальных ВН, некоторые из которых очень даже популярны. Но мне сейчас интересно именно решение математической задачи. Чисто научный интерес — на практике скорее всего буду сливать в Bad End. Просто мне надо написать ВН в практических целях, но и теоретического интереса практика не отменяет. |
|
|
Odio inventar nombres
либо при равенстве принудительно «нечестно» выбирать одну из концовок. Я как раз и говорю о том, что ничья по очкам вполне может приводить к тому, что игрок получает более простую концовку из возможных. Нет ничего "нечестного" в том, что одну концовку получить проще, чем другой. |
|
|
Банально нагадить счётчиками переменеых на любой чих, а после поблизости от перехода на концовку выдать несколько слайдов с текстовым прокликом, одинаковым для всех в одну строку внешне, но на деле игрок видит лишь один из вариантов, так как остальные скрыты от него, так как у него А больше всех остальных счётчиков с тянками, или же ни одно из значений не оказалось больше условного счётчика 10, все четыре варианта получили лишь по паре плюсовых взаимодействий, потому игрока ведёт далее по концовке "нафиг всех" или же 10тки набрались, но он ранее сознательно выбрал выбор с таким вариантом и поэтому ему показывает тот же слайд, но видим лишь вариант текста, где в счётчике конкретно 1 уникальной функции для этого выбора указана единица, а для всех остальных же прописано, чтобы этот счётчик был нулевым?
Показать полностью
А для более простого/сложного персонажа при равенстве значений счётчиков - тут или стараться, чтобы они физически не могли сравняться, или прописывать условие, что если а=>b то выбирается а. Если, и только если если b>а, выбирается б. А что из этого предпочтительней как более доступный вариант - это уже решает сценарист. Можно же на городить и связь с каким-нибудь левым счётчиком, где b выбирается при равенстве вместо а, но если третий счётчик имеет какое-то значение. Типа если он по характеру няшка-милашка, ему будет с б качать отношения проще, чем при другом характере, или там в какой-то момент сюжета сделал что-то для б важное, хоть и не идущее в его конкретный счётчик. Ну или всунуть рандомайзер при равном значении. Но прямо честно и ровно не получится никак. И более сложный для получения хоть на одну строчку рут персонажа игроки все равно будут считать за истинную концовку, даже если всем ясно, что для более простой и доступного персонажа автор влил весь свой фаворитизм, буквально навязывая его, а значит истинная концовка - простая. 1 |
|
|
Если временно оставить чисто математический анализ задачи, поскольку я даже не представляю, как к нему подступиться...
Показать полностью
Насчёт практического подхода сейчас подумал следующее. Мы немного расширяем идею переменных AChan_count и BChan_count из примера в посте. Теперь это будет не счётчик, а скажем, репутация у A-chan и B-chan. Или склонность к какой-то концовке в более общем смысле, ведь концовка может вообще не быть связана с персонажем. Ну, пусть будет у переменных префикс Rep. Итак, на старте мы имеем что-то вроде Rep_AChan = 0 Rep_BChan = 0 Rep_CChan = 0 Rep_DChan = 0 Rep_TrueEnd = 0 Эти переменные делаем с плавающей точкой, меняем их все при любом выборе, причём значения приращений делаем не идеально равными, что-то вроде «Выбор ответа, понравившегося A-chan, B-chan, безразличного C-chan, не понравившегося D-chan и не ведущего к True End»: Rep_AChan += 2.5 Rep_BChan += 2.49999 # Rep_CChan += 0 Rep_DChan -= 2.2 Rep_TrueEnd -= 2.19999 Перед финальным поворотом сюжета надо просто выбрать максимум. При вот таких отличиях, вроде 2.5 и 2.49999 ничья будет достаточно маловероятна, чтобы её можно было проигнорировать. Потом максимум надо сравнить с некоторым пороговым значением, которое можно посчитать исходя из суммарных значений этих приращений по разным путям (просто забить их в простую программу на C в массив и посчитать все пути тупо перебором). Вариант: пороговое значение может зависеть от концовки. Если максимум превышает порог — выбираем концовку. Иначе — jump bad_end. В принципе, народ что-то подобное и делает. Чтобы не мудрить с ничьей, добавил вот эти мелкие отличия в приращениях. Их даже можно обосновать сюжетно — ведь не может же быть, чтобы два персонажа реагировали полностью одинаково. Разумеется, если бы я планировал какой-нибудь дейтсим или более сложную игру, то можно было бы напридумывать специальных объектов под неё. Но я всё же склоняюсь к тому, что у меня будет скорее книга, чем игра. Почти линейный сюжет с мелкими выбираемыми деталями, рассказывающий общую часть истории. А потом на основе ранее сделанных выборов происходит одно ветвление на несколько концовок, где можно рассмотреть несколько вариантов последствий этого выбора (как фанфики пишут часто с вопросом «а что, если бы...»). Поэтому для меня на практике такая простая система вполне подойдёт. Вроде бы, если не найду подводных камней. Но с теоретическим анализом всё же было бы интересно разобраться. Увы, мне пока даже в голову не приходит, как формализовать такую модель. |
|