www.mudconnector.su

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

Все пишется на материале mud "Былины".

Вводная информация.

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

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

Формулировка проблемы.

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

Вторая проблема, о которой я и хотел бы написать -- игромеханическая. Квесты представляют собой разрозненную кучу сценариев, без каких-то единых механизмов. То есть.
- Нет какой-то сводной информации о квестах в целом, статистики (разве что в виде файла на компьютере администратора игры).
- Нет также и формализации правил -- вот это квест на 1-10 уровни, а на 11 и выше уровне на нем уже не дают опыта. Конечно, несложно написать в сценарии конкретного квеста такую проверку. Ну а если квестов десять? Сто? Если вы сами уже не помните, где какой?
- Нет возможности гибко манипулировать параметрами группы квестов. Например повысить выдачу награды членам клана, который контролирует город, где "живет" NPC выдающий задание. Или урезать выдачу опыта для квестов на 10-20 уровень.
- Каждый новый квест пишется "с нуля", хотя абсолютное большинство квестов сводится в общем-то к действиям "убить N указанных монстров", "принести N названных предметов", "пройти из точки А в точку Б". В разных сочетаниях, по-разному лбставленные, но эти элементы лежат в основе практически всех квестов в мадах.

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

Предлагаемое решение.

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

- Хранение информации по квестам в целом и каждому квесту в отдельности.
- Стандартные проверки на выполнение условий по взятию квеста. От уровня персонажа, до репутации у игровых фракций, если таковые есть.
- Регистрация факта взятия и выполнения квеста -- опять-таки стандартным образом.
- Отслеживание процесса выполнения задания, то есть прохождения персонажем этапов квеста, без "ручного" отслеживания состояния переменных и тому подобного.
- Информирование игрока о квесте, в объеме, предусмотренном разработчиком. Факт взятия, суть задания, прохождение этапов, факт выполнение, обещанная награда.
- Возможность сбора статистики по квестам, манипулирования параметрами как отдельного квеста, так и целых групп, выделяемых по разным признакам (уровень, тип награды, расположение, доступ по классам и так далее).

Резюме

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

Недостаток -- квест можно содержать только стандартные этапы, которые уже заложены в квестовый фреймворк. Если в нем не предусмотрен этап "подойти к NPC, предварительно надев 3 предмета из списка, содержащего 10 пунктов", то для добавления такого этапа придется или обращаться к кодерам, или вернуться к "старой школе" исполнения квестов. Возможным вариантом решения мне видятся вставки "скриптовых" этапов, подобно тому, как в листинг кода можно вставить участок на ассемблере. Условие -- скрипт по завершению должен оставить "состояние" квеста в виде, понятном фреймворку. Впрочем, если в фреймворк изначально заложено достаточно много вариантов этапов, то без таких вставок можно обойтись. 99,9% квестов будут им описываться полностью, для оставшейся десятой процента можно и не пожалеть пЫва кодеру. %)

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

Разумеется это шаг вперед. Однако надо быть очень аккуратным. Самая большая опасность состоит в том, что все квесты станут
"шаблонными". С точки зрения интерфейса с игроком это хорошо ("г помогу" это не так уж плохо, мало доблести в том, чтобы "угадать"
"г помогу вам с удовольствием"), но это в некоем виде коснется ВСЕХ аспектов. Порог для создания чего-то реально "редкого" существенно увеличится.
Главное, чтобы это не превратилось в WOW-стиль... т.е. кучка помеченных (!) NPC у каждого из которых надо несколько раз нажать OK.

Я предпринимал неординарные усилия в попытках написать SRS для встроенного языка. Не могу сказать, что это привело к значимым успехам.
Вокруг создания SRS и хорошего языка можно было бы как-то объединяться...

Некая ущербность предложенного подхода все-же есть. Проблема вовсе не в том, как налепить кучу одинаковых квестов.
Проблема в том, каким образом связывать ЭТАПЫ внутри сложных квестов. И каким образом обрабатывать НАГРАДУ.
Насколько я знаю в былинах использовался attach-detach подход, когда продвижение по квесту в том числе обрабатывалось как
подключение триггеров и их отключение. Мы в своё время использовали почти state-machine. Правда, тогда я этих слов толком не знал.
Были введены и задействованы "переменные" которым при их создании можно было указывать как быстро и при каких условиях они
обнуляются. (репоп - время - другие условия). В результате в любом месте зоны можно было легко определить в какой стадии находится квест.

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

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

