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

Синхронизация итп, отделено.
https://forum.mudconnector.su/viewtopic.php?f=14&t=789		 Страница 1 из 5
Автор:  ArtistSpb [ Пн дек 01, 2014 9:35 pm ]
Заголовок сообщения:  Синхронизация итп, отделено.
отделено от
А что вам надо от движка-то :) ?
topic261-70.html

KadVar писал(а):
ArtistSpb писал(а):
4. А вот с основным языком разработки ядра тут нужно думать. Основное требование к ядру - как то научиться работать в многопоточности со скриптами на Lua.

Не очень понимаю как вы будете синхронизацию обеспечивать...


Если совсем простым и отработанным способом - то это база данных. Она для этого и предназначена.
Тут стоит другой вопрос - а подойдет ли данное решение для нашего случая или нет.
Если нет - то придется делать синхронизацию ручками. А это самая сложная часть движка (из системных).
Она достигается за счет мьютексов и др. системных объектов синхронизации.
Возможно придется делать комбинированный способ - БД + самоделка.
Я пока думаю в этом направлении, собираю информацию.
Автор:  KadVar [ Вт дек 02, 2014 11:56 am ]
Заголовок сообщения:  Re: А что вам надо от движка-то :) ?
ArtistSpb писал(а):
Если совсем простым и отработанным способом - то это база данных. Она для этого и предназначена.

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

ArtistSpb писал(а):
Тут стоит другой вопрос - а подойдет ли данное решение для нашего случая или нет.
Если нет - то придется делать синхронизацию ручками. А это самая сложная часть движка (из системных).
Она достигается за счет мьютексов и др. системных объектов синхронизации.
Возможно придется делать комбинированный способ - БД + самоделка.
Я пока думаю в этом направлении, собираю информацию.


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

И да, основная сложность с wait/sleep. У вас предполагается подобный функционал для lua-скриптов ?
Автор:  ArtistSpb [ Вт дек 02, 2014 11:33 pm ]
Заголовок сообщения:  Re: А что вам надо от движка-то :) ?
KadVar писал(а):
ArtistSpb писал(а):
Если совсем простым и отработанным способом - то это база данных. Она для этого и предназначена.

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


Видимо мы по разному понимаем термин синхронизации. В моем понимании - это 'разруливание'
одновременного доступа к одним и тем же данным разными частями программы (или несколькими программами).


KadVar писал(а):
Мне не очень понятно что такое "ваш случай" и что вы хотите обрабатывать параллельно.
Сама параллельная работа ничего особо сложного из себя не представляет, если не
заниматься распараллеливанием бездумно.
Рекомендую подумать что будет работать параллельно, а что последовательно, заранее.
И да, основная сложность с wait/sleep. У вас предполагается подобный функционал для lua-скриптов ?


Из требований к движку вытекает неслабая логика, которую нужно еще и запрограммировать.
И что будет получаться, если для хранения данных использовать только базу данных, неизвестно.
Не исключено, что будет все громоздко и не расширяемо. Например, чтобы добавить какое нибудь свойство
объекту в мад, придется изменять структуру базы данных. Это значит, что билдер должен знать SQL и вообще почти всю
структуру БД мада (а это не есть гуд - свои секреты у мада тоже должны быть). Причем база данных не рассчитана на то,
чтобы часто менять ее структуру, тут очень легко попасть в ситуацию - в бд полный бардак. ИМХО конечно,
но БД придется поддерживать имморталам. Помойму это не жизнеспособно.

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

KadVar писал(а):
И да, основная сложность с wait/sleep. У вас предполагается подобный функционал для lua-скриптов ?

Да планируется. Если все делать через многопоточность, то реализация одной строчкой - sleep в самой ОС (приостановка потока, в котором работает скрипт).
Автор:  KadVar [ Ср дек 03, 2014 12:20 am ]
Заголовок сообщения:  Re: А что вам надо от движка-то :) ?
Я не очень понимаю зачем вам вообще БД применительно к маду ?
"Чтобы было" ?
Под статистику идеально использовать текстовые логи...

ArtistSpb писал(а):
KadVar писал(а):
И да, основная сложность с wait/sleep. У вас предполагается подобный функционал для lua-скриптов ?

Да планируется. Если все делать через многопоточность, то реализация одной строчкой - sleep в самой ОС (приостановка потока, в котором работает скрипт).


И эээ.. как вы коллизии разрешать будете ?
После каждого sleep будете повторно 100500 проверок производить ?
Где будет несколько потоков-то, вот чего я не понял :(
Автор:  ArtistSpb [ Ср дек 03, 2014 2:21 am ]
Заголовок сообщения:  Re: А что вам надо от движка-то :) ?
KadVar писал(а):
Я не очень понимаю зачем вам вообще БД применительно к маду ?
"Чтобы было" ?
Под статистику идеально использовать текстовые логи...

