Еще забыл добавить, что нужно поддержка инстансов отдельных зон. Псевдографика в юникоде это хорошо и можно использовать, но нужно будет подыскать шрифт где она есть. Я не думаю что в шрифтах рисуют все символы юникода. Или придется костлять такие символы в клиенте вручную.
Такой подход и нужно делать. Проблема в том что редактор по трудозатратам не меньше чем сам сервер, а то и больше. Плюс навернуть текстовыми конфигами можно гораздо больше чем сделать редактором. Тут придется тщательно выбрать какую часть функционала сделать в редакторе, и там не будут все возможности сервера. Разработка редактора никогда не будет успевать за сервером.
Полностью согласен, еще можно прямо в маде создавать псевдографику в стиле пиксель-арта, например, миниатюры комнат, заходишь в комнату «лес», а там картинка леса из текстовых символов. Можно сэкономить на описаниях.
Если разработка редактора занимает кучу времени и сил, то делай как обычно делают в современных мадовских движках, типа 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) индикатор прогресса для умений с предзадержкой.
И это только наиболее популярные возможности вывода терминалов, при необходимости можно задействовать (или придумать самому) намного больше.
Если в редакторе есть кнопка — генерировать моба 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. Редактор зон там часть движка, совмещен с админской веб-панелью мада. Заходишь браузером и создаешь зону прямо на сервере, тут же смотришь всю статистику, теституеь и подключаешь ее. И вопросов с правами на зону в таком случае возникает намного меньше.
Редактор не дает видеть всю картину целиком, ты заблуждаешься. Ты об этом сам же и сказал. Если что-то нужно особенное — нужно залезть в файлы зоны. А редактор такое не покажет — это особенное, т.е. — картина не целиком. А для поддержки нестандартных выходов — нужно было сделать поддержку карты в маде, так чтобы маппер жабы это понимал, т.е. отдавать внум конматы мапперу, чтобы он не путался в комнатах.
Вроде как в lpmud'ах не требуется перезагразка никогда, даже при подключении новых зон, по крайней мере они везде об этом твердят, когда идет сравнение lpmud'ов и diku-мудов.
Редактор ни в чем не ограничивает билдера, он помогает видеть картину в целом и делать быстро рутинные обычные действия. Если нужно что-то необычное, то никто не мешает залезть в файлы зоны и ручками прописать все, что тебе нужно (ну это в случает flat-файлов зоны, в случае баз данных будет морока). Я когда начинал билдить в Адане, я как раз пытался делать нестандартные вещи, типа необычные связи между комнатами, когда с-с-з не равно в-ю-ю. Но, мне быстро перекрыли кислород и объяснили, что так делать не нужно, потому как маппер для жабы такого не поймет.
Изменения без перезапуска или бекап без перезапуска — вполне реализуем, если заранее закладывать такую возможность. Например язык Erlang, он позволяет без перезагрузки и остановки сервера вообще менять его бинарный код. Как это работает я не изучал, но это заявлено.
Изменение — это обычная замена скрипта, как переменную в коде.
Бекап — тут можно остановить игровой процесс, оставить например только чат, чтобы не было скучно ждать бекап.
Два разных проекта писать не потребуется. Если взять С++11 то он уже давно стандарт — работает везде одинаково. Уверяю, поддержать несколько ОС совсем не сложно. Все давно для этого в сфере разработки сделано. Различия совсем незначительные.
Отладочный мад, которые в сети, а не локально на виртуальной машине — вполне нужная штука, где можно обкатывать зоны всеми сразу, а не в одиночку.
Два сервера на одном порту — это не опечатка. Это вполне реализуемо, но программно. Это похоже на технологию Load Balancer.
1. По поводу автоматизации нудных процессов — проставление флагов для однотипных мобов. Тут редактор будет даже хуже. Так как в моем варианте — можно наследовать одного моба от другого (наследование характеристик). Чтобы поставить общий флаг на моба — достаточно его поставить у прородителя таких мобов. В текстовом редакторе это будет сделать не намного сложнее. И в текстовом редакторе есть поиск. Плюс я повторюсь — редактором ты не сможешь кастомизировать индивидуально какую то характеристику для отдельного моба, т.к. придется наворачивать редактор, а это время.
2. Действительно без миникарты — картину в целом невидно, но нарисовать ее на бумаге несложно. Я не считаю что это прошлый век, но тратить время на редактор не вижу смысла, т.к. на него уходит гигантское время программиста. Что проще — нарисовать зону на бумаге, а потом ее соединить в коде или ждать пока программист сделает миникарту. В редакторе ты сможешь соединить только тем механизмом, что позволяет сам редактор (простой переход, дверь и пожалуй это все), а если делать это кодом, можно делать вообще все угодно (переходы в зависимости от характеристик персонажей, наличие предметов, висящих аффектов ).
В крайнем случае можно сделать миникарту чисто для ориентирования, но она не будет отражать все ньюансы. Очень сложно визуализировать ту механику, которую можно задать в виде кода.
Редактор удобен билдерам, согласен, они привыкли к нему, но он очень сильно их ограничивает в возможностях. Редактором можно сделать только то, что поддержал программист в этом редакторе, а движок мада сможет гораздо гораздо больше. Редактор — это камень на шее мадов. Это можно будет только продемонстрировать примером в будущем.
И насчет добавления новых фич без перезапуска мада. Я понимаю, что хочется, но не получится. Или для этого удобства придется городить отдельную механику. Тестироваться можно на тестовых серверах, а опыт серьезных проектов типа WoW показывает, что все равно даже для текущей работы нужна перезагрузка раз в неделю примерно. Скажем, даже такая простая вещь как бекап. Правильный бекап делается на выключенном сервере, не на живом и меняющемся. То есть в процессе работы мада, скажем, раз в час можно бекапить то, что бекапится в онлайне, а настоящий полный бекап делать, скажем, раз в неделю при остановке и перезагрузке сервера
Но. Я против мультиплатформенности. Потому как если мад это сервер плюс почта плюс веб-сервер для статистики и управления, то сделать мультиплатформенно означает по сути делать два разных (пусть и близких проекта) — один для UNIX, второй для Windows. Вы еще MacOS упомяните, у многих ноутбуки от Эппла ;)
В общем, мад сервер должен быть под Centos Linux.
А как работать разработчикам? Нужен или отладочный мад на том же виртуальном сервере (или на другом таком же) или пусть стаят у себя виртуальную машину. Сейчас это не сложно и мощности современных ноутбуков позволяют
А насчет (два мад сервера — рабочий и отладочный на одном сервере на одном порту, это наверное опечатка. Или на разных портах или на разных серверах)
Но, в принципе, да, как вариант.
Такой механизм, в частности, позволяет видоизменять живой сервер на лету, без всяких перезагрузок (что особенно удобно для исправления багов игровых зон, опечаток).
На подробный список небуквенных символов юникода можно полюбоваться на википедии отсюда и до конца страницы.
Большинство современных мадов используют только изменение цвета по трехбитной палитре и bold-начертание (для ярких цветов), более продвинутые используют смену цвета фона. Но возможно ведь гораздо больше.
1. На линуксах/макоси уже давно стало стандартом использовать 8-ми битную цветовую палитру (256 цветов, где 16 — оттенки серого, а остальные 240 — градации стандартных восьми). Некоторые могут возразить, что мад с таким количеством цветов получится слишком вырвиглазным, но я считаю иначе: такая палитра как раз-таки позволит выбирать наиболее приятные для глаза оттенки и создавать плавные цветопереходы, что в итоге благоприятно скажется на качестве картинки.
Но и это еще не предел. При желании можно использовать 24-битную палитру — это весь RGB-диапазон (256 * 256 * 256 = 16 777 216 цветов). Поддержка эмуляторами терминала здесь, конечно, хуже, но для игры все равно используют мад-клиенты, так что почему бы и нет?
2. При переходе на 8-ми битную палитру отпадает необходимость использовать bold-последовательность (CSI1m) для представления ярких цветов (они включены в палитру в качестве реальных цветов), так что возможен будет жирный текст.
Также ANSI предусматривает подчеркнутое, мигающее (поддерживаются еще xterm'ом), курсивное и перечеркнутое начертание (здесь с поддержкой похуже).
3. Управление курсором — это нужно для обновления произвольных областей терминала клиента. Сходу два наиболее актуальных юз кейса: 1) автоматически обновляющаяся строка статуса и 2) индикатор прогресса для умений с предзадержкой.
И это только наиболее популярные возможности вывода терминалов, при необходимости можно задействовать (или придумать самому) намного больше.
Из наглядных примеров, ты можешь сравнить мады у которые есть удобный редактор (Сфера Миров, Былины) и у которых нет редактора вообще (Неронис), и сделать вывод сколько билдеров трудятся для первых мадов и сколько над Неронисом, у которого и мир, кстати, спроектирован с серьезными косяками.
Если разработка редактора занимает кучу времени и сил, то делай как обычно делают в современных мадовских движках, типа CoffeeMUD или Evennia. Редактор зон там часть движка, совмещен с админской веб-панелью мада. Заходишь браузером и создаешь зону прямо на сервере, тут же смотришь всю статистику, теституеь и подключаешь ее. И вопросов с правами на зону в таком случае возникает намного меньше.
Изменение — это обычная замена скрипта, как переменную в коде.
Бекап — тут можно остановить игровой процесс, оставить например только чат, чтобы не было скучно ждать бекап.
Отладочный мад, которые в сети, а не локально на виртуальной машине — вполне нужная штука, где можно обкатывать зоны всеми сразу, а не в одиночку.
Два сервера на одном порту — это не опечатка. Это вполне реализуемо, но программно. Это похоже на технологию Load Balancer.
2. Действительно без миникарты — картину в целом невидно, но нарисовать ее на бумаге несложно. Я не считаю что это прошлый век, но тратить время на редактор не вижу смысла, т.к. на него уходит гигантское время программиста. Что проще — нарисовать зону на бумаге, а потом ее соединить в коде или ждать пока программист сделает миникарту. В редакторе ты сможешь соединить только тем механизмом, что позволяет сам редактор (простой переход, дверь и пожалуй это все), а если делать это кодом, можно делать вообще все угодно (переходы в зависимости от характеристик персонажей, наличие предметов, висящих аффектов ).
В крайнем случае можно сделать миникарту чисто для ориентирования, но она не будет отражать все ньюансы. Очень сложно визуализировать ту механику, которую можно задать в виде кода.
Редактор удобен билдерам, согласен, они привыкли к нему, но он очень сильно их ограничивает в возможностях. Редактором можно сделать только то, что поддержал программист в этом редакторе, а движок мада сможет гораздо гораздо больше. Редактор — это камень на шее мадов. Это можно будет только продемонстрировать примером в будущем.
Но. Я против мультиплатформенности. Потому как если мад это сервер плюс почта плюс веб-сервер для статистики и управления, то сделать мультиплатформенно означает по сути делать два разных (пусть и близких проекта) — один для UNIX, второй для Windows. Вы еще MacOS упомяните, у многих ноутбуки от Эппла ;)
В общем, мад сервер должен быть под Centos Linux.
А как работать разработчикам? Нужен или отладочный мад на том же виртуальном сервере (или на другом таком же) или пусть стаят у себя виртуальную машину. Сейчас это не сложно и мощности современных ноутбуков позволяют
А насчет (два мад сервера — рабочий и отладочный на одном сервере на одном порту, это наверное опечатка. Или на разных портах или на разных серверах)