1
Требования к современному мад серверу.

Уже прошло более 20 лет после того, как первые мады увидели свет. Но на данный момент в технологическом плане они по прежнему все те же и кодовые базы по сути не менялись. За редким исключением (Сфера миров) кодовые базы — это наследники Циркуля и Rom-a, у которых в свою очередь общий наследник Diku. А кодовую базу Сферы авторы не раскрывают. Все что делалось в русском сегменте — это русификация и изменение игровой механики. Зачастую изменения делались людьми с небольшим опытом программирования, что в результате приводило к проблемам — падение сервера, пропажа игровых предметов и т. д.

Технологии ушли вперед, мады пока нет. Тут я хочу попробовать собрать требования к современному мад серверу, который хотелось бы иметь и попробовать объяснить почему.

Итак требования.

1. Сервер должен быть мультиплатформенным, т.е. запускаться на основных ОС. На данный момент это Windows, Linux, FreeBSD. Если первая используется пользователями, в т.ч. билдерами, имплементорам, игроками — что позволит запустить сервер на своем домашнем компьютере для разработки зон, наример. То другие — в основном как хостинг для мад сервера. Стоимость хостинга в месяц для Linux намного дешевле хостинга на Windows. Это будет актуально, если мад не приносит прибыль и хостинг оплачивается из своего кармана.

2. Сервер должен поддерживать юникод. Уже давно прошла пора кодировок символов — кои8, win1251 и т.д. Это сильная привязка сервера к конкретному языку, например русскому. Это мешает разрабатывать мад на нескольких языках, в т.ч. одновременно. Из всех вариантов самым удобным считаю UTF8. Сервер должен работать только на юникоде, выбор кодировки — это ахронизм прошлого века. Ради поддержки старых клиентов можно будет сделать маленькую программу — прокси, или добавить поддержку кодировки на отдельном порту (как временную меру).

3. Все исходные тексты зон должны быть одинаковыми независимо от того, где идет работа (Windows/Linux). Сейчас у Циркуля есть такая особенность — исходники зон для сервера на кои8, а для редактора — на win1251. В результате работать не удобно. Вывод — исходники зон должны быть на юникоде (UTF8).

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

5. Мад протокол должен стать более универсальным. Сейчас в сфере мадов огромное количество различных протоколов — MCCP, MSDP, MTTS, и другие. Которые зачастую дублируют друг друга по функциональности и не совместимы между собой. Их сложно расширять, сложно писать поддержку, защищаться от неверных данных и т.д. Сделать поддержку протокола непростая задача, чтобы было надежно и лекго расширяемо. Предлагается для мад-протокола использовать Lua. По сути транслятор Lua идеально подходит на эту роль. Тут можно обеспечить защиту от неверных данных, поддержку различных версий протоколов, легко расширять набор команд протокола. Клиенту требуется только написать обработчики тех команд, которые он поддерживает, а все остальное Lua сделает за тебя сама, т.е. распарсит протокол в команды, проверит их синтаксис, пропустит не поддерживаемые команды, вызовет нужные команды уже с готовыми параметрами. Если чтото в протоколе меняется — очень легко написать адаптер для протокола на том же Lua. Адаптер может переделать команды так, как нужно клиенту.

Плагины для клиента могут обрабатывать те команды, которые сам клиент не поддерживает. Это все очень легко интегрируется.

Конечно, кодировка символов в протоколе должна быть UTF8. Нужно сразу же оговорить, что нужно использовать сжатие протокола по умолчанию. Пропускная ширина канала сервера = это общий трафик от всех клиентов. Если можно уменьшить объем трафика — то это стоит сделать, учитывая что общий объем трафика из-за использования UTF8 и Lua увеличится. Сжатие позволит уменьшить объем трафика в 7-8 раз, что в целом скажется положительно на скорости отклика от сервера и уменьшит лаги.

Следует еще заметить, если все таки нужна будет поддержка MSDP и прочих протоколов, то это можно будет решить опять же с помощью Lua. Написать на нем транслятор нового мад протокола — в MSDP.

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

