Многопользовательский UDP сетевая стратегия, совет, необходимый [закрытый]
Я думаю, что это - то, что говорил Eric, но можно загрузить JavaScript из URL непосредственно.
javascript:var%20s=document.createElement('script');s.setAttribute('src','http://YOURJAVASCRIPTFILE.js');document.getElementsByTagName('body')[0].appendChild(s);void(s);
Im, принимающие Вас, хотят, чтобы Ваше расширение загрузило JQuery, таким образом, можно управлять элементами страницы легко? Лаборатории моей компании имеют что-то, что делает это использование JavaScript непосредственно здесь: http://parkerfox.co.uk/labs/pixelperfect
5 ответов
Можно и нужно ли рассматривать P2P (Peer To Peer) для многопользовательской игры? Я не думаю, что технология P2P способна обрабатывать аспекты сетевых игр в реальном времени. Кроме того, в обычных p2p-сетях вы не подключены к тысячам участников одновременно, но обычно вы подключены к некоторым вышестоящим узлам, так что это скорее граф, чем очень плоское дерево.
Я реалистично говорю, что я сможет ли обслуживать 2500 игроков одновременно? Ни на одном сервере. Однако, распределяя пользователей по нескольким серверам, вы уже можете фильтровать их по географическому региону (например, по континенту или стране) в игровом мире, если это очень большой мир. Из-за низкой задержки вы в любом случае захотите разместить серверы рядом с реальным местоположением пользователей - вы не Не играйте на европейских серверах, если вы живете в США, и наоборот.
Можно ли увеличить количество игроков до 10000 за несколько лет? Есть много способов оптимизировать способ кодирования данных и передан. Отправка только дельт состояния игрового мира, прогнозирование движения игрока на стороне клиента, трансляция на сетевом уровне, облачные вычисления на стороне сервера и т. Д., И в ближайшие несколько лет их будет больше, особенно. когда игровая индустрия обращается к платформам облачных вычислений, таким как OnLive, становится очевидным, что нам нужны более эффективные алгоритмы и инфраструктура, чтобы справиться с такими объемами.
Проблема масштабирования - одна из самых сложных проблем для MMO, и она частично решена. Есть много примеров того, как отслеживать и обновлять информацию о пользователях.
Я упомяну один момент: исторически игры - это социальная вещь, и поэтому существует тенденция, согласно которой большинство людей собираются вместе в центральной или единой области. Так что вы действительно должны рассчитывать на этот худший случай.
Некоторые игры действительно создают огромное эпическое ощущение, и возможность группировки и объединения всех пользователей является основным требованием к дизайну. Для этого типа игры планируйте, чтобы все пользователи находились в одном месте. В других играх у вас должна быть возможность разбивать их на более мелкие группы и разделять и властвовать.
Вопрос о масштабировании вполне законен. Однако упор на UDP неуместен. Это не будет для вас главной проблемой.
Причина в том, что взаимодействие игрока с игроком по сути является проблемой O (N * N). С другой стороны, пропускная способность сервера - это проблема O (N). Учитывая, что современные веб-серверы могут поддерживать 1 Гбит Ethernet с HTTP через TCP, меньшие накладные расходы UDP означают, что вы, вероятно, сможете насытить 1 Гбит Ethernet с помощью UDP, пока ваши вычисления работают.
Проблема P2P в конечном итоге заключается в подключении конечных пользователей. Интернет-провайдеры обычно не предоставляют вам много загрузок, во многих случаях <1/10 скорости загрузки. Многие пользователи находятся за NAT, поэтому вам нужно будет настроить прокси-сервер для клиентов, чтобы инициировать соединения. Вам нужно будет обработать отключение пользователей и потерю пакетов (для неизбежного узла, который находится в дрянной беспроводной сети, который отбрасывает половину пакетов). И вам понадобится хороший способ группировать клиентов по интернет-провайдеру / местоположению, чтобы у них не было 200 мс + пингов между собой.
ИМО, это звучит как катастрофа, ожидающая своего часа. Вам, вероятно, лучше обратиться к хорошо известной сетевой библиотеке (и традиционной архитектуре клиент / сервер), чем пытаться изобрести квадратное колесо.
Можно и нужно рассмотреть P2P (Peer To Peer) для многопользовательской игры - нет, это, в лучшем случае, открывает перед вами читерство и всевозможные проблемы с надежностью. Эту банку с червями лучше не открывать. Однако это может помочь вам с распространением контента, если вас это беспокоит.
Я реалистично говорю, что смогу обслуживать 2500 игроков одновременно? - определенно, но акцент делается на от того, как вы это реализуете. В середине 90-х текстовые игры, такие как Realms of Despair или Medievia, одновременно обслуживали сотни игроков онлайн. Они не отправляли данные всем 14 раз в секунду, но они обновляли этих игроков несколько раз в секунду. С тех пор вычислительная мощность увеличилась примерно в 250 раз. Пища для размышлений.
Можно ли через несколько лет масштабировать до 10000 игроков? - это можно сделать сейчас, если вы снизите требования к пропускной способности и не будете всегда отправлять 14 обновлений в секунду, или ослабьте требование, чтобы все обслуживались одним сервером. Проблема « C10K » была решена более 10 лет назад . Очевидно, что FTP-клиент - это не игра в реальном времени, но, с другой стороны, его требования к пропускной способности выше. Если вы можете терпеть небольшую дополнительную задержку в обмен на более высокую пропускную способность, тогда вы в победителях.
был рассмотрен более 10 лет назад . Очевидно, что FTP-клиент - это не игра в реальном времени, но, с другой стороны, его требования к пропускной способности выше. Если вы можете терпеть небольшую дополнительную задержку в обмен на более высокую пропускную способность, тогда вы в выигрыше. был рассмотрен более 10 лет назад . Очевидно, что FTP-клиент - это не игра в реальном времени, но, с другой стороны, его требования к пропускной способности выше. Если вы можете терпеть небольшую дополнительную задержку в обмен на более высокую пропускную способность, тогда вы в победителях.