Ну, в "Былинах" можно использовать как attach-detach, так передачу переменных и наконец метки квестов. Метка - это число связанное с произвольной строкой, которое записывается в файл персонажа. То есть вы записываете в персонажа что-то вида "1001 quest completed" и потом можете прочитать или удалить. Увы, вся работа с ними тоже ведется напрямую, нет никакой единой системы нумерации меток и т.п., тем не менее, куда лучше чем подключение-отключение триггеров. Например это позволяет делать периодические квесты, квесты, которые выполняются раз в реморт, квесты, которые может выполнять сразу множество игроков, не мешая друг другу и так далее. По сути метка дает возможность хранить произвольную информацию.

Что до основной темы, я вот как раз думал, может действительно стоит помечать квестеров как-то типа "{!}Седой отшельник сидит здесь" или "{!} Бутылка с запиской внутри покачивается на воде", наплевав про вопли о "копировании WoW". Тоже не вижу особого интереса в угадывании очередного "помогу/пойду/возьмусь" для взятия квеста. Вот в процессе выполнения -- другое дело. Там подбор правильной команды или фразы может быть элементом игры (см. Wizardry 8 например).

Инструментарий это да, сложней... OLC несколько не нагляден. Хотя мне в отличие от вас нравится редактор Скрима (это который "новый редактор для "Былин"). Там вполне можно встроить редактор сетов в формате фреймворка, тем более, что от магазинов мы недавно избавились. В смысле магазинов, привязанных к зонам.

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

Помечать квестеров... на мой взгляд это бесспорно путь к серьезному оказуаливанию. Оно надо ?
Яб уж лучше сделал систему автоквестера по типу "пойди туда-то и тот-то даст тебе квест".

ЗЫ. Я, честно говоря, плотно не слежу. Можно ссылку на "хорошие" редакторы ?

Разумеется, я тоже думал что-то на тему конечного автомата. Тут правда надо учитывать, что квест отдельный для каждого персонажа, система, когда 1 человек берет квест, а остальные курят, имхо, порочна. То есть как минимум описание состояния автомата-квеста должно быть привязано к персонажу.



ИМХО, да. Это -- правильное оказуаливание. Оно делает процесс игры удобней, а не примитивней или хуже.



Одно другому не мешает, только это не автоквестер, а просто узловая точка/справочная, встроенная в игру.



Да вы его видели, редактор Scream'a с http://dolgof.ru/
Только вам не понравился вроде.

Да к чему привязывать дело десятое. Квесты бывают разные.
Тут скорее про другое у меня сомнение.
Насколько имеет смысл делать "непрерывный мир".
Это на самом деле весьма важный концептуальный вопрос.
С годами я начинаю думать что система предложенная близзардом более верна.
Т.е. "непрерывный внешний мир" + "инстанцы в местах где требуется ум".
При этом подходе многое разруливается гораздо проще.


А почему примитивней-то не делает ?
Квесты в традиционном понимании в принципе "примитив".
Если вы делаете зону с сюжетом, то странным выглядит (!) над головой у ничего не подозревающего NPC.
Если он, скажем... глашатай... это еще куда не шло, но если он тебя в общем-то и "не ждет" ?


Не, не понравилось при fast look. Может не разглядел.
Те-же яйца, только сбоку. Ну скокож уже можно, а ?
Более 10 лет назад.... я.... предложил этот убогий(на сегодня) внешний вид....
донором было какое-то приложение под дос по-моему от рмада, что-то переработали итп.
Ну сколько можно это мусолить ? Неужели прогресс остановился ?
Я когда это всё вижу меня в ступор вводит, вот ей богу...
Ну НАХЕРА... вот слов уже просто даже нет.... НАХЕРА столько ЗАКЛАДОК ?
Ну зачем ? Для вящего удобства ? Чтобы побольше ошибок нахреначить... да ?
Нет, я понимаю в 800х600 это было необходимо. Но сегодня ?
Почему ? Почему "вашу мамашу" Доп.Описания зарыты куда-то в жопу ?
Почему их не видно в окне прямо под описанием предмета ?
Это специально для увеличения количество удобства ?
Вопросы риторические. С таким подходом никуда не уехать. Вообще.
Я когда такое вижу, "плачу и закрываю", вот ей богу "сердце разрывается".
Ну сколькож можно-то.... прям хоть патентуй это убожество и запрещай к использованию.
Слов просто нет, ей богу...

ГМ-ский инструментарий такой-же ?
Или там есть что-то не видное поверхностно хоть чуть-чуть более удобное ?
Проверки к примеру обширные итд итп ?

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

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

Что до "примитивности" подхода с помечанием квестеров, я же не имею в виду помечать, как это в WoW сделано, всех NPC и предметы, которые участвуют в квесте, только входную точку. А там так и так должно быть как-то описано, что тут квест и его можно взять, только механизм не унифицирован, и больная фантазия билдеров рукам покоя не дает.

Редактор -- ну вы слишком уж категоричны. Если все оттуда вытащить из закладок, то оно и на 24-дюймовом мониторе многовато места займет, а ведь многие пользуются к примеру на работе. Ну описания да, можно бы. И вообще уменьшить число закладок. Зато карта там всегда перед глазами и сразу помечаются комнаты, где расположены выбранные мобы, предметы и триггера и т.п. удобства. Вообще, в OLC не хватает именно визуализации карты, и где что расположено, а в остальном он даже удобней. ГМский инструментарий, который мне нужен, в ортодоксально-консольном стиле и перловских скриптах. ж) Был бы штат кодеров на зарплате -- я б им дал указание сделать веб-интерфейсы с собственным движком, статистикой и цветастыми графиками. А так -- чем богаты.