7. Поддержка управления через веб. Если для статистики можно будет поднять отдельный сайтик — т.к. он будет только работать только с базой данных статистики (написать на PHP), и тут не обязательно тащить все это прямо в мад сервер, то для работы с мадом — работа в браузере может оказаться вполне удобным вариантом. Хотя тут нужно изучить те моменты, которые будет проще всего делать именно в браузере, а не в командой строке, как при игре.

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

9. Работа с почтой. Желательно, чтобы сервер мог работать с email-ами. Для отправки писем всем играющим.

10. Простая кастомизация игрового контента. Т.е. тут идет речь о редакторе. Редактор — отдельная программа, которая позволяет создавать игровые зоны, мобов и прочий контент для мада. Мое мнение — нужно отказаться от редактора и писать зоны в обычном текстовом редакторе.
Основные причины — 1. Редактор это отдельная программа, которую надо поддерживать, причем для каждого мада по сути нужен свой редактор, т.к. игровой контент будет различен. 2. Редактор нужно поддерживать для всех ОС, что и сервер, иначе нет смысла. 3. Возникает проблема — когда появляется новая фишка в игре — ее нужно запилить и в редакторе, распространить между билдерами и т.д. Вывод — редактор очень большой якорь на шее мадов — так как тащит их вниз. Он уменьшает скорость ввода нового игрового контента в мад.

Решение проблемы — писать код, как обычную программу в текстовом редакторе. Основной плюс — универсальность. Тут очень легко добавлять новый контент, который добавлен на сервер. Вместо того чтобы поставить флажок мышкой — написать например строчку dark=true (в комнате темно).
Это дает еще одну гибкость — параметры могут вычисляться (т.е. если в редакторе может стоять только флаг — да/нет), то в новом варианте — параметр может считаться по формуле (например зависеть от погоды, наличия солнца, и т д). И кстати для каждого отдельной румы или моба, может быть своя формула! Т.е. вместо простого варианта — да/нет, получаем кастомизацию вообще без ограничений.
Минус — такой системы — требуется переучится билдерам, немного подучить синтаксис зон.
Но зато можно получить в перспективе онлайновый редактор прямо в браузере, без перезагрузки сервера, со справкой. Снимаются все ограничения, присущие стандартным редакторам.

11. Скриптование зон, мобов и т.д. Как известно, мобам нужен хоть какой то интеллект, чтобы мир был живой. Нужно писать им логику поведения. Для этого нужен язык программирования, желательно очень простой, чтобы билдеры в нем разобрались, надежный, чтобы был проверен временем. Тут выбор может быть очень большим — С#, JavaScript, Python, Lua.
Я пока хочу остановиться на Lua, как наиболее простой язык для непосвященных, идеально интегрирующийся в другие языки. Обеспечивает хорошую надежность и гибкость.
Так как скрипты — это текст, то это идеально ложится на концепцию описания зон в текстовом редакторе. Описывается зона, моб, объект и тут же лежат скрипты поведения. Можно будет интегрировать отладчик для скриптов, чтобы проверить как он работает.

12. Универсальность. Это когда сервер подходит под написание практически любого мада. Это сложно достижимая задача, но можно попытаться приблизится к ней. Т.е. сервер должен быть модульным. При старте сервер собирается и нужных программых блоков, как из кубиков.
Т.е. сервер состоит из 1. ядра (общий код — сеть, работа с файлами, и прочее), 2. либы (код который относиться к конкретному типу мада, но на его базе можно написать несколько мадов) — функционал игрового сета мада. 3. игровых зон (код отдельных мобов, объектов и прочее).

13. Желательно уметь заменять игровой контент без перезагрузки сервера. Т.е. добавить моба, убрать объект и прочее — прямо на лету. Это требует вывод игровой механики в скрипты. Если либа и игровая зона будет скриптовая — то это вполне возможно.