Текстовые логи потом придется парсить... не в ручную же читать их...
А зачем еще писать парсер, если есть уже готовый - это база данных + SQL.
Написал SQL запрос - дай мне за сегодня количество дропа вон того артефакта
или сколько раз и кого за день убил Петя или какой закл самый популярный в бою и т.д.
С помощью БД я могу строить сбор статистики сколь угодной сложности.
С текстовыми файлами такого не сделать.
А статистика дает очень многое - в первую очередь информацию для баланса. И ее можно рисовать не в виде
текстового файла, а в виде сайта. Что-то вроде иммского сайта со статистикой. И не обязательно только имского -
можно например на сайте мада рисовать игровой чат и с сайта прямо отправлять мессаги в мад, не заходя в сам мад.
Можно будет сделать (в теории) объединение форума и внутриигровых досок.

KadVar писал(а):
И эээ.. как вы коллизии разрешать будете ?
После каждого sleep будете повторно 100500 проверок производить ?


Коллизии типа - игрок 1 берет меч, игрок 2 тоже в этот момент берет меч и т.д. и кто в итоге его возьмет ?
Это решается базой данных - это ее основная задача изначально. Решение коллизии - кто первый пришлет запрос в БД тот и возьмет меч
(читается чья игровая команда первая прилетит на сервер). Второму игроку уже не достанется меч.
Т.к. он пошлет такой же запрос в БД, как и первый игрок, но БД скажет ему - меча уже нет.

KadVar писал(а):
Где будет несколько потоков-то, вот чего я не понял :(


Потоки системные (понятие ОС). Процесс (программа) может состоять из 1+ потоков, которые выполняются параллельно и независимо друг от друга.
Ось переключает потоки по своим правилам. То есть возможно запускать несколько скриптов параллельно и они не будут мешать друг другу.
Но тут появляется задача синхронизации доступа к данным из разных потоков. Это можно решить за счет БД, а можно ручками, но это сложная задача.
Вот и нужно думать и выбирать путь для решения. Потому что для игровых данных (мобы, игроки. объекты и др.) сложно будет поддерживать и расширять
движок на базе данных. Об этом я писал в прошлом посте.

Кстати все мады, которые DIKU-based, изначально однопоточные. Поэтому возникают проблемы с лагами из-за плохих скриптов, действий игроков и т.д.
т.к. они выполняются последовательно, а не параллельно. Т.е. один плохой скрипт может "положить" весь сервер.
Автор:  Pacifist [ Ср дек 03, 2014 8:46 am ]
Заголовок сообщения:  Re: А что вам надо от движка-то :) ?
ArtistSpb писал(а):
Потому что для игровых данных (мобы, игроки. объекты и др.) сложно будет поддерживать и расширять
движок на базе данных. Об этом я писал в прошлом посте.


Почему бы не использовать подход реализованый в LPmud'ах, где игровые данные строятся с помощью lpc-языка, только c-пободные функции с большим количеством непонятных скобок заменить на луа, ну а на движок возложить работу по переносу этих данных в БД?
Автор:  ArtistSpb [ Ср дек 03, 2014 10:56 am ]
Заголовок сообщения:  Re: А что вам надо от движка-то :) ?
Pacifist писал(а):
ArtistSpb писал(а):
Потому что для игровых данных (мобы, игроки. объекты и др.) сложно будет поддерживать и расширять
движок на базе данных. Об этом я писал в прошлом посте.


Почему бы не использовать подход реализованый в LPmud'ах, где игровые данные строятся с помощью lpc-языка, только c-пободные функции с большим количеством непонятных скобок заменить на луа, ну а на движок возложить работу по переносу этих данных в БД?


На самом деле в lmud-ах игровые данные и с-подобные функции - по сути один и тот же язык.
И в нашем случае можно использовать тот же принцип, как ты и предлагаешь. Использовать луа для описания игровых данных. Это будет даже лучше xml. Чтобы загрузить данные - нужно просто запустить скрипт. И в этом скрипте можно уже как угодно инициализировать данные тех же мобов - хочешь rnd, хочешь - делай моба как повид другого моба. У билдера куча возможностей будет. Так как это не просто данные - которые надо прочитать, пропарсить и на их базе создать мобов. Это программа, а в программе можно делать все что угодно. Все уже готово - бери и используй. Ошибки тоже обрабатываются, при этом, учитывая, что в луа есть песочница - то можно обеспечить надежность, что даже самый кривой скрипт не порушит движок.

