K>>если у них планы раскидать всё на кластер — это адова сложность
F>а в чём сложность?
отлаживать
в риалтаймовой сетевой игре натуральная теория относительности — нету глобального времени, есть время на каждой машине и твой код создает иллюзию консистентности происходящего
если косячишь в геометрии, скажем, то оно более-менее наглядно — можно пощупать и догадаться
а вот если косячишь в создании иллюзии консистентности — оно просто рассыпается, ты видишь что происходит полная хрень, и копаться можно долго
кластер именно эту часть усложняет — скорее всего добавятся взаимодействия между нодами: ты можешь жестко нарезать мир на независимые куски, но это будет выглядеть некруто, и тебя жаба задушит, когда игроки на один кусок навалятся и одна нода будет кряхтеть, а остальные будут простаивать
Здравствуйте, koenig, Вы писали:
K>отлаживать K>в риалтаймовой сетевой игре натуральная теория относительности — нету глобального времени, есть время на каждой машине и твой код создает иллюзию консистентности происходящего K>если косячишь в геометрии, скажем, то оно более-менее наглядно — можно пощупать и догадаться K>а вот если косячишь в создании иллюзии консистентности — оно просто рассыпается, ты видишь что происходит полная хрень, и копаться можно долго
то же самое, что с многопоточностью же
K>кластер именно эту часть усложняет — скорее всего добавятся взаимодействия между нодами: ты можешь жестко нарезать мир на независимые куски, но это будет выглядеть некруто, и тебя жаба задушит, когда игроки на один кусок навалятся и одна нода будет кряхтеть, а остальные будут простаивать
для ВоВ это круто, а для нонейм игры — не круто?
осада замка в какой-нибудь корейщине на одной ноде — это не круто?
я просто не понимаю, что именно там такое адово сложное.
в многопоточности у тебя нет сетевой задержки, и хорошие возможности по синхронизации, и в отладчике снэпшот всей системы, а если обсчет в одном треде (а остальные вспомогательные) — вообще нефиговый детерминизм
для кластера вся хрень, которая написана с учетом задержки клиент-сервер она хорошо если на 2 умножается
у тебя ведь, фактически, уже и на сервере нету мира с одними часами, и откаты становятся еще более веселыми
ну или у тебя мир жестко нарезан и между нодами ничего не ходит
но тогда ты скучный
F>для ВоВ это круто, а для нонейм игры — не круто? F>осада замка в какой-нибудь корейщине на одной ноде — это не круто?
F>я просто не понимаю, что именно там такое адово сложное.
я по себе меряю, какому-нибудь мегамозгу это не проблема вообще
Здравствуйте, koenig, Вы писали:
F>>то же самое, что с многопоточностью же K>в многопоточности у тебя нет сетевой задержки, и хорошие возможности по синхронизации, и в отладчике снэпшот всей системы, а если обсчет в одном треде (а остальные вспомогательные) — вообще нефиговый детерминизм
кто ж серваки дебаггером отлаживает?! только логи и трейсы
K>для кластера вся хрень, которая написана с учетом задержки клиент-сервер она хорошо если на 2 умножается K>у тебя ведь, фактически, уже и на сервере нету мира с одними часами, и откаты становятся еще более веселыми
точки синхронизации у тебя всё равно остаются.
для упрощения ещё можно сделать, чтобы неигровые сущности с разных серваков между собой не взаимодействовали, а только с игроком.
K>ну или у тебя мир жестко нарезан и между нодами ничего не ходит K>но тогда ты скучный
даже с нарезкой есть интересные и весёлые игры. но это вообще перпендикулярно.
F>>>то же самое, что с многопоточностью же K>>в многопоточности у тебя нет сетевой задержки, и хорошие возможности по синхронизации, и в отладчике снэпшот всей системы, а если обсчет в одном треде (а остальные вспомогательные) — вообще нефиговый детерминизм
F>кто ж серваки дебаггером отлаживает?! только логи и трейсы
это муторней и дольше
гордиться тем, что остался только этот вариант — не стоит, кмк
K>>для кластера вся хрень, которая написана с учетом задержки клиент-сервер она хорошо если на 2 умножается K>>у тебя ведь, фактически, уже и на сервере нету мира с одними часами, и откаты становятся еще более веселыми
F>точки синхронизации у тебя всё равно остаются.
а в чем радость-то? задержка — это откаты и догоняющие события из прошлого
каждая точка синхронизации завязанная на сеть — это потенциальные задержки
если у тебя 1 сервак и нет мгновенного (точнее очень быстрого) оружия тебе откаты только на клиенте нужны
F>для упрощения ещё можно сделать, чтобы неигровые сущности с разных серваков между собой не взаимодействовали, а только с игроком.
фига се упрощение
неужто кто-то такое гоняет по сети? был прецедент?
Здравствуйте, koenig, Вы писали:
F>>кто ж серваки дебаггером отлаживает?! только логи и трейсы K>это муторней и дольше
пока человек с дебаггером проползает по сотне строк кода и на середине забывает, что было в начале, человек с логами пройдёт, проанализирует, исправит тесты и запустит ещё две итерации.
K>гордиться тем, что остался только этот вариант — не стоит, кмк
т.е. логи — это плохо, а невозможность подебажить распределённую систему — это норм?
K>а в чем радость-то? задержка — это откаты и догоняющие события из прошлого K>каждая точка синхронизации завязанная на сеть — это потенциальные задержки K>если у тебя 1 сервак и нет мгновенного (точнее очень быстрого) оружия тебе откаты только на клиенте нужны
при том, что для клиентов используется одна дырка, она и будет являться точкой синхронизации.
это значит только, что количество апдейтов станет меньше, а требования к реальному времени на нодах — выше.
F>>для упрощения ещё можно сделать, чтобы неигровые сущности с разных серваков между собой не взаимодействовали, а только с игроком. K>фига се упрощение K>неужто кто-то такое гоняет по сети? был прецедент?
неписи с разных локаций в играх с плавным переходом между нодами.
F>т.е. логи — это плохо, а невозможность подебажить распределённую систему — это норм?
логи это необходимость, дебаггер — это приемущество
K>>а в чем радость-то? задержка — это откаты и догоняющие события из прошлого K>>каждая точка синхронизации завязанная на сеть — это потенциальные задержки K>>если у тебя 1 сервак и нет мгновенного (точнее очень быстрого) оружия тебе откаты только на клиенте нужны
F>при том, что для клиентов используется одна дырка, она и будет являться точкой синхронизации.
если она тупо пробрасывает пакеты — это просто дополнительная задержка, без дополнительных бенефитов в виде уменьшения конфликтов (с бенефитом в виде 1 соединение с клиентом)
а если будет бороться с конфликтами — ну вот она и будет слабым местом
зачем тогда несколько серверов городить, если все равно на выходе кто-то сидит, видит весь мир и выполняет откаты
F>это значит только, что количество апдейтов станет меньше, а требования к реальному времени на нодах — выше.
вот это не понял
апдейтов у нас столько, сколько нужно клиенту, чтобы картинка была терпимой
F>>>для упрощения ещё можно сделать, чтобы неигровые сущности с разных серваков между собой не взаимодействовали, а только с игроком. K>>фига се упрощение K>>неужто кто-то такое гоняет по сети? был прецедент?
F>неписи с разных локаций в играх с плавным переходом между нодами.
а почему их, а не игроков? по идее достаточно действия игроков гонять?
Здравствуйте, koenig, Вы писали:
F>>т.е. логи — это плохо, а невозможность подебажить распределённую систему — это норм? K>логи это необходимость, дебаггер — это приемущество
это рудимент начального программерского образования. признак низкой культуры разработки.
K>зачем тогда несколько серверов городить, если все равно на выходе кто-то сидит, видит весь мир и выполняет откаты
чтобы обработать много логики. например, кучерявый AI.
кроме того, эта точка может отбрасывать отстающие апдейты серваков и заниматься балансировкой.
F>>это значит только, что количество апдейтов станет меньше, а требования к реальному времени на нодах — выше. K>вот это не понял K>апдейтов у нас столько, сколько нужно клиенту, чтобы картинка была терпимой
если появляется точка синхронизации, которая мержит параллельные апдейты, то она будет тормозить результат для клиента.
т.е. framerate будет ниже.
F>>>>для упрощения ещё можно сделать, чтобы неигровые сущности с разных серваков между собой не взаимодействовали, а только с игроком. K>>>фига се упрощение K>>>неужто кто-то такое гоняет по сети? был прецедент? F>>неписи с разных локаций в играх с плавным переходом между нодами. K>а почему их, а не игроков? по идее достаточно действия игроков гонять?
так игроки с одной ноды видят неписей с другой. и у последних поведение должно нормально выглядеть.
Здравствуйте, Слава, Вы писали:
С>Говорят, Eve Online работает на кластере, соединённом Infiniband. Правда, такой подход противоречит обычному workflow "денег у нас нет, поэтому давайте запустимся на говне, а как деньги появятся — говна докупим, и писать будем сразу на MongoDB, она на говне хорошо масштабируется".
И там один тик равен одной секунде, на 100 мс не замахиваются.
Здравствуйте, Nikе, Вы писали:
N>У нас тут небольшой спор вышел: разделять ли физически процесс обсчитывающий игровой мир с модулем отвечающим за внешние взаимодействия (сокеты)?
Нет.
N>Т.е. можно: N>- всё оставить в рамках одного процесса. N>- использовать два приложения, которые через pipe обмениваются юзерскими пакетами. N>- вообще разделить по разным серверам, один сервер обсчитывает мир, шлёт юзерские данные через сокеты на другой сервер, а тот уже рассылает всё по миру.
А в чем преимущества 2 и 3 вариантов? Какую проблему они решают?
N>P.S. N>Игровой мир довольно сложный и сервер напрягает по максимуму. Типичные размеры пакета для одного игрока — 500б в его сторону и 8 байт обратно, 15-20 кадров в секунду. Предположительно один сервер должен поддерживать сотни игроков.
Чето для сложного мира маленькие пакеты... Не ошиблись в оценках?
Здравствуйте, Qbit86, Вы писали:
F>>>- где-то ещё должен быть спрятан сервер для мета-гейма. N>>Это что? Q>Рейтинги, лидерборды, ачивоньки, турниры, сезоны, акции.
это больше покупки, прокачка, квесты, шмот, кланы, рейды.
Здравствуйте, gandjustas, Вы писали:
N>>- вообще разделить по разным серверам, один сервер обсчитывает мир, шлёт юзерские данные через сокеты на другой сервер, а тот уже рассылает всё по миру. G>А в чем преимущества 2 и 3 вариантов? Какую проблему они решают?
Я спрашиваю, потому, что недостаточно знаю нюансы обеспечения безопасности такого рода серверов.
Потенциальные преимущества:
— Создание аналога DMZ
— Повышения стабильности: в случае проблем сетевой модуль можно грохнуть и быстро перезапустить, клиенты переподключатся.
— Освободить сервер считающий игру от дополнительных функций: мало ли на сотнях клиентов притормаживать начнёт за счёт работы сетевой подсистемы.
N>>Игровой мир довольно сложный и сервер напрягает по максимуму. Типичные размеры пакета для одного игрока — 500б в его сторону и 8 байт обратно, 15-20 кадров в секунду. Предположительно один сервер должен поддерживать сотни игроков. G>Чето для сложного мира маленькие пакеты... Не ошиблись в оценках?
Не, игра концептуальная, много передавать не надо.
Здравствуйте, Nikе, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
N>>>- вообще разделить по разным серверам, один сервер обсчитывает мир, шлёт юзерские данные через сокеты на другой сервер, а тот уже рассылает всё по миру. G>>А в чем преимущества 2 и 3 вариантов? Какую проблему они решают? N>Я спрашиваю, потому, что недостаточно знаю нюансы обеспечения безопасности такого рода серверов.
Вам еще рано об этом думать.
N>Потенциальные преимущества: N>- Создание аналога DMZ
От какой проблемы это защитит.
N>- Повышения стабильности: в случае проблем сетевой модуль можно грохнуть и быстро перезапустить, клиенты переподключатся.
Для этого сетевой модуль не должен быть отдельным процессом.
N>- Освободить сервер считающий игру от дополнительных функций: мало ли на сотнях клиентов притормаживать начнёт за счёт работы сетевой подсистемы.
Весь ввод-вывод надо делать асинхронным в таких серверах.
Здравствуйте, gandjustas, Вы писали:
N>>Потенциальные преимущества: N>>- Создание аналога DMZ G>От какой проблемы это защитит.
Судя по тому, что никто ничего не сказал — наверное не нужно.
N>>- Освободить сервер считающий игру от дополнительных функций: мало ли на сотнях клиентов притормаживать начнёт за счёт работы сетевой подсистемы. G>Весь ввод-вывод надо делать асинхронным в таких серверах.
Естестственно он асинхронный, но процессорное же время он сколько-то да жрёт?
Здравствуйте, Nikе, Вы писали:
N>>>- Освободить сервер считающий игру от дополнительных функций: мало ли на сотнях клиентов притормаживать начнёт за счёт работы сетевой подсистемы. G>>Весь ввод-вывод надо делать асинхронным в таких серверах. N>Естестственно он асинхронный, но процессорное же время он сколько-то да жрёт?
Незаметно мало, по сравнению с обработкой данных ввода-вывода.
Здравствуйте, gandjustas, Вы писали:
N>>Естестственно он асинхронный, но процессорное же время он сколько-то да жрёт? G>Незаметно мало, по сравнению с обработкой данных ввода-вывода.
Круто
Меня интересовали нюансы, которых я мог не знать. Пока ничего неожиданного, вроде, не всплыло.
F>>>т.е. логи — это плохо, а невозможность подебажить распределённую систему — это норм? K>>логи это необходимость, дебаггер — это приемущество F>это рудимент начального программерского образования. признак низкой культуры разработки.
ахтунг! мачо в треде
ты говоришь какие-то непонятные мне вещи:
K>>зачем тогда несколько серверов городить, если все равно на выходе кто-то сидит, видит весь мир и выполняет откаты
F>чтобы обработать много логики. например, кучерявый AI.
что там за ai, до которого через сеть ходить не жалко? и не пора ли его в таком случае запихнуть в видюху?
F>кроме того, эта точка может отбрасывать отстающие апдейты серваков и заниматься балансировкой.
что такое отстающие апдейты серваков? если это заблудшие udp пакеты от клиента, то там одно число сравнивается (номер последнего принятого). это как бы не работа вообще.
какая балансировка возможна, если каждая нода загружена конткретным куском мира? куда перебалансировать-то? там всё по фиксированному алгоритму должно быть.
F>>>это значит только, что количество апдейтов станет меньше, а требования к реальному времени на нодах — выше. K>>вот это не понял K>>апдейтов у нас столько, сколько нужно клиенту, чтобы картинка была терпимой
F>если появляется точка синхронизации, которая мержит параллельные апдейты, то она будет тормозить результат для клиента. F>т.е. framerate будет ниже.
не знаю, как для клиента можно мержить параллельные апдейты
поток апдейтов для клиента один, что там мержить?
если это входящие — то их не мержат, это входные данные для расчета мира, их в расчет скармливают.
F>>>>>для упрощения ещё можно сделать, чтобы неигровые сущности с разных серваков между собой не взаимодействовали, а только с игроком. K>>>>фига се упрощение K>>>>неужто кто-то такое гоняет по сети? был прецедент? F>>>неписи с разных локаций в играх с плавным переходом между нодами. K>>а почему их, а не игроков? по идее достаточно действия игроков гонять?
F>так игроки с одной ноды видят неписей с другой. и у последних поведение должно нормально выглядеть.
npc увязавшийся за игроком — это же state игрока, и должен смигрировать вместе с игроком при смене ноды? не смигрирует — он даже путь найти не сможет
в общем, это какие-то сложные и непонятные мне игры
Здравствуйте, koenig, Вы писали:
F>>>>т.е. логи — это плохо, а невозможность подебажить распределённую систему — это норм? K>>>логи это необходимость, дебаггер — это приемущество F>>это рудимент начального программерского образования. признак низкой культуры разработки. K>ахтунг! мачо в треде
это тут ни при чём. просто есть задачи, которые нельзя решить дебаггером, а логами можно.
F>>чтобы обработать много логики. например, кучерявый AI. K>что там за ai, до которого через сеть ходить не жалко? и не пора ли его в таком случае запихнуть в видюху?
может, он уже в видюхе
просто если позволить настраивать AI, то его накрутят очень и очень сложным.
F>>кроме того, эта точка может отбрасывать отстающие апдейты серваков и заниматься балансировкой. K>что такое отстающие апдейты серваков? если это заблудшие udp пакеты от клиента, то там одно число сравнивается (номер последнего принятого). это как бы не работа вообще.
сервера ж тебе в разное время ответят. их надо подождать.
K>какая балансировка возможна, если каждая нода загружена конткретным куском мира? куда перебалансировать-то? там всё по фиксированному алгоритму должно быть.
ноды имеют обыкновение умирать.
K>не знаю, как для клиента можно мержить параллельные апдейты
сводишь время, сортируешь, накатываешь обновление, не?
F>>так игроки с одной ноды видят неписей с другой. и у последних поведение должно нормально выглядеть. K>npc увязавшийся за игроком — это же state игрока, и должен смигрировать вместе с игроком при смене ноды? не смигрирует — он даже путь найти не сможет
ну, куски миров таки пересекаются. а неписи всё равно ограничены зоной своего пастбища.
Здравствуйте, neFormal, Вы писали:
F>это тут ни при чём. просто есть задачи, которые нельзя решить дебаггером, а логами можно.
Так, а почему ты думаешь, что распределённую систему нельзя дебажить? А то у меня три вижалки постоянно открыто как раз для этого (но не в данном проекте).
F>>>кроме того, эта точка может отбрасывать отстающие апдейты серваков и заниматься балансировкой. K>>что такое отстающие апдейты серваков? если это заблудшие udp пакеты от клиента, то там одно число сравнивается (номер последнего принятого). это как бы не работа вообще.
F>сервера ж тебе в разное время ответят. их надо подождать.
вооот. а пока ждем, можно подумать — что мы выиграли такой архитектурой.
K>>какая балансировка возможна, если каждая нода загружена конткретным куском мира? куда перебалансировать-то? там всё по фиксированному алгоритму должно быть.
F>ноды имеют обыкновение умирать.
это уже какие-то определенные жанры — чтобы игроки были готовы ждать поднятия новой ноды
K>>не знаю, как для клиента можно мержить параллельные апдейты
F>сводишь время, сортируешь, накатываешь обновление, не?
так это не апдейты, это события с каких-то соседних нод — типа оттуда кто-то пальнул, т.е. это часть обсчета мира — их не мержат а скармливают в обсчет.
клиенту с его текущей ноды полетит, что он труп, его состояние живет на одной ноде
F>>>так игроки с одной ноды видят неписей с другой. и у последних поведение должно нормально выглядеть. K>>npc увязавшийся за игроком — это же state игрока, и должен смигрировать вместе с игроком при смене ноды? не смигрирует — он даже путь найти не сможет
F>ну, куски миров таки пересекаются. а неписи всё равно ограничены зоной своего пастбища.
я так понимаю, eve — это плохой пример всего этого. а кто хороший? хочу нагуглить архитектуру
только логи и трейсы
