![]() |
|
||||||||||
|
|||||||
|
|
« Предыдущая тема | Следующая тема » |
| Опции темы | Опции просмотра |
|
![]() |
![]() |
|
|
|
|||||
|
Делаем мобильную игру для платформы ВКонтакте. Игра уже почти готова, но в последний момент решили внедрить корпоративную игру. Так как судя по группе ВКшной платформы, большая часть игроков хотят играть в игры с друзьями.
Чтобы не заморачиваться с сервером, решил сделать игру через p2p. Сама по себе задача не сложная, но вот скорость обмена сообщениями что-то уж очень разочаровывает. Все на столько тормозное, что тут даже разные реалтаймовые хитрости не помогут серьезно улучшить положение. Может быть дело в интернете, конечно. А может в самом механизме работы p2p во флеше. Пока проверить на другом канале не могу. Собственно вопрос, реальна ли задача? Или флешевый p2p максимум для пошаговых пойдет? Может кто-нибудь знает примеры игр, которые работают по этой схеме? Поделитесь ссылочкой =) |
|
|||||
|
Регистрация: Oct 2006
Сообщений: 2,283
|
Делал когда-то чат рулетку через п2п.При передаче видео лагов особых не заметил. Была еще тестовая заготовка для игры.Если найду выложу на хостинг её.
upd: нашел открываешь, стартуешь сервер(start server). открываешь вторую вкладку, конектишься к серверу (join), жмешь в первой вкладке start game,играешься. Управление черными кнопками снизу(думал на мобилках делать игру).При большом кол-ве игроков могут быть глюки.Точно не помню сколько допустимо Последний раз редактировалось undefined; 25.03.2015 в 21:56. |
|
|||||
|
Регистрация: Oct 2006
Сообщений: 2,283
|
You are welcome.
Раз пошла такая пьянка раскажу про одну граблю, над которой сам долго ломал голову - это отслеживание смерти пира.На событие NetGroup.Neighbor.Disconnect полагаться нельзя т.к. оно приходит только соседям отвалившегося пира.Рассылать соседями сообщение об отвале тоже не вариант т.к. соседи могут отвалиться вместе с первым пиром.Единственное более менее надежное решение до которого я допер такое: 1) первый пир в группе назначается админом. 2) Все остальные раз в N секунд шлют ему пинги. 3)Админ следит если кто пропустил отсылку пинга - оповещаем остальных об отвале. 4)Админ при жизни назначает приемника.Если отвалился админ приемник встает на его место соответственно с назначением приемника следующего поколения(хотя можно ограничиться если помер админ - финита ля комедия) Тут надо помнить еще, что стратус в любом момент может начать перестраивать сеть из-за чего часть пиров может ненадолго оказаться отрезанной от сети.Тогда надо не на первом же пропущенном пинге кричать что пир сдох, а, скажем, на m-ом. Несколько мудренно, но альтернатива - слать пинги от всех пиров всем.Тогда полное равноправие получается.Но зато растет нагрузка на сеть.При большом кол-ве игроков может таки залагать. |
|
|||||
|
Цитата:
Цитата:
|
|
|||||
|
Регистрация: Oct 2006
Сообщений: 2,283
|
Цитата:
Почитай про метод sendToNearest у нет-группы.Это метод адресной доставки сообщения конкретному пиру(причем все надо самому ручками делать от соседа к соседу) в хэлпе должен быть пример. Цитата:
Последний раз редактировалось undefined; 26.03.2015 в 19:12. |
|
|||||
|
Цитата:
Цитата:
|
|
|||||
|
Регистрация: Oct 2006
Сообщений: 2,283
|
Цитата:
Цитата:
Его и не надо указывать.Флэш сам выберет соседа, ближайшего к groupAddress и пошлет ему message.Дальше у этого соседа надо поймать это сообщение и снова вызвать sendToNearest с тем же groupAddress и message и так далее по цепочке в конце концов message достигнет адресата.Вообщем вот готовый свич для обработки сообщения посланного через sendToNearest case "NetGroup.SendTo.Notify": // e.info.message, e.info.from, e.info.fromLocal if(e.info.fromLocal == true){ log(e.info.code); // We have reached final destination hSendTo(e.info.message.data); }else{ // Forwarding ng.sendToNearest(e.info.message,e.info.message.dest); } break; public function sendTo(peer_id:String,data:Object):void { var message:Object = {}; message.data = data; message.dest=ng.convertPeerIDToGroupAddress(peer_id); message.seq = seq; seq++; if (seq>999) seq=0; if(joined){ ng.sendToNearest(message,message.dest); } else { log("not joined"); } } seq - нужен чтоб сообщения отличались друг от друга т.к. одинаковые будут кешироваться. Хотя если у тебя всего макс. 3 пира в комнате, то париться,конечно, особо не следует. Добавлено через 10 минут Вот, кстати, годный манул.Я оттуда копипастил оттуда: Цитата:
|
|
|||||
|
Чем больше узнаю о р2р во флеше, тем больше убеждаюсь в безрукости его создателей)
Неужели нельзя было реализовать api без всяких там sendMode, а тупо sendToNeighbor(peerID:String), и никаких танцев с бубном. Но нет же, решили нагородить не пойми что. Цитата:
Поэтому я решил сделать идентификацию. В краце это выглядит так: Игра получает список айди френдов из соцсети. После этого создается группа со своим айди в качестве groupSpec. И когда игрок хочет пригласить друга, он клацает по иконке друга, тут же создается группа со спецификатором как у друга и задается таймаут 3 секунды на ожидание коннекта соседа. Потому что если соседа нет, эта тупая система не посылает никаких событий о подключении к группе себя самого. Если в течение 3 секунд никакой сосед не объявился, друг считается офлайн и группа убивается. Как бы по честному получается, что игрок может создать и держать группу только со своим айди. Каждая группа заключена в обертку Client, у которой есть свойство isMine:Boolean и userID:String (равно айди френда из соцсети). При создании своей группы, оно true, во всех остальных случаях false. Так что при коннекте соседа, ему посылается запрос пира, и он при получении группового сообщения проверяет какой userID в сообщении (userID это адресат). Если он совпадает с его userID и его свойство isMine == true, то в ответ он посылает свой nearID просящему. Таким образом происходит временная привязка userID к peerID, и я уже знаю какой peerID у конкретного друга. Ну а дальше дело техники. Сделал еще одну обертку Connector, который рассылает события типа ClientEvent.PRIVATE_MESSAGE или ClientEvent.INCOMING_INVITATION, и может отправлять сообщения не по каким-то там neighbor'ам, а юзерам с конкретным userID из соцсети. Вроде работает как надо пока. На тестах. Но уже куча сомнений закралась в работоспособности этой системы в принципе. Похоже в итоге все-таки придется вернуться к старому доброму серверу) |
|
||||||
|
Регистрация: Oct 2006
Сообщений: 2,283
|
Цитата:
Цитата:
Цитата:
Цитата:
Добавлено через 7 минут Цитата:
Последний раз редактировалось undefined; 26.03.2015 в 21:38. |
![]() |
![]() |
Часовой пояс GMT +4, время: 01:55. |
|
|
« Предыдущая тема | Следующая тема » |
|
|