14. Умение крутить несколько мадов на одном сервере, на одних портах. Это скорее пожелание, позволит экономить на хостинге, если имплементоры этих мадов договорятся. Или держать одновременно игровой и тестовый сервера на одном хостинге.

15. Дать возможность серверам коммуникации между собой. Тут можно объединить чаты нескольких мадов, базы игроков и прочее.

На этом пока все требования.
  • avatar
  • Поделиться
  • +3

51 комментарий

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

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

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

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

Редактор удобен билдерам, согласен, они привыкли к нему, но он очень сильно их ограничивает в возможностях. Редактором можно сделать только то, что поддержал программист в этом редакторе, а движок мада сможет гораздо гораздо больше. Редактор — это камень на шее мадов. Это можно будет только продемонстрировать примером в будущем.
avatar
Редактор ни в чем не ограничивает билдера, он помогает видеть картину в целом и делать быстро рутинные обычные действия. Если нужно что-то необычное, то никто не мешает залезть в файлы зоны и ручками прописать все, что тебе нужно (ну это в случает flat-файлов зоны, в случае баз данных будет морока). Я когда начинал билдить в Адане, я как раз пытался делать нестандартные вещи, типа необычные связи между комнатами, когда с-с-з не равно в-ю-ю. Но, мне быстро перекрыли кислород и объяснили, что так делать не нужно, потому как маппер для жабы такого не поймет.
avatar
  • artist
  • 0
Редактор не дает видеть всю картину целиком, ты заблуждаешься. Ты об этом сам же и сказал. Если что-то нужно особенное — нужно залезть в файлы зоны. А редактор такое не покажет — это особенное, т.е. — картина не целиком. А для поддержки нестандартных выходов — нужно было сделать поддержку карты в маде, так чтобы маппер жабы это понимал, т.е. отдавать внум конматы мапперу, чтобы он не путался в комнатах.
avatar
Я написал несколько десятков зон, делал это в разных редакторах и без редакторов. Хороший редактор очень сильно облегчает труд билдера, например, в редакторе Сферы Миров для мобов нужно указать уровень моба и нажать кнопку сгенерировать, и редактор сам проставит все, что нужно для обычного моба, все его характеристики. В случае необходимости можно проставить все это вручную, но в большинстве случаев этого не требуется. И ты хочешь сказать, что я ничего не потеряю, если все характеристики буду набирать в текстовом файле, типа «str=5; dex=6; int=4 и т.д.». Это займет намного больше времени, и займет необоснованно, когда этого можно избежать. Это все равно, что утверждать, что писать код в обычном текстовом редакторе и в каком-нибудь Visual Studio, это одно и то же, как по результату, так и по затратам сил.

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

Если разработка редактора занимает кучу времени и сил, то делай как обычно делают в современных мадовских движках, типа CoffeeMUD или Evennia. Редактор зон там часть движка, совмещен с админской веб-панелью мада. Заходишь браузером и создаешь зону прямо на сервере, тут же смотришь всю статистику, теституеь и подключаешь ее. И вопросов с правами на зону в таком случае возникает намного меньше.
avatar
  • artist
  • 0
Если в редакторе есть кнопка — генерировать моба 15 уровня, то в моем варианте можно будут сделать примерно так: mob=Generate{level = 15}, но если в редакторе функция генерации моба зашита и ее не поменять, то в моем варианте ее можно менять, причем можно генерировать моба не только по уровню, а по любому набору параметров. А еще как пример можно будет сделать примерно так: mob = { parent = «black.wolf», name = «Белый волк», drop_coins = сhar_level*10+20 } — создать белого волка на базе черного волка, добавить ему дроп монет и привязать его к уровню персонажа, который его убил.
avatar
mob = { parent = «black.wolf», name = «Белый волк», drop_coins = сhar_level*10+20 }

