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. Дать возможность серверам коммуникации между собой. Тут можно объединить чаты нескольких мадов, базы игроков и прочее.
На этом пока все требования.
Технологии ушли вперед, мады пока нет. Тут я хочу попробовать собрать требования к современному мад серверу, который хотелось бы иметь и попробовать объяснить почему.
Итак требования.
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. Дать возможность серверам коммуникации между собой. Тут можно объединить чаты нескольких мадов, базы игроков и прочее.
На этом пока все требования.
51 комментарий
Не согласен насчет редакторов. Билдеру или любому дизайнеру зон очень важно видеть картину целиком, что у него получается в целом. А, еще лучше, чтобы было видно, как это выглядит во всем игровом мире, то есть даже не одну зону, а целый комплекс зон поблизости. Это нужно, чтобы у нас не получалась пустыня посреди леса, например, или джунгли на крайнем севере. Переход между зонами должен быть плавным и логическим. В этом помогает, в частности, миникарта редактора. Когда никаких подсказок нет, а пишешь только голые строчки кода, очень трудно увидеть всю картину целиком, к сожалению. Или придется пользоваться бумагой и чертить и прикидывать все на ней, но это, мне кажется, каменный век.
Другим хорошим подспорьем для билдера является также автоматизация однотипных нудных процессов. Например, проставление одних и тех флагов для нескольких десятков мобов или объектов. Такая бессмысленная рутина очень сильно бьет по творческой мотивации писать зону, особенно человеку, который за свой труд ничего не получает.
2. Действительно без миникарты — картину в целом невидно, но нарисовать ее на бумаге несложно. Я не считаю что это прошлый век, но тратить время на редактор не вижу смысла, т.к. на него уходит гигантское время программиста. Что проще — нарисовать зону на бумаге, а потом ее соединить в коде или ждать пока программист сделает миникарту. В редакторе ты сможешь соединить только тем механизмом, что позволяет сам редактор (простой переход, дверь и пожалуй это все), а если делать это кодом, можно делать вообще все угодно (переходы в зависимости от характеристик персонажей, наличие предметов, висящих аффектов ).
В крайнем случае можно сделать миникарту чисто для ориентирования, но она не будет отражать все ньюансы. Очень сложно визуализировать ту механику, которую можно задать в виде кода.
Редактор удобен билдерам, согласен, они привыкли к нему, но он очень сильно их ограничивает в возможностях. Редактором можно сделать только то, что поддержал программист в этом редакторе, а движок мада сможет гораздо гораздо больше. Редактор — это камень на шее мадов. Это можно будет только продемонстрировать примером в будущем.
Из наглядных примеров, ты можешь сравнить мады у которые есть удобный редактор (Сфера Миров, Былины) и у которых нет редактора вообще (Неронис), и сделать вывод сколько билдеров трудятся для первых мадов и сколько над Неронисом, у которого и мир, кстати, спроектирован с серьезными косяками.
Если разработка редактора занимает кучу времени и сил, то делай как обычно делают в современных мадовских движках, типа CoffeeMUD или Evennia. Редактор зон там часть движка, совмещен с админской веб-панелью мада. Заходишь браузером и создаешь зону прямо на сервере, тут же смотришь всю статистику, теституеь и подключаешь ее. И вопросов с правами на зону в таком случае возникает намного меньше.
Ты забываешь про падежи, в которых легко запутаться, описаниях и характеристиках мобов. Нужно помнить какой командой задать родительный падеж, какой командой установить силу или степень уклонения моба. Это десятки команд которые нужно запомнить, порог вхождения увеличиется колоссально. В редакторе же на все это подсвечиваются подсказки.
Такой механизм, в частности, позволяет видоизменять живой сервер на лету, без всяких перезагрузок (что особенно удобно для исправления багов игровых зон, опечаток).
Но. Я против мультиплатформенности. Потому как если мад это сервер плюс почта плюс веб-сервер для статистики и управления, то сделать мультиплатформенно означает по сути делать два разных (пусть и близких проекта) — один для UNIX, второй для Windows. Вы еще MacOS упомяните, у многих ноутбуки от Эппла ;)
В общем, мад сервер должен быть под Centos Linux.
А как работать разработчикам? Нужен или отладочный мад на том же виртуальном сервере (или на другом таком же) или пусть стаят у себя виртуальную машину. Сейчас это не сложно и мощности современных ноутбуков позволяют
А насчет (два мад сервера — рабочий и отладочный на одном сервере на одном порту, это наверное опечатка. Или на разных портах или на разных серверах)
Отладочный мад, которые в сети, а не локально на виртуальной машине — вполне нужная штука, где можно обкатывать зоны всеми сразу, а не в одиночку.
Два сервера на одном порту — это не опечатка. Это вполне реализуемо, но программно. Это похоже на технологию Load Balancer.
А поднимать виртуальную машину ради одного только мад-сервера — это какой-то оверхед. Энивей, при нормальном подходе поддержка мультиплатформенности нынче ничего (или почти ничего) не стоит.
Изменение — это обычная замена скрипта, как переменную в коде.
Бекап — тут можно остановить игровой процесс, оставить например только чат, чтобы не было скучно ждать бекап.
Большинство современных мадов используют только изменение цвета по трехбитной палитре и bold-начертание (для ярких цветов), более продвинутые используют смену цвета фона. Но возможно ведь гораздо больше.
1. На линуксах/макоси уже давно стало стандартом использовать 8-ми битную цветовую палитру (256 цветов, где 16 — оттенки серого, а остальные 240 — градации стандартных восьми). Некоторые могут возразить, что мад с таким количеством цветов получится слишком вырвиглазным, но я считаю иначе: такая палитра как раз-таки позволит выбирать наиболее приятные для глаза оттенки и создавать плавные цветопереходы, что в итоге благоприятно скажется на качестве картинки.
Но и это еще не предел. При желании можно использовать 24-битную палитру — это весь RGB-диапазон (256 * 256 * 256 = 16 777 216 цветов). Поддержка эмуляторами терминала здесь, конечно, хуже, но для игры все равно используют мад-клиенты, так что почему бы и нет?
2. При переходе на 8-ми битную палитру отпадает необходимость использовать bold-последовательность (CSI1m) для представления ярких цветов (они включены в палитру в качестве реальных цветов), так что возможен будет жирный текст.
Также ANSI предусматривает подчеркнутое, мигающее (поддерживаются еще xterm'ом), курсивное и перечеркнутое начертание (здесь с поддержкой похуже).
3. Управление курсором — это нужно для обновления произвольных областей терминала клиента. Сходу два наиболее актуальных юз кейса: 1) автоматически обновляющаяся строка статуса и 2) индикатор прогресса для умений с предзадержкой.
И это только наиболее популярные возможности вывода терминалов, при необходимости можно задействовать (или придумать самому) намного больше.
На подробный список небуквенных символов юникода можно полюбоваться на википедии отсюда и до конца страницы.
Но, в принципе, да, как вариант.
Это традиционный подход. А, мне кажется, что можно идти и от обратного. Сначала создаем простой редактор зон (GUI) и делаем его модульным. Сначала он может лишь создавать описания комнат, постепенно добавляем ему функционал: возможность создавать объекты, мобов. Прикручиваем какой-нибудь скриптовый язык для оживления мобов. Сетевую часть добавляем в самом конце, когда мир уже полностью готов и существует сам по себе, причем делаем ее тоже модульной, хочешь подключаешь телнет, хочеш ssh и т.д. Получится этакая революционная кузница миров, где можно творить, что хочешь. Можно сделать классический мад, можно одиночный IF, в общем на что фантазии хватит.
Для игрока самое важное это конечный результат, какой получится игра, и от этого конечного результата надо и попробовать идти.
Блин, не там комментарий оставил.
Для сохранения моделей в базу данных в любом случае понадобится описывать схему. Эту же схему может автоматически подцеплять редактор, и ничего дописывать каждый раз не придется.
Это называется сниппетами, и они есть в любой нормальной IDE)
Направление мысли конечно вполне здравое, вот только вопрос, ты это пробовал реализовать на практике? Тут такая куча вопросов появится… как и что делать. И еще ты не учитываешь, что билдеру придется ставить базу данных, настраивать ее и прочее. А билдеры в основном, не профессиональные программисты.
Сниппеты нужно еще реализовать. Т.е. найти подходящее IDE и допилить под задачи мада. А у каждого мада может быть свой набор сниппетов.
Под базой данных я имел место хранения данных вообще. Это необязательно СУБД, для билдинга можно просто сохранение в файл использовать.
С этим можно согласиться, но ты просто даже не представляешь трудоемкость того что ты хочешь. И практически невозможность реализовать на 100%. Нельзя реализовать сложное, уникальное и интересное поведение мобов с помошью кликов мышкой.
Ты предлагаешь писать код на русском? К сожалению поезд ушел, все основы IT создались на базе английского. Да и русский плохо подходит в качестве языка программирования, по 1С видно.
Проблема в черезмерной трудоемкости, проект то не коммерческий и нанять команду программистов не начто. И зачем писать редактор аля RAGS, если вся работа билдера — писать текст. Зачем изобретать, велосипед, если он уже изобретен — текстовый редактор. Все хотят универсальный движок для мада, но почему мало кто понимает, что идея редактора типа RAGS — несовместима с идеей универсального мад сервера.
Никто не заставляет писать билдера код, если он не хочет, ему просто предлагается в текстом редакторе описать поля той же комнаты, которые бы он точно также описывал в редакторе. Ему нужно только помочь со знанием тех полей, которые есть в движке (сниппеты, визарды и т.д)
Никогда не добиться гибкости текстового редактора в любом самописном редакторе. Никто не пишет редакторы для написания других сложных программ, где не придется программировать.
На гитхабе и битбакете десятки новых кодовых баз, если не сотни. Вот, например, есть Evennia, у которой целых 34 разработчика. Но, заходим на mudstats и делаем сортировку по году основания мада, и что же мы видим? Почти все последние мады (а скорее всего все, так как не охота разбираться, что такое other) сделаны на движках 90х годов:
Почему так? Может быть потому, что нет смысла использовать новый движок, раз он не дает ничего нового по сравнению со старым?
Справа — миникарта, аха.
Название комнаты, описание комнаты, список выходов, объекты, строка состояния. Классическая схема же.
Я так разработку нового движка планирую.
А вообще, я не собирался включать работу с протоколами в движок. Движок просто предоставляет потоки ввода/вывода для каждого юзера, а уж как их использовать — личное дело каждого. Без проблем можно будет и твою схему реализовать, и какую бы то ни было еще. В теории можно даже задействовать мад-сервер в качестве сервера графической игры)
Ты не понял.
Я имел в виду, что в самом движке работа с протоколами отсутствует. Движок занимается логикой игрового мира, обработчик протокола — отдельный модуль, зависящий от конкретного мада. Модули взаимодействуют через потоковый интерфейс.
В свою очередь, плюс ES — нативная поддержка браузерами. Хотя, для клиента интерпретатор будет весить уже больше, под несколько мегабайт.
Сервер будет высылать клиенту исполнимый код, а клиент будет этот код исполнять? Как-то это не сочетается с идеями безопасности. Вот щас я напишу сервер, который будет посылать rm -rf ;-)
Я думал, что свой протокол, это какое-то расширение обычного мад-протокола, например, будут высылаться какие-то xml-файлики с командами типа расширенного управления шрифтами, цветом, звуком, окнами, картой, еще чем-то
Хотя ты упоминаешь «песочницу», это наверное слегка усилит безопасность
Когда ты заходишь на сайт muder.ru, сервер посылает тебе исполнимый код (в том числе тьюринг-полный JS), который браузер послушно исполняет. Но ты же не беспокоишься о безопасности?
Просто коду не предоставляется никаких средств ввода-вывода, которые могли бы навредить безопасности — это и называется песочницей.
А тут будет продукт, сделанный командой в 2-3 человека. Понятно, что паранойя должна иметь пределы и точно так же нельзя доверять, например, бинарнику Тортиллы, или JMC, да и любому другому приложению.
Никто не собирался самостоятельно интерпретатор писать) Разумеется, будет взят уже готовый и тысячу раз проверенный.