www.mudconnector.su

Честно говоря, я надеялся, что его придумает кто-то другой. Но желающих как-то не особо много.

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

Готов поучаствовать.
Возглавить не готов .

Проблема с мироустройством не основная. Гораздо ценнее готовая заготовка под редактор.

Набросал несколько вопроов, которые не совсем ясны и хотелось бы их прояснить:

1. В каком виде должна храниться информация о зоне? В каком-то определенном формате xml, yaml или json?
Или лучше в бинарном коде удобном для машин?

2. Вся зона должна быть в одном файле или нескольких? Что удобнее?

3. Что лучше сделать, просто дискретные комнаты или какую-то систему координат x, y (чтобы можно
было точно определять местоположение игроков относительно друг друга)? Если система координат, то как
она должна выглядеть?

4. Как в такой системе должны задаваться алгоритмы поиска путей (по которым передвигаются мобы)?

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

6. Как будет обновляться зона, вся полностью или частично? как задавать репоп если иногда нужно зону
обновить полностью, а иногда частично.

7. Как будут создаваться инстансовые зоны в этой системе, если они запланированы?

Только в текстовом.
Цель: сравнение diff-ом. Часто бывает нужно.
Всегда все поля должны быть указаны, т.е. никаких значений по умолчанию.
Если isDark есть, то не надо писать его тольео для false, надо писать и для true тоже.
Специально для того, чтобы можно было исправить руками без редакторов.


Я делил на файлы объектов-мобов итп.
На самом деле вопрос сложный.
Вероятно всё-таки лучше делить.
Причем делить "еще раз пополам".
Т.е. разделить внешний вид и функциональность !


Тут боюсь нет выбора, в основном все имеют дело с дискретными комнатами.


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


Боюсь никакого. Тут не угодить.
Если есть желание морочиться со скриптами, то отдельно следует всё продумать.
Я не смог придумать качественного языка.
За основу на сегодня брал бы что-то типа lua, т.е. интерпретируемый язык.


Да какая разница ?
Такие тонкости должны быть управляемы в каждом конкретном маде.


Да откудаж я знаю ?
Это ведь не имеет никакого отношения к описанию зоны-мира ?

А есть какие нибудь соображения по поводу того, как будут храниться эти файлы? В цирклах это пронумерованные файлы, типа 111, 556 и т.д., без списка
какому номеру какая зона соответствует не разобраться. В других системах используются еще аббревиатуры названий, типа midgaard, crypt4, blackforest и т.д.,
что тоже при большом количестве зон не намного удобнее, т.к. будет по десять штук всяких непонятных форестов, таунов и т.д.
Как организовать несколько сотен или тысяч файлов в удобную стройную систему?

А откуда в маде несколько тысяч зон ?
На сегодня я складывал бы все файлы одной зоны в одну папку, а не раскладывал по папочкам.
Зачастую это удобнее.
Хотите можно постфиксы делать 000-black-forest, 111-ancient-village итп

ЗЫ. Работая с миром знал наизусть с сотню зон по номерам-то точно.

А не легче ли написать конвентер зон ? Например, из CircleMud в какой-нибудь унифицированный формат, а из этого формата во всякие rom, coffeemud и т.д.
Насколько я знаю, в CoffeeMud такой конвентер имеется, и он умеется конвентировать ~20 форматов зон в формат зон CircleMud

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

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

В любом случае при конвертации зон и прочего из мада в мад будет много ручной работы - все опрации не автоматизировать.

Информация в редакторах обычно хранится в виде списков: "код в движке" - "что это такое". Такие списки переделываются под конкретный мад очень быстро.

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

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