Ты забываешь про падежи, в которых легко запутаться, описаниях и характеристиках мобов. Нужно помнить какой командой задать родительный падеж, какой командой установить силу или степень уклонения моба. Это десятки команд которые нужно запомнить, порог вхождения увеличиется колоссально. В редакторе же на все это подсвечиваются подсказки.
avatar
падежи
А зачем вообще вручную падежи вводить?) Сервер мог бы склонять существительные и автоматически.
avatar
Не встречалось еще ни одной программы, которая могла бы абсолютно любое русское слова правильно по падежам просклонять, всегда приходится перепроверять. Может я отстал от жизни?
avatar
В DF2 уже лет как десять работает система автоматического спряжения слов (не только существительных, вообще любых). Какие-то проблемы встречаются раз в год и легко исправляются добавлением исключения.
avatar
Если разработка редактора занимает кучу времени и сил, то делай как обычно делают в современных мадовских движках, типа CoffeeMUD или Evennia. Редактор зон там часть движка, совмещен с админской веб-панелью мада. Заходишь браузером и создаешь зону прямо на сервере, тут же смотришь всю статистику, теституеь и подключаешь ее. И вопросов с правами на зону в таком случае возникает намного меньше.
Есть еще подход: редактор зон встроен напрямую в игру, как часть инструментария иммортала. При этом все изменения сразу же вступают в силу, созданные объекты сразу же становятся частью игрового мира, так что билдер сразу видит результат.
Такой механизм, в частности, позволяет видоизменять живой сервер на лету, без всяких перезагрузок (что особенно удобно для исправления багов игровых зон, опечаток).
avatar
  • artist
  • 0
Такой подход и нужно делать. Проблема в том что редактор по трудозатратам не меньше чем сам сервер, а то и больше. Плюс навернуть текстовыми конфигами можно гораздо больше чем сделать редактором. Тут придется тщательно выбрать какую часть функционала сделать в редакторе, и там не будут все возможности сервера. Разработка редактора никогда не будет успевать за сервером.
avatar
  • prool
  • 0
В целом вещи правильные и во многом очевидные.

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


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

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

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

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

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

Изменение — это обычная замена скрипта, как переменную в коде.
Бекап — тут можно остановить игровой процесс, оставить например только чат, чтобы не было скучно ждать бекап.
avatar
Вроде как в lpmud'ах не требуется перезагразка никогда, даже при подключении новых зон, по крайней мере они везде об этом твердят, когда идет сравнение lpmud'ов и diku-мудов.
avatar
Я бы добавил еще более глубокую поддержку 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
Также в статье не упомянут очень важный довод в пользу UTF: юникод — это не только символы со всех языков мира, это еще и большое количество символов псевдографики. В частности, возможно будет чертить нормальные таблицы/блоки с неразрывными границами.
На подробный список небуквенных символов юникода можно полюбоваться на википедии отсюда и до конца страницы.
avatar
Полностью согласен, еще можно прямо в маде создавать псевдографику в стиле пиксель-арта, например, миниатюры комнат, заходишь в комнату «лес», а там картинка леса из текстовых символов. Можно сэкономить на описаниях.
avatar
Можно сэкономить на описаниях.
Аха, и потерять на художниках :)
Но, в принципе, да, как вариант.
avatar
Куча программок есть, которая картинки в ASCII-арт переделывает, только вот таких программ с UTF-8 символами я не находил. Можно брать картинку или фотографию с интернета и переделывать ее в текстовый формат. По-моему можно даже автоматизировать этот процесс, так что экономия времени будет колоссальная.
avatar
  • artist
  • 0
Еще забыл добавить, что нужно поддержка инстансов отдельных зон. Псевдографика в юникоде это хорошо и можно использовать, но нужно будет подыскать шрифт где она есть. Я не думаю что в шрифтах рисуют все символы юникода. Или придется костлять такие символы в клиенте вручную.
avatar
Псевдографика в юникоде это хорошо и можно использовать, но нужно будет подыскать шрифт где она есть
Чо искать-то — DejaVu, Menlo, Consolas.
avatar
На американском мадконнекторе сейчас как раз обсуждают вопрос внутриигрового билдинга: http://www.mudconnect.com/SMF/index.php?topic=79784.0. В общем, в случае хранения игровой информации в базах данных есть гибкие веб-UI типа: http://simov.github.io/express-admin/, которые можно легко переделать в игровой редактор.
avatar
Традиционно разработчики серверов идут от абстрактного к частному, сначала делают ядро, которое не умеет ничего, кроме как принимать подключения игроков и игрокам на таком сервере предлагается для начала только чатиться, затем делаются объекты с которыми можно совершать простые действия, потом примитивные мобы, а потом в самом конце для всего этого делают редактор, если силы на него остаются.