Instance или не Instance based будет весь мир категорически влияет на то, как будут обрабатываться сложные
линии квестов. Собственно инстанцы по всей вероятности снимут очень много проблем. (правда большинство из них уже вроде бы решены)

Цветастые графики в редакторах непричем, хотя было бы неплохо.
Инструмент, увы, банально не прогрессирует, и его текущее "закукливание" ведет к массе трудноуловимых багов.
Причем даже сама мысль о том, что следует переработать от 50 до 80% интерфейса кажется вам странной.
Ведь всё вроде бы работает и так...

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



Ну а в каком направлении его менять? И что это даст?
Для массовых операций редактор все равно непригоден, для этого куда лучше годятся скрипты-конвертеры.
А для вдумчивого написания отдельной зоны он вполне себе удобен, как мне кажется.

ЗЫ: Кстати, насчет "предложил этот вариант". Вы не Росвальд будете? Первый вариант редактора амада кажется им написан, а старый былиновский на его основе.

Так зависит одно от другого очень остро.


Ну удобен, значит ничего менять не надо. По мне, так яб 70-80% переделал. Обладая сегодняшней эрудицией.
Инструмент был неплох (даже хорош) лет десять назад, на сегодня есть решения в области GUI и получше.
Уж по крайней мере яб снял с билдеров 90% гемороя связанного с статсами предметов и мобов, хотя у вас
там, возможно иные "понятия", в этом случае яб хотя бы разделил антураж с механикой. Явным образом.
Тут еще зависит кто подо что затачивает, и как потом проверяет.

Если говорить о части про создание квестов - подлежит переделке на 100%.
Разве нет ?


Нет, не буду.
Я право не знаю о каком редакторе речь, и кто такой Росвальд , не эрудирован.
Возможно это некто, кого я знаю под иным именем. Или просто не припоминаю. Хотя ник знакомый.
Однако могу вам смело сказать, что первый вариант редакторов написанных для амада был написан мною.
До того использовали некий редактор от какого-то западного(?) мада, и нечто от рмада(?) (под дос?) .
Впрочем длилось это крайне недолго, возможно 2-3 месяца начиная от старта. Возможно чуть больше,
тому уж лет 15, не упомнить толком. Может правда что-то было...
Там немало странных на сегодня решений было применено. В частности разделение на отдельные экзешники,
в целях уменьшения размеров релизов. (кстати epic fail, библиотеки оказались тяжелее кода, а без них
распространять оказалось неудобно, потом слинковали в один экзешник, размер толком не увеличился)
Оно все на дельфях к слову сказать было.

Да мне в целом ей богу за право первенства всех этих Bases ) спорить не интересно.
Росвальд так Росвальд. 10 лет назад этим результатом можно было и гордиться, сегодня нельзя .

Вопрос не в том, кто чего совершил, а в том, что нету блин прогресса. Иногда до слёз обидно.