Полностью согласен, еще можно прямо в маде создавать псевдографику в стиле пиксель-арта, например, миниатюры комнат, заходишь в комнату «лес», а там картинка леса из текстовых символов. Можно сэкономить на описаниях.
Если разработка редактора занимает кучу времени и сил, то делай как обычно делают в современных мадовских движках, типа CoffeeMUD или Evennia. Редактор зон там часть движка, совмещен с админской веб-панелью мада. Заходишь браузером и создаешь зону прямо на сервере, тут же смотришь всю статистику, теституеь и подключаешь ее. И вопросов с правами на зону в таком случае возникает намного меньше.
Есть еще подход: редактор зон встроен напрямую в игру, как часть инструментария иммортала. При этом все изменения сразу же вступают в силу, созданные объекты сразу же становятся частью игрового мира, так что билдер сразу видит результат.
Такой механизм, в частности, позволяет видоизменять живой сервер на лету, без всяких перезагрузок (что особенно удобно для исправления багов игровых зон, опечаток).
Также в статье не упомянут очень важный довод в пользу UTF: юникод — это не только символы со всех языков мира, это еще и большое количество символов псевдографики. В частности, возможно будет чертить нормальные таблицы/блоки с неразрывными границами.
На подробный список небуквенных символов юникода можно полюбоваться на википедии отсюда и до конца страницы.
Я бы добавил еще более глубокую поддержку ANSI-последовательностей.
Большинство современных мадов используют только изменение цвета по трехбитной палитре и bold-начертание (для ярких цветов), более продвинутые используют смену цвета фона. Но возможно ведь гораздо больше.

1. На линуксах/макоси уже давно стало стандартом использовать 8-ми битную цветовую палитру (256 цветов, где 16 — оттенки серого, а остальные 240 — градации стандартных восьми). Некоторые могут возразить, что мад с таким количеством цветов получится слишком вырвиглазным, но я считаю иначе: такая палитра как раз-таки позволит выбирать наиболее приятные для глаза оттенки и создавать плавные цветопереходы, что в итоге благоприятно скажется на качестве картинки.
Но и это еще не предел. При желании можно использовать 24-битную палитру — это весь RGB-диапазон (256 * 256 * 256 = 16 777 216 цветов). Поддержка эмуляторами терминала здесь, конечно, хуже, но для игры все равно используют мад-клиенты, так что почему бы и нет?

2. При переходе на 8-ми битную палитру отпадает необходимость использовать bold-последовательность (CSI1m) для представления ярких цветов (они включены в палитру в качестве реальных цветов), так что возможен будет жирный текст.
Также ANSI предусматривает подчеркнутое, мигающее (поддерживаются еще xterm'ом), курсивное и перечеркнутое начертание (здесь с поддержкой похуже).

3. Управление курсором — это нужно для обновления произвольных областей терминала клиента. Сходу два наиболее актуальных юз кейса: 1) автоматически обновляющаяся строка статуса и 2) индикатор прогресса для умений с предзадержкой.

И это только наиболее популярные возможности вывода терминалов, при необходимости можно задействовать (или придумать самому) намного больше.
  • avatar artist
  • 0
Если в редакторе есть кнопка — генерировать моба 15 уровня, то в моем варианте можно будут сделать примерно так: mob=Generate{level = 15}, но если в редакторе функция генерации моба зашита и ее не поменять, то в моем варианте ее можно менять, причем можно генерировать моба не только по уровню, а по любому набору параметров. А еще как пример можно будет сделать примерно так: mob = { parent = «black.wolf», name = «Белый волк», drop_coins = сhar_level*10+20 } — создать белого волка на базе черного волка, добавить ему дроп монет и привязать его к уровню персонажа, который его убил.
Я написал несколько десятков зон, делал это в разных редакторах и без редакторов. Хороший редактор очень сильно облегчает труд билдера, например, в редакторе Сферы Миров для мобов нужно указать уровень моба и нажать кнопку сгенерировать, и редактор сам проставит все, что нужно для обычного моба, все его характеристики. В случае необходимости можно проставить все это вручную, но в большинстве случаев этого не требуется. И ты хочешь сказать, что я ничего не потеряю, если все характеристики буду набирать в текстовом файле, типа «str=5; dex=6; int=4 и т.д.». Это займет намного больше времени, и займет необоснованно, когда этого можно избежать. Это все равно, что утверждать, что писать код в обычном текстовом редакторе и в каком-нибудь Visual Studio, это одно и то же, как по результату, так и по затратам сил.

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

Если разработка редактора занимает кучу времени и сил, то делай как обычно делают в современных мадовских движках, типа CoffeeMUD или Evennia. Редактор зон там часть движка, совмещен с админской веб-панелью мада. Заходишь браузером и создаешь зону прямо на сервере, тут же смотришь всю статистику, теституеь и подключаешь ее. И вопросов с правами на зону в таком случае возникает намного меньше.
  • avatar artist
  • 0
