Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Сообщения за день
 

Вернуться   Форум Flasher.ru > Flash > Общие вопросы о Flash (не затрагивающие ActionScript)

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 18.03.2015, 19:52
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 1  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
По умолчанию Кто-нибудь делал p2p реалтаймовую игру? Или знает пример таковой?

Делаем мобильную игру для платформы ВКонтакте. Игра уже почти готова, но в последний момент решили внедрить корпоративную игру. Так как судя по группе ВКшной платформы, большая часть игроков хотят играть в игры с друзьями.
Чтобы не заморачиваться с сервером, решил сделать игру через p2p. Сама по себе задача не сложная, но вот скорость обмена сообщениями что-то уж очень разочаровывает. Все на столько тормозное, что тут даже разные реалтаймовые хитрости не помогут серьезно улучшить положение. Может быть дело в интернете, конечно. А может в самом механизме работы p2p во флеше. Пока проверить на другом канале не могу.
Собственно вопрос, реальна ли задача? Или флешевый p2p максимум для пошаговых пойдет?
Может кто-нибудь знает примеры игр, которые работают по этой схеме? Поделитесь ссылочкой =)

Старый 25.03.2015, 21:42
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 2  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,283
Делал когда-то чат рулетку через п2п.При передаче видео лагов особых не заметил. Была еще тестовая заготовка для игры.Если найду выложу на хостинг её.
upd:
нашел
открываешь, стартуешь сервер(start server).
открываешь вторую вкладку, конектишься к серверу (join), жмешь в первой вкладке start game,играешься. Управление черными кнопками снизу(думал на мобилках делать игру).При большом кол-ве игроков могут быть глюки.Точно не помню сколько допустимо


Последний раз редактировалось undefined; 25.03.2015 в 21:56.
Старый 26.03.2015, 07:47
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 3  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Спасибо)
На работе довольно неплохо работает. Танки почти синхронно двигаются. Дома тупит. Видимо дело все-таки в интернете было.

Старый 26.03.2015, 17:15
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 4  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,283
You are welcome.
Раз пошла такая пьянка раскажу про одну граблю, над которой сам долго ломал голову - это отслеживание смерти пира.На событие NetGroup.Neighbor.Disconnect полагаться нельзя т.к. оно приходит только соседям отвалившегося пира.Рассылать соседями сообщение об отвале тоже не вариант т.к. соседи могут отвалиться вместе с первым пиром.Единственное более менее надежное решение до которого я допер такое:
1) первый пир в группе назначается админом.
2) Все остальные раз в N секунд шлют ему пинги.
3)Админ следит если кто пропустил отсылку пинга - оповещаем остальных об отвале.
4)Админ при жизни назначает приемника.Если отвалился админ приемник встает на его место соответственно с назначением приемника следующего поколения(хотя можно ограничиться если помер админ - финита ля комедия)
Тут надо помнить еще, что стратус в любом момент может начать перестраивать сеть из-за чего часть пиров может ненадолго оказаться отрезанной от сети.Тогда надо не на первом же пропущенном пинге кричать что пир сдох, а, скажем, на m-ом.
Несколько мудренно, но альтернатива - слать пинги от всех пиров всем.Тогда полное равноправие получается.Но зато растет нагрузка на сеть.При большом кол-ве игроков может таки залагать.

Старый 26.03.2015, 18:18
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 5  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
На событие NetGroup.Neighbor.Disconnect полагаться нельзя т.к. оно приходит только соседям отвалившегося пира.
Вот тут малость не понял. А кому оно еще должно рассылаться? Или имеется в виду, что рассылается только тем, кто подключился после него? Тогда тоже не ясно. У меня все пока работает как часы. Я даже написал некое подобие сервера на p2p, в которой можно слать приватные сообщения любому пиру в группе, либо всей группе сразу, приглашать друзей в свою игру, использовать группы как комнаты в клиент-серверном приложении. В общем, голову тоже поломать пришлось изрядно. p2p в as3 реализовано вообще через задницу
Цитата:
(хотя можно ограничиться если помер админ - финита ля комедия)
Я этим и ограничился) Думаю это разумнее всего

Старый 26.03.2015, 19:01
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 6  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,283
Цитата:
Вот тут малость не понял
Ну никто ведь не обещает, что в сети каждый пир будет соединен прямым соединением с каждым, так?Вот если мне память не изменяет, стратус выстраивает топологию сети так, чтоб у каждого пира было 5-7 соседей(напрямую соединенных).Вот эти 5-7 пиров и называются соседями.Соответсвенно пока у тебя меньше 5-7 запущеных клиентов все ок. т.к. они все являются соседями друг друга, а ты запусти их 10-15 штук и проследи кому приходит NetGroup.Neighbor.Disconnect.Там ведь неслучайно слово Neighbor есть?
Почитай про метод sendToNearest у нет-группы.Это метод адресной доставки сообщения конкретному пиру(причем все надо самому ручками делать от соседа к соседу) в хэлпе должен быть пример.
Цитата:
А кому оно еще должно рассылаться?
Ну я думал, что желательно, чтоб все пиры знали сколько народу в комнате и их peerID.Хотя если у тебя этого не надо, то конечно, все много проще