Это традиционный подход. А, мне кажется, что можно идти и от обратного. Сначала создаем простой редактор зон (GUI) и делаем его модульным. Сначала он может лишь создавать описания комнат, постепенно добавляем ему функционал: возможность создавать объекты, мобов. Прикручиваем какой-нибудь скриптовый язык для оживления мобов. Сетевую часть добавляем в самом конце, когда мир уже полностью готов и существует сам по себе, причем делаем ее тоже модульной, хочешь подключаешь телнет, хочеш ssh и т.д. Получится этакая революционная кузница миров, где можно творить, что хочешь. Можно сделать классический мад, можно одиночный IF, в общем на что фантазии хватит.

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

Блин, не там комментарий оставил.
avatar
Начинать с редактора неверно, ведь сил на сам сервер может и не остаться, если повторить часть предыдущего поста. Лучше до написания кода, начать с сеттинга мада. Тут хотя бы будет видна конечная цель. И, как я уже сказал ранее, редактор для мада — зря потраченное время. Основная часть билдера — писать текст и вбивать цифры. Для этого подойдет текстовый редактор. Единственное, что будет полезно, это всякие помощники для этого текстовика — в виде шаблонов-заготовок для моба и других помощников.
avatar
Лучше до написания кода, начать с сеттинга мада.
А если пишется универсальный движок для создания мадов?) В каждом маде свой сеттинг.

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

Единственное, что будет полезно, это всякие помощники для этого текстовика — в виде шаблонов-заготовок для моба и других помощников.
Это называется сниппетами, и они есть в любой нормальной IDE)
avatar
А если пишется универсальный движок для создания мадов?) В каждом маде свой сеттинг.
Я не писал, что движок нужно затачивать под конкретный сеттинг, я предлагал сначала подумать что в итоге должно получится. И универсальный движок — крайне непростая задача, лучше начать с реализации сеттинга, но стараться чтобы все это можно было бы использовать и в другом маде.

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

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