Редактор не дает видеть всю картину целиком, ты заблуждаешься. Ты об этом сам же и сказал. Если что-то нужно особенное — нужно залезть в файлы зоны. А редактор такое не покажет — это особенное, т.е. — картина не целиком. А для поддержки нестандартных выходов — нужно было сделать поддержку карты в маде, так чтобы маппер жабы это понимал, т.е. отдавать внум конматы мапперу, чтобы он не путался в комнатах.
Вроде как в lpmud'ах не требуется перезагразка никогда, даже при подключении новых зон, по крайней мере они везде об этом твердят, когда идет сравнение lpmud'ов и diku-мудов.
Редактор ни в чем не ограничивает билдера, он помогает видеть картину в целом и делать быстро рутинные обычные действия. Если нужно что-то необычное, то никто не мешает залезть в файлы зоны и ручками прописать все, что тебе нужно (ну это в случает flat-файлов зоны, в случае баз данных будет морока). Я когда начинал билдить в Адане, я как раз пытался делать нестандартные вещи, типа необычные связи между комнатами, когда с-с-з не равно в-ю-ю. Но, мне быстро перекрыли кислород и объяснили, что так делать не нужно, потому как маппер для жабы такого не поймет.
  • avatar artist
  • 0
Изменения без перезапуска или бекап без перезапуска — вполне реализуем, если заранее закладывать такую возможность. Например язык Erlang, он позволяет без перезагрузки и остановки сервера вообще менять его бинарный код. Как это работает я не изучал, но это заявлено.

Изменение — это обычная замена скрипта, как переменную в коде.
Бекап — тут можно остановить игровой процесс, оставить например только чат, чтобы не было скучно ждать бекап.
  • avatar artist
  • 0
Два разных проекта писать не потребуется. Если взять С++11 то он уже давно стандарт — работает везде одинаково. Уверяю, поддержать несколько ОС совсем не сложно. Все давно для этого в сфере разработки сделано. Различия совсем незначительные.

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

Два сервера на одном порту — это не опечатка. Это вполне реализуемо, но программно. Это похоже на технологию Load Balancer.
  • avatar artist
  • 0
1. По поводу автоматизации нудных процессов — проставление флагов для однотипных мобов. Тут редактор будет даже хуже. Так как в моем варианте — можно наследовать одного моба от другого (наследование характеристик). Чтобы поставить общий флаг на моба — достаточно его поставить у прородителя таких мобов. В текстовом редакторе это будет сделать не намного сложнее. И в текстовом редакторе есть поиск. Плюс я повторюсь — редактором ты не сможешь кастомизировать индивидуально какую то характеристику для отдельного моба, т.к. придется наворачивать редактор, а это время.

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

Редактор удобен билдерам, согласен, они привыкли к нему, но он очень сильно их ограничивает в возможностях. Редактором можно сделать только то, что поддержал программист в этом редакторе, а движок мада сможет гораздо гораздо больше. Редактор — это камень на шее мадов. Это можно будет только продемонстрировать примером в будущем.
  • avatar prool
  • 0
И насчет добавления новых фич без перезапуска мада. Я понимаю, что хочется, но не получится. Или для этого удобства придется городить отдельную механику. Тестироваться можно на тестовых серверах, а опыт серьезных проектов типа WoW показывает, что все равно даже для текущей работы нужна перезагрузка раз в неделю примерно. Скажем, даже такая простая вещь как бекап. Правильный бекап делается на выключенном сервере, не на живом и меняющемся. То есть в процессе работы мада, скажем, раз в час можно бекапить то, что бекапится в онлайне, а настоящий полный бекап делать, скажем, раз в неделю при остановке и перезагрузке сервера
  • avatar prool
  • 0
В целом вещи правильные и во многом очевидные.

Но. Я против мультиплатформенности. Потому как если мад это сервер плюс почта плюс веб-сервер для статистики и управления, то сделать мультиплатформенно означает по сути делать два разных (пусть и близких проекта) — один для UNIX, второй для Windows. Вы еще MacOS упомяните, у многих ноутбуки от Эппла ;)


В общем, мад сервер должен быть под Centos Linux.

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

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

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

Другим хорошим подспорьем для билдера является также автоматизация однотипных нудных процессов. Например, проставление одних и тех флагов для нескольких десятков мобов или объектов. Такая бессмысленная рутина очень сильно бьет по творческой мотивации писать зону, особенно человеку, который за свой труд ничего не получает.
Благодарю за ответы. Надеюсь, я не слишком нуден. Я не к чему не призываю, просто интересно разобраться.
  • avatar artist
  • 0
Я пока не решил окончательно использовать Unity3d или нет. Покажет только эксперимент касательно самых сложных частей.
  • avatar artist
  • 0
Потому что Unity готовый инструмент, который уже все делает много сам, не нужно заморачиватся подключением этой либы, изучать ее ограничения, требования к коду для нее, внедрять ее и т.д. Плюс в Unity огромное количество уже готовых блоков, которое можно использовать в проекте. Огромный магазин таких блоков. Это не только удобный GUI — это среда разработки с отладчиками, и прочими инструментами заточенных под работу. Unity решает огромное количество второстепенных задач, экономит время.
То есть Юнити использует опен-соурсную виртуальную машину, которая транслирует код на C и C++ в JavaScript? А, для чего нужен тогда Юнити, что мешает использовать Emscripten напрямую в проекте? Юнити нужен только как удобный GUI?
  • avatar artist
  • 0
Все работает не так. С++ и C# в Unity транслируется в JavaScript, плагины не требуются. Используется это en.wikipedia.org/wiki/Emscripten