Comments 40
Интернет через прокси. Ничего не работает. Какие порты необходимо открыть?
идея сырая, ещё пар идёт:
если пир решил, что ведущий пропал и надо выбрать нового —
он инициирует «перевыборы», оповещая об этом всех участников и рассылая свою «таблицу предпочтений»,
в которой для каждого из участников выставлен вес,
для пропавшего по его мнению ведущего — 0.
коофициенты для остальных можно расставлять рандомно, либо пропорционально пингу.
для самого себя коофициент не выставляется, чтобы не мухлевать.
если пир получил от когото оповещение о выборах,
он тоже рассылает такую таблицу, причом если он считает что никто никуда не пропадал, 0 он никому не выставляет.
в результате, как только ведущий потерян, инициируются перевыборы,
у каждого пира собираются «таблицы предпочтений» от всех остальных участников,
и ведущим назначается тот, кто набрал больше очков.
(например, у кого лучший пинг дло всех участников)
если пир решил, что ведущий пропал и надо выбрать нового —
он инициирует «перевыборы», оповещая об этом всех участников и рассылая свою «таблицу предпочтений»,
в которой для каждого из участников выставлен вес,
для пропавшего по его мнению ведущего — 0.
коофициенты для остальных можно расставлять рандомно, либо пропорционально пингу.
для самого себя коофициент не выставляется, чтобы не мухлевать.
если пир получил от когото оповещение о выборах,
он тоже рассылает такую таблицу, причом если он считает что никто никуда не пропадал, 0 он никому не выставляет.
в результате, как только ведущий потерян, инициируются перевыборы,
у каждого пира собираются «таблицы предпочтений» от всех остальных участников,
и ведущим назначается тот, кто набрал больше очков.
(например, у кого лучший пинг дло всех участников)
Неоднократно заходил и никого там не находил…
Я не так давно закончил флеш игру. п2п риал тайм мультиплеер шутер.
www.youtube.com/watch?v=o30ZFEWSKbM
вот так выглядит.
1. решается без проблем
2. rtmfp reliable! проблемы нет
3. не тестировал порядок приема сообщений, но проблемы здесь абсолютно не вижу
4. все что хакается будут хакать. засекюрите — опять будут хакать. хотя засекюрить впринцыпе несложно
если есть вопросы — в личку
www.youtube.com/watch?v=o30ZFEWSKbM
вот так выглядит.
1. решается без проблем
2. rtmfp reliable! проблемы нет
3. не тестировал порядок приема сообщений, но проблемы здесь абсолютно не вижу
4. все что хакается будут хакать. засекюрите — опять будут хакать. хотя засекюрить впринцыпе несложно
если есть вопросы — в личку
UFO just landed and posted this here
тогда можете посмотреть саму игру.
gibfest.com
Вы лучше расскажите, как работает ваша игра, технологические подробности
а что именно интересует?
Каким образом у вам организована коммуникация между клиентам, используете ли вы мультикастинг или прямые соединения, вызываете функции на клиенте или кидаете управляющие пакеты в поток и т.п.
коммуникация — many 2 many. тоесть каждый клиент связан с каждым. у каждой комнаты есть создатель (owner), в случае если 2 клиента не могут связаться между собой, owner выступает для них как proxy.
мультикастинг не использую. когда делал игру его еще не было.
вызываю функции на клиенте — во флеше по другому вроде и невозможно. «кидаете управляющие пакеты в поток» — насколько я знаю на флеше это невозможно, если ошибаюсь — просветите, буду нереально благодарен.
мультикастинг не использую. когда делал игру его еще не было.
вызываю функции на клиенте — во флеше по другому вроде и невозможно. «кидаете управляющие пакеты в поток» — насколько я знаю на флеше это невозможно, если ошибаюсь — просветите, буду нереально благодарен.
Кидаете управляющие пакеты в поток — я имел ввиду, что есть единая функция, принимающая управляющие объекты.
Насчет много-ко-многим — тоже делал без мульткастинга директ-коннекшенами, для видео не вариант habrahabr.ru/blogs/flex/103427/
Насчет много-ко-многим — тоже делал без мульткастинга директ-коннекшенами, для видео не вариант habrahabr.ru/blogs/flex/103427/
почему для видео «не вариант»?
Очень просто — при директе если у вас 15 клиентов, каждый отправляет по 14 своих видеопотоков и принимает по 14 чужих.
Но если у вас еще есть 200 зрителей (а у меня они есть), то каждый клиент отправляет 214 потоков. А зрители будут только принимать 15 потоков напрямую от каждого клиента.
При мультикастинге такого не будет. Его суть заключается в том, что каждый клиент одновременно принимает и передает и свои, и чужие потоки дальше. Т.о. если в комнате играют 15 человек, каждый клиент будет принимать те же 14 (+ если у него широкий канал, роутить чужие), но отдавать своих 5, 6, 7 — все зависит от настроек. А зрители будут работать на сеть — принимать 15 потоков не напрямую, а друг через друга, отправляя эти потоки так же друг другу. Вух, завернул.
В результате будет иметь бОльшую лэйтенси на принимающей стороне, но меньшую нагрузку на отправляющей.
Примерно так.
Но если у вас еще есть 200 зрителей (а у меня они есть), то каждый клиент отправляет 214 потоков. А зрители будут только принимать 15 потоков напрямую от каждого клиента.
При мультикастинге такого не будет. Его суть заключается в том, что каждый клиент одновременно принимает и передает и свои, и чужие потоки дальше. Т.о. если в комнате играют 15 человек, каждый клиент будет принимать те же 14 (+ если у него широкий канал, роутить чужие), но отдавать своих 5, 6, 7 — все зависит от настроек. А зрители будут работать на сеть — принимать 15 потоков не напрямую, а друг через друга, отправляя эти потоки так же друг другу. Вух, завернул.
В результате будет иметь бОльшую лэйтенси на принимающей стороне, но меньшую нагрузку на отправляющей.
Примерно так.
Очень оптимистично думать, что это будет работать, пускай и с мультикастингом. И откуда такая уверенность, что будет 200 зрителей?
1. Это раьотает
2. 200 — это пример. Каждый дополнительный клиент при прямом соединении (а если еще и TCP) — это дополнительная нагрузка на канал.
2. 200 — это пример. Каждый дополнительный клиент при прямом соединении (а если еще и TCP) — это дополнительная нагрузка на канал.
Блин, мне стыдно, перечитал свои комменты — столько очепяток, пишу как чебурек. Видимо, усталость сказывается :(
ну раз работает, то зашибись.
И я перечитал тред и чето не понял каким образом вы видео прилепили. Ваш вопрос был про игровую логику, мой ответ тоже про игровую логику. Как делать видео — дело десятое.
короч. игры на п2п делаются. все проблемы что есть — решаються. причем даже в быстрых риал-тайм играх, а это на порядки сложнее чем пошаговая карточная игра.
удачи вам с игрой и помните, что rtmfp для месседжей RELIABLE. он ГАРАНТИРУЕТ доставку. (пишу заглавными ибо после первого комента про то что rtmfp reliable снизу дальше пишут какуюто нездоровую муть про «превентивное циклическое повторение»)
И я перечитал тред и чето не понял каким образом вы видео прилепили. Ваш вопрос был про игровую логику, мой ответ тоже про игровую логику. Как делать видео — дело десятое.
короч. игры на п2п делаются. все проблемы что есть — решаються. причем даже в быстрых риал-тайм играх, а это на порядки сложнее чем пошаговая карточная игра.
удачи вам с игрой и помните, что rtmfp для месседжей RELIABLE. он ГАРАНТИРУЕТ доставку. (пишу заглавными ибо после первого комента про то что rtmfp reliable снизу дальше пишут какуюто нездоровую муть про «превентивное циклическое повторение»)
Ну раз короч, то короч. Насчет делаются — сам знаю, сам делаю. Насчет месажди RELIABLE и ГАРАНТИРУЕТ — это верно в случае отправки мессаджа через поток. Если для доставки мессаджей используется не стримы и прямые соединения, а NetGroup (надеюсь, вам знакомо такое), то доставка мессаджей НЕ ГАРАНТИРОВАНА.
Вот вам сцылко
Вот вам цитатко:
Насчет видео — это концептуальная основа сабжа этого поста, появилось с треде после того, как вы рассказали об использовании direct connections в вашей игре. В моей же dc — расточительство и путь в никуда.
Вот вам сцылко
Вот вам цитатко:
Sends a message to all members of a group. To call this method, the GroupSpecifier.postingEnabled property must be true in the groupspec passed to the NetGroup constructor. For more information, see «Post messages to a group» in Flash Media Server Developer’s Guide.
All messages must be unique. A message that is identical to one posted earlier might not be propagated. Use a sequence number to make messages unique.
Message delivery is not ordered. Message delivery is not guaranteed.
Насчет видео — это концептуальная основа сабжа этого поста, появилось с треде после того, как вы рассказали об использовании direct connections в вашей игре. В моей же dc — расточительство и путь в никуда.
Вы поспорить хотите, или нужны ответы?
А зачем меседжи доставлять также как видео?
Видео через мультикаст, а всю игровую логику через прямые конекшены? А?
А зачем меседжи доставлять также как видео?
Видео через мультикаст, а всю игровую логику через прямые конекшены? А?
Блин, ну кто вам сказал, что мессаджи доставляются так же, как и видео?
В моем случае видео транслируется через мультикаст-потоки, мессаджи — через нетгруппы. Прямые соединения разумны только в случае с очень небольшим количеством пользователей.
Насчет поспорить/ответы — в этом треде после habrahabr.ru/blogs/p2p/105876/#comment_3323873 все-таки вы задаете вопросы, а я отвечаю :)
В моем случае видео транслируется через мультикаст-потоки, мессаджи — через нетгруппы. Прямые соединения разумны только в случае с очень небольшим количеством пользователей.
Насчет поспорить/ответы — в этом треде после habrahabr.ru/blogs/p2p/105876/#comment_3323873 все-таки вы задаете вопросы, а я отвечаю :)
Почему не возможно месаджи доставлять через прямые соединения?
Количество соединений будет == количеству игроков.
Количество соединений будет == количеству игроков.
наперед поясняю — не надо всем устанавливать прямые соединения со всеми зрителями, так как те нифига не посылают.
Можно, но не забывайте про зрителей, а зрители в моем случае — очень важная составляющая. Конечно, зрителям можно кидать сообщения через нетгруппы отдельно, но изначально хотелось сделать единого клиента и обработчика логики и для зрителя, и для игрока. Сейчас от этой идеи я уже отошел, как отхожу и от p2p для основной логики — только для оповещений:
> 4. все что хакается будут хакать. засекюрите — опять будут хакать. хотя засекюрить впринцыпе несложно
> 4. все что хакается будут хакать. засекюрите — опять будут хакать. хотя засекюрить впринцыпе несложно
насчет зрителей пояснил выше.
но уточню еще:
каждому зрителю хватит одного конекшена с любым из клиентов.
да. логика у зрителя будет таже что и у клиента. обрабатыватся все будет также.
но уточню еще:
каждому зрителю хватит одного конекшена с любым из клиентов.
да. логика у зрителя будет таже что и у клиента. обрабатыватся все будет также.
Мой конкретный вопрос: что у вас происходит, когда owner (он же прокси для нескольких клиентов) вашей игры отваливается?
«Овнер ушел — подключитесь к другой комнате».
в альфа версии, пока я не сделал механизм прокси, игра спокойно продолжалась дальше.
но дело в том, что если в комнате собереться больше 6-8 игроков, то законектить всех ко всем врядли получиться.
в альфа версии, пока я не сделал механизм прокси, игра спокойно продолжалась дальше.
но дело в том, что если в комнате собереться больше 6-8 игроков, то законектить всех ко всем врядли получиться.
Да, я пробовал сыграть, набралось 8 человек, после старта меня выкинуло. В причины вдаваться не стал — не мои проблемы.
Раньше в игре у меня тоже был owner, ему для старта нужно было нажать GO!, так вот многие даже с этой функцией не справлялись, не говоря уже о том, что owner запросто сваливал :)
В мафию не интересно играть, когда в игре меньше 10 человек. Нижний разумный предел — это 7 человек. Норма — 15, учитывая то, что два-три отвалятся из-за проблем с коннектом или зависшим флешем (видео-тяжелая штука), и еще столько же уйдут в офф, потому что их убили в начале и им теперь не интересно.
Все это ограничивает в выборе способов взаимодействий между игроками.
Раньше в игре у меня тоже был owner, ему для старта нужно было нажать GO!, так вот многие даже с этой функцией не справлялись, не говоря уже о том, что owner запросто сваливал :)
В мафию не интересно играть, когда в игре меньше 10 человек. Нижний разумный предел — это 7 человек. Норма — 15, учитывая то, что два-три отвалятся из-за проблем с коннектом или зависшим флешем (видео-тяжелая штука), и еще столько же уйдут в офф, потому что их убили в начале и им теперь не интересно.
Все это ограничивает в выборе способов взаимодействий между игроками.
Насчет «все-таки вы задаете вопросы, а я отвечаю :)»… ну. нет слов. это вы сейчас пробуете мне помочь… советуете, как сделать мой проект лучше, так как вы имеете какойто опыт в нужной сфере… предлагаете варианты, которых я не вижу… ага
Нужно сделать как в Alien Swarm. В любой момент лидера/ведущего каждый участник может сменить. Они сами определят, что с ведущим какие-то проблемы и назначат нового. Даже если он просто в туалет слишком часто бегает.
Задумка отличная но работает нестабильно, регулярно выкидывает в начале игры. Пока юзабельно только как глючный видеочат. Если допилите до нормального состояния получится офигенный сервис. Успехов!
Я не спец в p2p но мне кажется что схемы с ведущим должны решаться централизованно, то есть ведущим должен быть сервер :) В крайнем случае можно отдать в сервер частично — например следить за живучестью ведущего и переназначать должен сервер.
Без относительно p2p — проблемы с доставкой надо решать. Принципиально есть два способа
1. подтверждение. смотрим в сторону TCP и если по каким-то причинам нельзя использоваться TCP то можно реализовать поверх UDP что-то похожее
2. превентивное циклическое повторение. Посылаем последние n сообщений когда очередь опустела или просто так для профилактики. Создано было для канальных СП, но для пакетных есть немало вариантов.
1+2. Можно комбинировать — например в сообщении есть номер полученного с той стороны сообщения, что является нижней границей для окна повторений
Для многоадресной рассылки конечно придется пофантазировать, так как стандартных способов решить эту проблему вроде как нет, например, mutlicast с гарантией доставки так и не появился — не смогли договориться…
Без относительно p2p — проблемы с доставкой надо решать. Принципиально есть два способа
1. подтверждение. смотрим в сторону TCP и если по каким-то причинам нельзя использоваться TCP то можно реализовать поверх UDP что-то похожее
2. превентивное циклическое повторение. Посылаем последние n сообщений когда очередь опустела или просто так для профилактики. Создано было для канальных СП, но для пакетных есть немало вариантов.
1+2. Можно комбинировать — например в сообщении есть номер полученного с той стороны сообщения, что является нижней границей для окна повторений
Для многоадресной рассылки конечно придется пофантазировать, так как стандартных способов решить эту проблему вроде как нет, например, mutlicast с гарантией доставки так и не появился — не смогли договориться…
В том-то и проблема, что все построено на мульткастинге :) Концепт отличный, а вот в реальных условиях, когда у человека канал 256 килобит, а в комнате 10 человек пытаются ему в этот канал пихнуть каждый по 50 видео и параллельно еще управляющие сообщения, выходит не очень красиво — людей выкидывает по таймауту.
Ведущий — отличный вариант для монетизации сервиса (собирать небольшой взнос участников), впрочем бесплатный ведущий как опция тоже может иметь право на существование. Платный в любом случае надёжнее.
Sign up to leave a comment.
Видео-мафия и технологическая дилема