Сложность в многопоточности. Это как будет сделана связка скрипты - данные. Я не уверен, что если использовать бд хватит скорости компа на vds (тех ресурсов которые отпускает провайдер, они же ограничены) да и как это будет сотреться в комплексе я пока не знаю, поэтому я пока собираю инфу. Я занимаюсь этим вопросом, так как это ключевой момент, без решения которого все остальное смысла особо не имеет.
Автор:  KadVar [ Ср дек 03, 2014 11:58 am ]
Заголовок сообщения:  Re: А что вам надо от движка-то :) ?
ArtistSpb писал(а):
KadVar писал(а):
Я не очень понимаю зачем вам вообще БД применительно к маду ?
"Чтобы было" ?
Под статистику идеально использовать текстовые логи...

Текстовые логи потом придется парсить... не в ручную же читать их...
А зачем еще писать парсер, если есть уже готовый - это база данных + SQL.
...
С текстовыми файлами такого не сделать.

Потому, что производительность... потом "делайте что хотите".
Обратите внимание, авторы апача пишут в текстовые файлы. Есть chainsaw итд итп.
Есть много готовых проверенных решений.

ArtistSpb писал(а):
KadVar писал(а):
И эээ.. как вы коллизии разрешать будете ?
После каждого sleep будете повторно 100500 проверок производить ?


Коллизии типа - игрок 1 берет меч, игрок 2 тоже в этот момент берет меч и т.д. и кто в итоге его возьмет ?
Это решается базой данных - это ее основная задача изначально. Решение коллизии - кто первый пришлет запрос в БД тот и возьмет меч
(читается чья игровая команда первая прилетит на сервер). Второму игроку уже не достанется меч.
Т.к. он пошлет такой же запрос в БД, как и первый игрок, но БД скажет ему - меча уже нет.

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

ArtistSpb писал(а):
KadVar писал(а):
Где будет несколько потоков-то, вот чего я не понял :(


Потоки системные (понятие ОС). Процесс (программа) может состоять из 1+ потоков, которые выполняются параллельно и независимо друг от друга.

Ось переключает потоки по своим правилам. То есть возможно запускать несколько скриптов параллельно и они не будут мешать друг другу.

Я (если чё) осведомлен о потоках :)
Вы я вижу тоже. Вопрос всё тот-же, что конкретно будет исполняться параллельно ?
Неужели "всё" ?

ArtistSpb писал(а):
KadVar писал(а):
Но тут появляется задача синхронизации доступа к данным из разных потоков. Это можно решить за счет БД, а можно ручками, но это сложная задача.
Вот и нужно думать и выбирать путь для решения. Потому что для игровых данных (мобы, игроки. объекты и др.) сложно будет поддерживать и расширять
движок на базе данных. Об этом я писал в прошлом посте.

Да не поможет вам БД скорее всего.
Напишите код. Один метод всего. В произвольном синтаксисе. Хоть по-русски. Только SQL-и опишите внятно.
И я покажу вам где и как будет айайай.

ArtistSpb писал(а):
Кстати все мады, которые DIKU-based, изначально однопоточные. Поэтому возникают проблемы с лагами из-за плохих скриптов, действий игроков и т.д.
т.к. они выполняются последовательно, а не параллельно. Т.е. один плохой скрипт может "положить" весь сервер.

Не поэтому абсолютно, а потому, что не работает (хотя и запланирован) "аккаунтинг".
Плохие скипты должны вырубаться на уровне движка скриптов, но что-то там у них не работает.
Есть проблемы когда не успевает обработаться один hearthbeat, но опять-таки из-за криворукости,
там есть все данные, чтобы в этом случае следующий попросту пропускался.
Автор:  KadVar [ Ср дек 03, 2014 12:00 pm ]
Заголовок сообщения:  Re: А что вам надо от движка-то :) ?
ArtistSpb писал(а):
У билдера куча возможностей будет.

Путь к трудноуловимым и очень фатальным багам.
Возможностей должно быть ровно столько, сколько нужно. Не более.
Автор:  Pacifist [ Ср дек 03, 2014 3:55 pm ]
Заголовок сообщения:  Re: А что вам надо от движка-то :) ?
KadVar писал(а):
ArtistSpb писал(а):
У билдера куча возможностей будет.

Путь к трудноуловимым и очень фатальным багам.
Возможностей должно быть ровно столько, сколько нужно. Не более.


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

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

Потом, почему бы не взять на вооружение принципы opensource-проектов, которые также делают кто попало. Выделить ветки unstable, testing, stable и задать правила по которым они переходят друг в друга.
Страница 1 из 5 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/