И еще ты не учитываешь, что билдеру придется ставить базу данных, настраивать ее и прочее.
Под базой данных я имел место хранения данных вообще. Это необязательно СУБД, для билдинга можно просто сохранение в файл использовать.
avatar
Абсолютно не согласен. Время консольных мамонтов ушло, в 21м веке мады должны делаться мышкой, без лишней необходимости писать код. Писать километры текста, тысячи раз повторяющихся одних и тех же if...else...then...end, согласятся лишь программисты, но у них, как правило, туго с фантазией и креативностью. К тому же, это жутко неудобно, постоянно переключаться с английского на русский, когда все команды на английском, а описания и смысловой текст на русском. Говорю это по своему опыту работ с движками для IF, я перепробовал все, что смогли предложить отечественные разработчики: QSP, INSTEAD и т.д., все они написаны для программистов и сложны для входа в них. Пришлось использовать зарубежный RAGS, хотя он не расчитан на другие языки кроме английского, некоторые вещи зашиты слишком глубоко в движке и частичная англификация сохраняется в игре. RAGS позволяет создавать игры, ничего не зная о программировании и не писать кода практически ни сколько. Вот и интересно мне, почему наши программисты не могут повернуться лицом к обычным людям.
avatar
Абсолютно не согласен. Время консольных мамонтов ушло
Мад вообщето консольный мамонт. И тут играть все равно придется на клавиатуре в основном.
в 21м веке мады должны делаться мышкой, без лишней необходимости писать код.
С этим можно согласиться, но ты просто даже не представляешь трудоемкость того что ты хочешь. И практически невозможность реализовать на 100%. Нельзя реализовать сложное, уникальное и интересное поведение мобов с помошью кликов мышкой.
К тому же, это жутко неудобно, постоянно переключаться с английского на русский, когда все команды на английском, а описания и смысловой текст на русском.
Ты предлагаешь писать код на русском? К сожалению поезд ушел, все основы IT создались на базе английского. Да и русский плохо подходит в качестве языка программирования, по 1С видно.
RAGS позволяет создавать игры, ничего не зная о программировании и не писать кода практически ни сколько. Вот и интересно мне, почему наши программисты не могут повернуться лицом к обычным людям.
Проблема в черезмерной трудоемкости, проект то не коммерческий и нанять команду программистов не начто. И зачем писать редактор аля RAGS, если вся работа билдера — писать текст. Зачем изобретать, велосипед, если он уже изобретен — текстовый редактор. Все хотят универсальный движок для мада, но почему мало кто понимает, что идея редактора типа RAGS — несовместима с идеей универсального мад сервера.
Никто не заставляет писать билдера код, если он не хочет, ему просто предлагается в текстом редакторе описать поля той же комнаты, которые бы он точно также описывал в редакторе. Ему нужно только помочь со знанием тех полей, которые есть в движке (сниппеты, визарды и т.д)
Никогда не добиться гибкости текстового редактора в любом самописном редакторе. Никто не пишет редакторы для написания других сложных программ, где не придется программировать.
avatar
Никто не мешает писать код, когда тебе это нужно, открываешь блокнот и в путь, я же не говорю, что писание кода запретить нужно полностью, просто надо снизить порог входа в твою программу. В мадах слишком мало человек, чтобы хоть кем-нибудь разбрасываться.

На гитхабе и битбакете десятки новых кодовых баз, если не сотни. Вот, например, есть Evennia, у которой целых 34 разработчика. Но, заходим на mudstats и делаем сортировку по году основания мада, и что же мы видим? Почти все последние мады (а скорее всего все, так как не охота разбираться, что такое other) сделаны на движках 90х годов:
Mudstats screen
Почему так? Может быть потому, что нет смысла использовать новый движок, раз он не дает ничего нового по сравнению со старым?
avatar
А вот так современный мад может выглядеть:

Справа — миникарта, аха.
avatar
Что это?
avatar
Вывод при посещении новой комнаты. Или по look. Не похоже?)
Название комнаты, описание комнаты, список выходов, объекты, строка состояния. Классическая схема же.
avatar
Я имел ввиду откуда это, какой мад?
avatar
Пока никакой. Это постановочный скрин.
Я так разработку нового движка планирую.
avatar
  • artist
  • 0
Я бы предложил бы начать с протокола. Тащить наследие MSDP, MSP и прочее я не хочу. Хочу взять для протокола Lua и на его базе сделать протокол для мадов. Готовый парсер + обработка ошибок + песочница + легко написать адаптеры совместимости между версиями. Идеально для протокола. Нужна отдельный форум, или на худой конец группа ВК для обсуждений. Для поддержания штанов могу написать прокси из нового протокола в текущую солянку протоколов для мад клиентов.
avatar
А, клиент для такого протокола ты новый будешь писать?
avatar
Я что-то не понял насчет Lua. Сервер генерирует lua-код, который передается по сети и исполняется на стороне клиента — так, чтоли? Будет ли это работать в веб-клиенте?

А вообще, я не собирался включать работу с протоколами в движок. Движок просто предоставляет потоки ввода/вывода для каждого юзера, а уж как их использовать — личное дело каждого. Без проблем можно будет и твою схему реализовать, и какую бы то ни было еще. В теории можно даже задействовать мад-сервер в качестве сервера графической игры)
avatar
  • artist
  • 0
