www.mudconnector.su
https://forum.mudconnector.su/

mud design-concepts (расширяемость)
https://forum.mudconnector.su/viewtopic.php?f=16&t=244		 Страница 1 из 3
Автор:  KadVar [ Чт ноя 18, 2010 12:57 pm ]
Заголовок сообщения:  mud design-concepts (расширяемость)
Собственно раз уж собралось довольно много народу, можно собрать мысли касательно расширяемости.
Что хотелось-бы: построить архитектуру хорошо управляемого извне движка.
Т.е. речь о том, чтобы, скажем, скиллы можно было целиком или на 99% программировать "снаружи".

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

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

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

В идеале мне хочется продумать архитектуру, где люди с соответствующими правами, без доступа
к исходникам ядра смогут сами реализовать (почти) любые умения, сами отладить итп.
Причем, разумеется, нужны механизмы, которые не позволят им по случайности "завалить весь сервер".
Т.е. по-хорошему надо вести статистику потребления ресурсов скиллами итд итп.
Автор:  Эрендир [ Чт ноя 18, 2010 4:55 pm ]
Заголовок сообщения:  Re: mud design-concepts (расширяемость)
Цитата:
Сейчас, вероятно, появилось уже что-то более могучее.


Да, Луа 5.1.4. А вскоре будет Луа 5.2.0. :)
ИМХО идеальный скриптовый язык для МАДов (и не только).
Автор:  omlin [ Чт ноя 18, 2010 10:15 pm ]
Заголовок сообщения:  Re: mud design-concepts (расширяемость)
У меня сейчас сложился большой опыт практического применения луа. Для текущей концепции однопоточных мадов луа применять нужно очень аккуратно, из-за его производительности. Затраты на вызов луа-движка, даже с "прекомпиленными" функциями (т.е. которые уже загнаны в луа-стэк), довольно серьезные. Выносить в него такую частоиспользуемую логику, как скиллы, не думаю что правильно. Одно дело триггерные атаки боссов и прочие триггеры, которые вызываются сравнительно редко, совсем другое дело - боевая механика. Со временем количество вызовов в цикл может достигать уже сотен и тысяч, и мад начнет проседать. Не забывайте, ведь в луа еще надо передавать данные, а это не быстро.

Писал, не так давно, в блоге про производительность одной 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-ки, подгружаемой в движок в качестве плагина.
В этом случае, архитектурно всё будет весьма грамотно, и производительность никак не пострадает.
Автор:  KadVar [ Пт ноя 19, 2010 11:35 am ]
Заголовок сообщения:  Re: mud design-concepts (расширяемость)
omlin писал(а):
Я склонен считать, что такие вещи, как умения, нужно делать просто отдельными классами, которые подписываются на события движка.
Если очень хочется, сделайте это в виде отдельной dll-ки, подгружаемой в движок в качестве плагина.
В этом случае, архитектурно всё будет весьма грамотно, и производительность никак не пострадает.


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

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

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

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

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

Кстати о поточности... многопоточность тоже "вещь о двух концах". Честно говоря толком
применение к маду не вижу... если только в отдельном потоке всю коммуникационную часть
сделать, а разбор команд и сами действия в другом... но толку с этого никакого внятного
не будет. DNS-ы можно резолвить отдельным потоком... а что еще... не знаю.
"Каждому юзеру - свой поток" - это был бы странный лозунг.
"Я тебя первый зарезал, потому как мой поток на менее загруженном ядре крутится".
Автор:  omlin [ Пт ноя 19, 2010 3:43 pm ]
Заголовок сообщения:  Re: mud design-concepts (расширяемость)
ну замерялось то что в статье - на Core 2 Duo E8400 @ 3.00GHz 3.00GHz; 8 Gb RAM
индекс производительности Windows (шкала от 1.0 до 7.9):
процессор 6.5
память 6.5

дома машина гораздо слабее, а результаты почти такие же
не знаю, насколько решит железо, если честно, надо пробовать
в любом случае, луа - это довольно долго. факт.
Автор:  Эрендир [ Пт ноя 19, 2010 4:56 pm ]
Заголовок сообщения:  Re: mud design-concepts (расширяемость)
omlin, imho Вы несколько сгущаете краски относительно производительности Луа.
Например,
Цитата:
1 млн. присваиваний полю таблицы занимает 7 секунд.

неправда.
Код
Код:
t={}
for i = 1, 10^6 do
   t[1]=i
end

выполняется за 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 производительности - передача данных между скриптом и программой.
Автор:  KadVar [ Пт ноя 19, 2010 5:06 pm ]
Заголовок сообщения:  Re: mud design-concepts (расширяемость)
Эрендир писал(а):
И да, типичный 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 записей
столь же быстро будут работать ?
Автор:  omlin [ Пт ноя 19, 2010 9:02 pm ]
Заголовок сообщения:  Re: mud design-concepts (расширяемость)
Эрендир писал(а):
неправда.

читай что написано, прежде чем отвечать
во-первых, дело не в производительности скриптов луа как таковых, я говорил про Lua C API
во-вторых, в посте приведен текст программы, на которой всё это проверялось. я не занимаюсь голословными утверждениями, я действительно это запустил и протестировал.
в-третьих, очень хорошее начало разговора - обвинить человека во лжи
Автор:  Эрендир [ Пт ноя 19, 2010 9:44 pm ]
Заголовок сообщения:  Re: mud design-concepts (расширяемость)
я извиняюсь, но всё же 1 млн. присваиваний полю таблицы происходят очень быстро.
Вот 1 млн присваиваний с параллельным созданием 1000 массивов будет медленным, не спорю. Например, код

Код:
t={}
for i = 1, 10^3 do
   t[i]={}
   for j = 1, 10^3 do
      t[i][j]=i*j
   end
end

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

А вот такой, что соответствует примеру в Вашей статье:
Код:
foo={}
for i = 1, 10^6 do
   foo.bar=10
end

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

Код:
for i = 1, 10^6 do
   foo={}
   foo.bar=10
end

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

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

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

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

Ну, ещё возможно у Вас слишком часто вызывается GC, или опять же слишком часто происходит rehashing таблиц.
UPD: последние 3 предположения (практически) наверняка бред.
Автор:  Харч [ Пт ноя 19, 2010 10:08 pm ]
Заголовок сообщения:  Re: mud design-concepts (расширяемость)
У меня в маде так: есть класс, отвечающий за основу умения. От него наследуются классы обычных умения, боевых, заклинаний и т. д. А вот они уже загружаются из внешних файлов, в которых прописываются формулы расчета повреждений/восстановлений и вообщем аффектов.
Чем такая система плоха? Не знаю, так как еще не дописал ее.
Страница 1 из 3 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/