www.mudconnector.su

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

Флаг должен реализовываться на базе подключения скрипта к объекту, который отвечает за флаг,
а не жестко зашитый код в движок. Это мое виденье вопроса.

Не очень понимаю. Вы как-то добъетесь того, что апач (или кто там вебсервер) станет однопоточным.
С синхронизацией-то как ?


В реальном циркуле существенная часть действий делается раз в 10 секунд.





Описания сущностей должны быть четко продуманы.
Само понятие "флагов" ущербно по определению, при нормальном дизайне нет флага IsAlive,
есть либо такое поле, либо поле race дающая ответ на этот вопрос.
При нормальном дизайне флаг типа "can-be-used-for-zone-0001" также не может появиться.

Изначально идеология всех русских проектов, что я видел отравлена circle и подобными движками,
когда-то на заре программирования использовали битовые маски, чтобы экономить память.
В результате появились все эти "массивы флагов" куда сували черти че лишь бы оно 1 бит, а не
1 байт использовало. Свалки гиганские данных.

И потом всё это "поперло"(увы не без моего участия) в редакторы, где мы видим тонны никому не нужного
поведения, которое включается галочками. Вместо реально необходимой информации.

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

Тут я с вами не соглашусь. Можно как угодно это называть и реализовывать.
Однако если редактор разумно сделан, то иметь в нём возможность подобного поведения в "один клик" необходимо.

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

Я рассматриваю флаги как набор условий и обработчиков, применяемых к комнате и всему в ней - и сведены эти функции к одному кодовому слову для удобства билдера. Например он указывает -nopk а сервер это обрабатывает, и зашита эта функция в движке потому что она часто используется. Если же билдеру нужно назначить свои условия, он может это сделать в параметре (например) scripts: ... (или румпрогс)
Я не говорю что должны быть флаги и кроме них не должно быть возможности расширений. Но минусов самих флагов я не вижу. Может не так понял мысль?

К слову, yaml можно конвертить и в json, и в ассоциативный массив, и как угодно еще. И обратно тоже. Я сейчас пишу парсер зон в моем формате, который текстовый файл превращает в набор пхп-объектов "комната", и записывает их в базу. Так же и из базы сможет экспортировать в понятный человеку текстовый файл всю зону.

По хостингу - у меня есть VDSка, на ней сейчас сервер майнкрафта крутится =)
Я понимаю ограничения шаред хостинга. Потому и хотел чтобы мой движок могли запустить на обычном хостинге, так как это гораздо доступнее чем вдска или дедик. Но аргументы твои (можно на ты?) и KadVar по поводу прямого соединения мне кажутся убедительными, так что сегодня углубился в изучение вебсокетов.

То что из питера - это хорошо! Погоду бы еще нам получше, а то даже и не погулять - приходится муд писать

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


Объекты и запись в базу данных. При запросе клиенту вываливается все что он пропустил - синхронизация по такому принципу (при условии что реалтайм невозможен). Если использовать сокеты, то данная проблема перестает существовать. Я уже смотрю в эту сторону.

Зашибись удобство читать что-то типа
-nopk -evilpro -goodsan -infr -mustbeeq -nodr итп
Вам тут всё понятно ?


Вопрос у кого нужна доступность.
Амазон дает бесплатный на год ВПС. Очень некислый.
Но надо чуть-чуть ума.



Клиент 1 дал команду поднять с пола предмет.
Клиент 2 дал команду поднять с пола предмет.
Одновременно
Кто поднимет предмет ?
Что будет если все проверки "пройдут", и оба воркера апача одновременно запустят соответствующие SQL ?

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

Использовать в качестве формата описания зон Yaml мне нравится, это очень простой текстовый формат,
c отступами и т. д. Читается очень легко!

Хотя я думал над вариантом, когда в качестве формата зон используется Lua и в качестве протокола для мада тоже используется Lua,
так как это и виртуальная машина - можно исполнять код, то есть очень удобно в качестве протокола и
синтаксический анализатор, можно описывать структуры данных. Структуры описываются в Cи-стайле, тут есть скобочки (чуть сложнее Ямля,
но ему пофиг на отступы, а Ямлю нет).
Тут же можно писать и скрипты зон,
Можно делать предкомпиляцию-проверку,
быструю загрузку зон - так как структура зоны по сути является программой, то есть не нужно писать парсер зон.

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

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

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

Я исключительно против "бессмысленной свалки" которую представляют из себя т.н. "флаги".

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

Вопрос уже к Rottenwood:
Ты думал над тем как будут программировать билдеры скрипты в движке ? На PHP, на JS ? Как насчет песочницы
для выполнения таких скриптов ? Как насчет того чтобы измерять скорость работы скриптов (профайлер) ?
А это очень важный вопрос.

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



SQL запрос сам по себе содержит проверку, которая не допустит подобного. В MySQL реализована очередь запросов. Но даже до нее есть очередь обработчика команд (на стороне пхп), так что такая ситуация что оба пройдут проверку и возьмут вещь - при нормальных обстоятельствах невозможна. Если имеются ввиду задачи посложнее и потяжелее - то в симфони всегда есть возможность проверить другие запущенные процессы.



Размышляя об этом я пришел к таким вариантам:
1. я хочу написать некий псевдоязык, представляющий из себя абстракцию высокого уровня предоставляющую доступ к т.н. "техническим" командам. Эти команды билдер сможет использовать в построении простых прогсов.
2. для тех кому нужна тюринг-фул среда для создания скриптов - будет реализована интеграция с Lua (а вариантов-то особо и нет). Пхп умеет реализовывать луашные скрипты.
3. возможность напрямую вызывать пхп скрипты считаю излишней.

Это будет ошибкой имхо. Не надо изобретать велосипед. Если решил Lua - значит делай на Lua без особых вариантов. Плюс очень желательно профайлер, чтобы находить тормозные скрипты.