Все верно, луа код генерируется на сервере и выполняется на клиенте. Для веба есть луа на JS. По поводу ввода вывода не понятно — это обеспечивает TCPIP. Все уже готово. Для сервера графической игры? Ввод вывод — это 1% от общей функциональности игры. Можно поподробнее?
avatar
Все верно, луа код генерируется на сервере и выполняется на клиенте.
Остроумно) Так ведь можно и питон, и руби, и ес задействовать.

По поводу ввода вывода не понятно — это обеспечивает TCPIP.
Ты не понял.
Я имел в виду, что в самом движке работа с протоколами отсутствует. Движок занимается логикой игрового мира, обработчик протокола — отдельный модуль, зависящий от конкретного мада. Модули взаимодействуют через потоковый интерфейс.
avatar
  • artist
  • 0
Остроумно) Так ведь можно и питон, и руби, и ес задействовать.
Можно и руби и питон, но плюс Lua в компактности и там есть песочница из коробки (для кода, которому нельзя доверять). Lua — это 200кб бинарника, а питон и руби еще придется ставить на клиентский комп отдельным пакетом.
avatar
Можно и руби и питон, но плюс Lua в компактности и там есть песочница из коробки (для кода, которому нельзя доверять). Lua — это 200кб бинарника, а питон и руби еще придется ставить на клиентский комп отдельным пакетом.
Во как.
В свою очередь, плюс ES — нативная поддержка браузерами. Хотя, для клиента интерпретатор будет весить уже больше, под несколько мегабайт.
avatar
  • prool
  • 0
Я нифига не понял :)

Сервер будет высылать клиенту исполнимый код, а клиент будет этот код исполнять? Как-то это не сочетается с идеями безопасности. Вот щас я напишу сервер, который будет посылать rm -rf ;-)

Я думал, что свой протокол, это какое-то расширение обычного мад-протокола, например, будут высылаться какие-то xml-файлики с командами типа расширенного управления шрифтами, цветом, звуком, окнами, картой, еще чем-то

Хотя ты упоминаешь «песочницу», это наверное слегка усилит безопасность
avatar
Вот щас я напишу сервер, который будет посылать rm -rf ;-)
А кто-то говорил, что языком будут никсовые утилиты?

Сервер будет высылать клиенту исполнимый код, а клиент будет этот код исполнять? Как-то это не сочетается с идеями безопасности.
Когда ты заходишь на сайт muder.ru, сервер посылает тебе исполнимый код (в том числе тьюринг-полный JS), который браузер послушно исполняет. Но ты же не беспокоишься о безопасности?
Просто коду не предоставляется никаких средств ввода-вывода, которые могли бы навредить безопасности — это и называется песочницей.
avatar
  • prool
  • 0
JavaScript писали десятки человек, а тестировали тысячи, да и то порой в js находят уязвимости.

А тут будет продукт, сделанный командой в 2-3 человека. Понятно, что паранойя должна иметь пределы и точно так же нельзя доверять, например, бинарнику Тортиллы, или JMC, да и любому другому приложению.
avatar
порой в js находят уязвимости
Уязвимости могли находить в окружениях, предоставляемых браузерами. Если окружения попросту нет, о каких уязвимостях может идти речь? JS сам по себе вообще никаких средств ввода-вывода не имеет. Луа имеет, но с помощью песочницы все они точно так же «отключаются» (на самом деле, конечно, не отключаются, а попросту не предоставляются). Без I/O максимальное, на что способна вредоносная программа — это загрузить процессор (опять же, решаемо).

А тут будет продукт, сделанный командой в 2-3 человека.
Никто не собирался самостоятельно интерпретатор писать) Разумеется, будет взят уже готовый и тысячу раз проверенный.
avatar
  • artist
  • +1
На базе черепахи будет новый клиент. С нуля большого смысла нет. Можно взять Qt чтобы сделать нативные клиенты и под мак и линух и перетащить туда код черепахи. Новый протокол одназначно нужен, но сразу все этот объем работы не осилить. Скорее всего придется написать сначала прокси с нового протокола — в солянку старых мад протоколов. Это что бы не писать новый клиент, а использовать старые.

Оставить комментарий

Комментировать при помощи:
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.