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/ |