Последний раз редактировалось undefined; 26.03.2015 в 19:12.
Старый 26.03.2015, 19:22
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 7  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
а ты запусти их 10-15 штук и проследи кому приходит NetGroup.Neighbor.Disconnect.Там ведь неслучайно слово Neighbor есть?
Дело не в этом. Там просто у NetConnection есть свойство maxPeerConnections. По умолчанию 8. Поэтому и не приходит остальное. Просто задай другое число, и будет все приходит. Но я специально ограничил на 3 соседа. Просто игрок коннектится, проверяет если в группе уже есть двое, то отключается
Цитата:
Почитай про метод sendToNearest.Это метод адресной доставки сообщения конкретному пиру
В этом методе невозможно указать адрес соседа. В общем не метод а хрень. Я читал про него. Проблему доставки конкретному игроку я решил сам. Другим способом.

Старый 26.03.2015, 19:53
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 8  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,283
Цитата:
Дело не в этом. Там просто у NetConnection есть свойство maxPeerConnections
Это немного про другое maxPeerConnections - максимальное число пиров в рамках данного конекшена.Оно никак не влияет на топологию сети.5-6 соседей выбирается из соображений скорости доставки сообщений.
Цитата:
В этом методе невозможно указать адрес соседа
public function sendToNearest(message:Object, groupAddress:String):String

Его и не надо указывать.Флэш сам выберет соседа, ближайшего к groupAddress и пошлет ему message.Дальше у этого соседа надо поймать это сообщение и снова вызвать sendToNearest с тем же groupAddress и message и так далее по цепочке в конце концов message достигнет адресата.Вообщем вот готовый свич для обработки сообщения посланного через sendToNearest
Код AS3:
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;
+ функция посылки мессаджа конкретному пирИД:
Код AS3:
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");
			}
		}
где ng - текущая NetGroup
seq - нужен чтоб сообщения отличались друг от друга т.к. одинаковые будут кешироваться.
Хотя если у тебя всего макс. 3 пира в комнате, то париться,конечно, особо не следует.

Добавлено через 10 минут
Вот, кстати, годный манул.Я оттуда копипастил
оттуда:
Цитата:
Neighbor Count != Group Member Count

Старый 26.03.2015, 20:53
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 9  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Чем больше узнаю о р2р во флеше, тем больше убеждаюсь в безрукости его создателей)
Неужели нельзя было реализовать api без всяких там sendMode, а тупо sendToNeighbor(peerID:String), и никаких танцев с бубном. Но нет же, решили нагородить не пойми что.
Цитата:
+ функция посылки мессаджа конкретному пирИД:
Вот собственно это как было не понятно, так и сейчас не понял. Эти peerID представляют из себя длинную хэш строку, которая каждый раз меняется при переподключении. То есть по ней совершенно невозможно определить какой друг скрывается за этим пиром, и видимо единственное место где этот п2п годен - это какие-то анонимные чаты или игры со случайным оппонентом.
Поэтому я решил сделать идентификацию. В краце это выглядит так: Игра получает список айди френдов из соцсети. После этого создается группа со своим айди в качестве 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 из соцсети.

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

Старый 26.03.2015, 21:22
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 10  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,283
Цитата:
Вот собственно это как было не понятно, так и сейчас не понял. Эти peerID представляют из себя длинную хэш строку, которая каждый раз меняется при переподключении. То есть по ней совершенно невозможно определить какой друг скрывается за этим пиром
Верно привязываться к ним не стоит в хелпе жеж сразу говорится, что флэш отвечает только за связь/передачу данных не более все что больше - через свой сервер.
Цитата:
Если в течение 3 секунд никакой сосед не объявился, друг считается офлайн и группа убивается
Флэш сам прибьет группу как только из неё все выйдут.
Цитата:
Неужели нельзя было реализовать api без всяких там sendMode, а тупо sendToNeighbor(peerID:String)
Это не баг, а фича.Дается механизм доставки сообщений от соседа к соседу, а дальше на базе него делай что хочешь.Вдруг я не хочу чтоб мое сообщение шло по кратчайшему пути?)
Цитата:
охоже в итоге все-таки придется вернуться к старому доброму серверу)
Я для себя решил, если нужен мультиплеер и нет сокет-сервера - можно посмотреть в сторону п2п. Иначе придется периодически опрашивать(в ожидании напарника) сервер по http что мне никогда не нравилось. Ну и если число игроков до неприличия высоко тоже только п2п остается.Для трех лучше сразу на сервере делать ИМХО.

Добавлено через 7 минут
Цитата:
Потому что если соседа нет, эта тупая система не посылает никаких событий о подключении к группе себя самого
как не посылает? Ты ведь у нетГруппы ловишь событие коннект(NetGroup.Connect.Success).


Последний раз редактировалось undefined; 26.03.2015 в 21:38.
Создать новую тему Ответ Часовой пояс GMT +4, время: 01:55.
Быстрый переход
  « Предыдущая тема | Следующая тема »  

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 01:55.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.