www.mudconnector.su

Собственно раз уж собралось довольно много народу, можно собрать мысли касательно расширяемости.
Что хотелось-бы: построить архитектуру хорошо управляемого извне движка.
Т.е. речь о том, чтобы, скажем, скиллы можно было целиком или на 99% программировать "снаружи".

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

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

Думаю полезно будет не только мне.

В идеале мне хочется продумать архитектуру, где люди с соответствующими правами, без доступа
к исходникам ядра смогут сами реализовать (почти) любые умения, сами отладить итп.
Причем, разумеется, нужны механизмы, которые не позволят им по случайности "завалить весь сервер".
Т.е. по-хорошему надо вести статистику потребления ресурсов скиллами итд итп.

Да, Луа 5.1.4. А вскоре будет Луа 5.2.0.
ИМХО идеальный скриптовый язык для МАДов (и не только).

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

Писал, не так давно, в блоге про производительность одной LUA-библиотеки для .Net'а.

http://omlin.blogspot.com/2010/10/luainterface.html

Получается, что даже если использовать lua.dll напрямую, 1 млн. присваиваний полю таблицы занимает 7 секунд. Для сравнения, в шарпе, простейший цикл на 1 млн. присваиваний рэндомного гуида полю класса, занимает 0.0156250 секунды.

А ведь в маде у каждого из объектов - десятки полей, передавать нужно за одно событие 3-4 объекта, помножьте хотя бы на 5 сотен вызовов за цикл мада (ведь вы собираетесь внедрять луа где только можно? тогда 5 сотен вызовов это очень скромная цифра).

Получаем, 0.1 секунды только на передачу полей, БЕЗ логики. Цикл в адане вроде 0,2 секунды, дак частенько провисает, и это без всякого луа. Вот и думайте...

Я склонен считать, что такие вещи, как умения, нужно делать просто отдельными классами, которые подписываются на события движка.
Если очень хочется, сделайте это в виде отдельной dll-ки, подгружаемой в движок в качестве плагина.
В этом случае, архитектурно всё будет весьма грамотно, и производительность никак не пострадает.

Очень хочется, чтобы можно было делегировать возможность делать скилы куда-то вовне.
И подключать их БЕЗ проверок "лично". Собственно это же касается и многих других аспектов
игровой механики.
Т.е. нужен какой-то бокс, в котором ничего существенного сломать нельзя.
Кроме балланса-игроков итп . (это решаемо )

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

Как альтернативу, можно себе представить некую кастомизацию скилов по шаблонам.
Т.е. редактирование ресурсов фактически. Как это везде и сделано.
Но тут уже всё будет много грустнее.
Никаких существенных улучшений изнутри такого jail-а не сделать.

Третий подход: смешанный. Большинство скиллов-аффектов итп реализуются на уровне мада,
и можно только "выбрать тип и заполнить поля", другие можно написать целиком снаружи.
Но тут всё зависит в процентном соотношении. Надо как-то собирать статистику и периодически
"переписывать" написанное снаружи и много жрущее.

Изначально мне хотелось бы иметь архитектуру в которой ГМ с соответствующими полномочиями
может подправить или сделать [любой] скилл "на лету". Понятно, что не любой , но 95%
потребностей хотелось бы покрыть. При этом однопоточное все будет или многопоточное
мне честно говоря пофиг. Эти мысли не для интеграции в циркуль.

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

ну замерялось то что в статье - на Core 2 Duo E8400 @ 3.00GHz 3.00GHz; 8 Gb RAM
индекс производительности Windows (шкала от 1.0 до 7.9):
процессор 6.5
память 6.5

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

omlin, imho Вы несколько сгущаете краски относительно производительности Луа.
Например,

неправда.
Код

выполняется за 0.124 секунды.
Если же присваивать миллиону индексов миллион значений, такой же код выполняется за 0.224 секунды.

Да, таблицы в Луа медленнее массивов по адресу в С из-за rehash и прочих collectgarbage. Но если знать некоторые основные правила оптимизации Луа-кода, то всё не так страшно. Например, вызывать как можно более локальные функции. (Главные правила оптимизации Don't do it и, для экспертов, Don't do it yet, конечно, тоже не стоит забывать). В общем, Lua Performance Tips by Roberto Ierusalimschy из Lua Programming Gems в помощь.

И да, типичный bottleneck производительности - передача данных между скриптом и программой.

Тут вопрос в том, "а много ли ей надо".

ЗЫ. У вас какие-то жесткие очень примеры, можно лучше
t={}
for i = 1, 10^3 do
for j = 1, 10^3 do
t[1]=i*j
end
(синтаксисом не владею, но мысль я думаю ясна, тут вы можете
мерять оверхед возникающий в гиганских массивах, у нас таких не будет явно)

Тьфу... написал и понял, что написал фигню.
В общем не 1 массив на 10^6 записей, а 10^3 массивов по 10^3 записей
столь же быстро будут работать ?

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

я извиняюсь, но всё же 1 млн. присваиваний полю таблицы происходят очень быстро.
Вот 1 млн присваиваний с параллельным созданием 1000 массивов будет медленным, не спорю. Например, код


выполняется за 0.339 секунд.

А вот такой, что соответствует примеру в Вашей статье:

за 0.115 секунд.
Можно ещё сделать очень медленно вот так:


что займёт 0.517 секунд.

Как видите, я тоже не занимаюсь голословными утверждениями. Я сам ожидал гораздо худших вариантов, особенно в первом примере из данного ответа.
Это кстати то, чего не хватает в Вашей статье: сравнение производительности с чистым скриптом.

Так вот, я делаю вывод, что либо LuaInterface очень медленный, либо вызов метода объекта в C# вот так: `LuaDLL.lua_pushstring`, либо, если для С ситуация повторится,

"типичный bottleneck производительности - передача данных между скриптом и программой."(c)

Ну, ещё возможно у Вас слишком часто вызывается GC, или опять же слишком часто происходит rehashing таблиц.
UPD: последние 3 предположения (практически) наверняка бред.

У меня в маде так: есть класс, отвечающий за основу умения. От него наследуются классы обычных умения, боевых, заклинаний и т. д. А вот они уже загружаются из внешних файлов, в которых прописываются формулы расчета повреждений/восстановлений и вообщем аффектов.
Чем такая система плоха? Не знаю, так как еще не дописал ее.

_________________
Кодер и билдер MUD Shaal (Мада Мир Шааль).