Отправлено: 21.06.07 20:59. Заголовок: игра по сети

сколько будет жрвть трафика игра по сети в час у меня один мегабайт 1.60

 Отправлено: 21.06.07 22:07. Заголовок: Re:

примерно 10 метров за час при игре вдвоем

 Отправлено: 21.06.07 23:21. Заголовок: Re:

а сжать никак не получиться? мы в генералы играли с 6 метрами в час! А это 3Д игра! У нас же еще уровень немного не тот. Инс, ты падумай над этим...

 Отправлено: 22.06.07 12:40. Заголовок: Re:

Insert Мда...............нехило

 Отправлено: 09.08.07 14:05. Заголовок: Re:

Инс... пора мутить сервак как в зарубежном Soldat. Можно будет турниры проводить) Я бы поиграл

 Отправлено: 11.08.07 11:28. Заголовок: Re:

Сервак точно Нужно... Мутите... Поиграем...

Efendi

 Отправлено: 30.12.07 17:40. Заголовок: ПОМОГИЕ

Народ помогите! Кто может дать адрес сервака для игры в инете?
В часности обращаюсь к создателям!

 Отправлено: 31.12.07 15:53. Заголовок: Dj_smart Сервака в и..

Dj_smart Сервака в инэте нет. Заранее узнаёшь свой ИП, говоришь тем, с кем собираешься играть, они прописывают и заходят.

 Отправлено: 01.01.08 13:32. Заголовок: Волк Давай сыграем.К..

Волк Давай сыграем.Как только зайдешь на этот сайт, кинь мыло на Mezhova_djsmart@mail.ru или на Аську 363958929. Я всегда в Online!
Мой ip адресок: 92.113.79.182. Жду мыло.

 Отправлено: 05.01.08 17:44. Заголовок: Insert пишет: приме..

Insert пишет:

цитата:

примерно 10 метров за час при игре вдвоем

мда... действительно ОЧЕНЬ много...
это Battlefield 2 так же жрёт при 10-15 человек =D

Я даж игра в 3д игры с траффиком 500кб/час ... нужна вам оптимизация)

 Отправлено: 06.01.08 19:04. Заголовок: для общего развития

Тут все удивляются что трафика так много. А удивляться нечему. Я тут посниффил пакеты которые посылают друг другу два клиента и ох... балдел. По моим подсчетам на пару байт полезной инфы приходится пара ТЫСЯЧ байт чисто игрового спама. Это значит без учета TCP, IP и Ethernet заголовков, которые составляют в нашем случае примерно три четверти длины пакетов.
Скрытый текст

Здесь кому интересно идет длинная и нудная расшифровка среднестатистического пакета. Итак, вот он красавец: 0000 00 17 a4 d9 bb a0 00 08 02 dc 4b 13 08 00 45 00 ........ ..K...E. 0010 00 38 f1 4c 40 00 80 06 86 1a c0 a8 01 03 c0 a8 .8.L@... ........ 0020 01 05 04 43 07 99 29 a6 e1 f7 25 fe fb ed 50 18 ...C..). ..%...P. 0030 fb e5 df 17 00 00 0c 00 0c 00 00 00 00 00 00 00 ........ ........ 0040 00 00 00 00 00 00 ......

Длина его - 46 байт в шестнацатиричной системе счисления, что соответствует 70ти в десятичной.
Первые 14 из них - заголовок езернет (если бы я гамал, скажем, по WiFi он бы был даже длиннее, так что 14 байт можно считать абсолютным минимумом).
Далее (от 000E до 0022) идет заголовок IP, который накидывает нам еще 20 байт. Особо любопытные могут вычленить мой внутренний айпишник - c0.a8.01.05:).
Следующие 20 байт - заголовок TCP (0023-0036). Из него в частности видно (невооруженным глазом - конечно не видно, но если почитать умные статьи, например RFC 793, то можно увидеть), что в данном пакете включен флаг PUSH, который означает что данный пакет должен отправляться вне очереди. Зачем был включен данный флаг - тайна, ибо этим флагом помечены абсолютно все пакеты посылаемые во время игры. Флаг таким образом не только теряет весь свой смысл, но и может послужить проблемой при игре через интернет, потому как большое количество пакетов с такими флагами не нравится некоторым свичам.
И наконец заключает наш шит-парад собственно игровые данные (последние 16 байт 0037-0046). Тут уже без всякой дополнительной подготовки видно, что состоит она в основном из нулей. Стоит также добавить, что буквально за десять секунд игры я успел почить пару сотен пакетов. И хотя я понимаю откуда берется такое число (fps*t) от этого не легче, тем более что 90% из них с точностью до номера идентичны представленному, т.е. не несут никакой смысловой нагрузки.

"Не рассказывай мне о проблемах, скажи как ее решить"
Что тут ответить. Я честно попытался написать свою собственную програму на языке Java с рабочим названием ZodConnector, и выяснил невеселую истину что програмист из меня как из колбасы телескоп. У меня есть идеи как убыстрить сетевой движок, и я их могу рассказать, если это кому-нибудь интересно. Могу даже дать этот недокостыль ZodConnector, который предполагался как посредник между зод-клиентами, но не заработал даже в тестовом режиме (я утонул в ошибках сокетов). Могу попытаться разработать спецификацию протокола для танков (все таки, можно сказать специалист по сетевым технологиям). Но вот самостоятельно написать скорее всего у меня ничего не получится.

 Отправлено: 06.01.08 20:47. Заголовок: Insert , послушайся ..

Insert , послушайся Morse ! Он дело говорит.

 Отправлено: 07.01.08 23:17. Заголовок: Morse Ну ты моск :) ..

Morse Ну ты моск :) Я подозревал конечно что там много служебного спама, но что бы так... Моих данных там действительно 16 байт. Сейчас немного поправил код и без особых усилий уложился в 12. Правда думаю что разницу 66-70 никто не заметит :) Мне не совсем понятно, что должна делать твоя прога? Расскажи, какие у тебя есть идеи?

Кстати, если кому интересно, я со следующим релизом планирую выложить исходные коды

 Отправлено: 08.01.08 02:03. Заголовок: Цель первая и самая ..

Цель первая и самая главная: перевести игру на UDP рельсы.
Если кто не знает UDP - протокол в некотором смысле аналогичный TCP, с той только разницей что TCP более надежный - со встроенной защитой от потери пакетов, а UDP более быстрый - благодаря отсутствию этой защиты. Человек же знающей немедленно возразит "но ведь тогда пакеты будут теряться - произойдет рассинхронизация". Конечно будут, а кому сейчас легко? Таким образом моя прога должна была заниматься тем, что перехватывать соединения игры, и подменять ее пакеты своими собственными. Это конечно понизило бы надежность, но ускорило бы игру раза в полтора - только за счет UDP.
Следующий этап - асинхронная передача. При нынешних обстоятельствах задержка любого пакета приводит к тормозам - игра притормаживает до получения необходимых данных. Задача проги на этом этапе - в случае если требуемый пакет вовремя не получен - подсовывать игре предыдущий. Таким образом при тормозах у какого-нибудь отдельного игрока (тормоза со стороны сервера рассматривать не будем - это смерть при любом раскладе) страдает только этот отдельный игрок, а у остальных все в порядке. Это честно: почему из-за тормозного чела остальные семеро должны пережидать его лаги.
И наконец самый последний этап - полностью собственное протоколирование. Прога превращается в (сильно) урезанную версию зод-сервера. Получая информацию от игры или других прог она обновляет информацию внутри своей игровой базы, а пакеты генерит сама - исходя из информации внутри этой базы. Эта схема позволила бы по всякому менять формат передаваемых через инет данных не меняя собственно игры.
Это то что касается несостоявшейся проги.

Что касается идей.
Идея с протоколом по-любому в силе, но если подходить к проблеме обстоятельно, то нужно заметить что для получения играбельной программы одного только перехода на новый протокол будет мало. Предется поменять всю парадигму сетевого общения, а именно, понять, что при игре через интеренет абсолютная синхронизация невозможна впринципе. Пакеты имеют обыкновение теряться, приходить с опозданием, биться и тд. И, соответственно, не надо даже пытаться этой абсолютной синхронизации достичь, к ней можно только стремиться. Соответственно рассинхронизация должна привратиться из ошибки (error) в исключение (exception) - програмисты меня поймут.
Итак, в процессе игры мы будем регулярно, хотя и нечасто, сталкиваться с ситуацией в которой мнения сервера и клиента по какому-нибудь вопросу расходятся. Скажем сервер считает что танк там, а клиент уверен что сям. Тут надо точно определить чьи данные мы признаем более правильными. Для начала вообще прикинем какие данные требуют синхронизации.
1. положение танков - безусловно. важнейшие данные.
2. положение снарядов - тоже важные данные, но не сильно - подробности ниже
3. здоровье и состояние танков (втч какая пушка бустер и тд)
4. положение и состояние объектов - всего что лежит кроме стацек
5. положение и состояние стацек (включая здоровье)
6. положения и состоание триггеров а также значения переменных пользователя - если уж мы решили что сделаем возможность прохождения кампаний в многопользовательском режиме надо добавить это и в протокол
расположено в порядке уменьшения критичности
Я предлагаю следующее деление: клиент имеет приоритет только касательно координат и состояния своего танка, и координат снарядов, выпущенных им. Все остальное - в ведении сервера. Если ты стрелял по танку туда, а он оказался не там - вини свой канал, оппонент не виноват. Если ты ехал себе и ехал, и вдруг оказался трупом (снаряды не подгрузились) - ситуация та же. Координаты и состояние собственного танка и координаты выпущенных им снарядов - единственные вещи которые клиент гарантированно знает лучше чем сервер. Поэтому в случае рассинхронизации приоритетными должны считаться именно они. Все попадания (изменения хп) должны расчитываться на сервере - он, так сказать, лицо непредвзятое.
Это все было сильно растянутое первое. Теперь еще более растянутое второе.
Посылать все эти данные 30 или сколько там раз в секунду - глупо и расточительно. Большинство этих данных совершенно некритичны по времени. Предлагаю разделить пакеты на две группы: uptime-пакеты (далее - обычные пакеты) и синхронизационные пакеты (далее - синхропакеты). Обычные пакеты будут посылаться по мере надобности - т.е. с изменением данных: данные изменились - пакет ушел. Синхропакеты будут посылаться раз, скажем, в секунду, и будут содержать все данные нуждающиеся в синхронизации. Его назначение будет - страховка. Чтобы он легко и быстро проходил через интернет его размер должен быть меньше 1492 байт (если кому-нибудь что-нибудь говорит аббривеатура MTU - то вот это оно и есть). С одной стороны это ах как много, а с другой на карту можно столько барахла накидать лишнего, что никаких скоростей не хватит. Как уже упоминалось самые критичные данные - положение танка. Я считаю что самым удачным вариантом будет передача изменения состояния управляющих клавиш. Клавиш этих всего шесть, если кто не помнит. Игрок нажимает клавишу, после чего отправляется пакет: "на такой-то секунде игры была нажата следующая клавиша". По таким данным можно однозначно восстановить текущее положение танка. Такой подход хорош сразу с двух точек зрения: во-первых я еще не встречал игроков которые бы 30 или сколько там раз в секунду нажимали-отпускали клавиши (эпилептики не в счет), а во вторых в случае небольшого сетевого тормоза танк не встанет как вкопанный, а продолжит движение по прежней траектории. В большенстве случаев это даст гораздо меньшую рассинхронизацию. С выстрелами ситуация будет сложнее - помимо нажатия клавиши на траекторию снаряда влияет также товарищ рандом. Имеет смысл в момент выстрела посылать сразу координаты (и тип) соответствующего снаряда. Проблеммы будут с пулеметом, автопушкой и прочими подобными. Тут надо что-нибудь придумать, чтоб не плодить зря миллион пакетов. Почему я ранее сказал что координаты снарядов - не особо важные данные: "уклонение - целая наука" завопят ветераны. Давайте прикинем, от каких снарядов реально увернуться. Ракеты, бфг, и вобщем-то все. То есть тех, время полета которых довольно велико. Координаты же их расчитываются с абсолютной точностью по любым данным (т.к. они все - неуправляемые). То есть даже если мы получили координаты снаряда с сильным опазданием, мы все равно сможем восстановить не только его нынешние, но и все последующие. Уклонение от всех остальных - дело случая, и я не вижу причин почему бы рандом клиента был привыше рандома сервера.
Вобщем, идей я наизлагал много, а есть их у меня еще больше. Но больше всего - проблем мною пока не решенных. Например непонятно что делать с геодатой. Триггер ее может запросто поменять, и надо понять как синхронизировать подобные события. Также непонятно как производить банальное лечение. ХП танка находится в ведении сервера, но триггер или пряник могут это изменить, и эти данные будут приоритетными - как быть? (пример прост: в результате рассинхронизации клиент считает что танк въехал в область триггера, а сервер - нет. координаты клиента - приоритетные, поэтому факт вьезда истен. как это доказать серверу? то же про пряник) И тд и тд - впору отдельный топик заводить.
Даже если это все уже кажется продуманным, на самом деле это все - сырые идеи. Если общественное мнение склонится к тому, что сетевой движок грейдить надо - не на уровне "гип-гип да-да надо-надо", а реально найдутся готовые на это исполнители, то я буду эти идеи развивать (при посильном участии форумчан ессно). Единственное условие - после сессии))

ух я расписался... прям целое сочинение. что-то интернет на меня плохо действует - я становлюсь графоманом

 Отправлено: 08.01.08 13:35. Заголовок: Morse Я эксперименти..

Morse Я экспериментировал с UDP, и там действительно скорость немного выше. поскольку сетевой двиг зоны устроен так, что все передаваемые данные важны, то для обеспечения надежной доставки пакетов приходилось над UDP громоздить собственный протокол, который в результате сводил на нет все преимущества. И я пришел к следующему выводу. Для игры по интернету UDP не катит, а по локалке и так все быстро. В любом случае, это какие-то проценты производительности.

Сейчас каждый клиент передает на сервер состояние кнопок контроллера. Затем сервер раздает эти данные всем остальным. Таким образом игровая ситуация расчитывается каждым клиентом независимо. Все рандомные генераторы, скрипты с переменными, триггеры - все это работает синхронно. Если случится так, что клиенты что-то рассчитают по разному, синхронизация нарушится, что и можно наблюдать почти в каждой версии :) Совсем недавно, не без участия КРАШЕРА, я выловил очередной баг на эту тему: синхра сбивалась, когда у одного клиенты был выбран Direct3D, а у другого - OpenGL. Как выяснилось, Direct3D использует пониженную точность вычислений с плавающей точкой. В результате банальное умножение на разных машинах давало разный результат.

 Отправлено: 09.01.08 03:50. Заголовок: Мда, при таком устро..

Мда, при таком устройстве сетевого движка от какой-либо внешней проги толку действительно будет мало. Тут уж либо ничего не делать, либо менять все от и до...
Ну и ладно. В конце концов по локалке работает и то хлеб.

 Отправлено: 09.01.08 14:14. Заголовок: Мдаааааа. :sm13: Ins..

Мдаааааа. Insert А что такое UDP? Как оно разшифровывается?

 Отправлено: 09.01.08 15:58. Заголовок: можешь почитать rfc ..

можешь почитать rfc 768, например здесь. Там про него написано абсолютно все. А вообще практически любой вопрос в наше время можно задать гуглу и получишь хороший и развернутый ответ.

 Отправлено: 20.03.08 23:38. Заголовок: Чо на счёт сервера то?

Он есть или нет его???сервер то

 Отправлено: 16.04.08 23:03. Заголовок: TCP достаточно, можн..

TCP достаточно, можно кстати немного увеличить скорость, отключив QoS.
Нужно максимально оптимизировать вид передаваемых данных - т.е. свести их объем к минимуму. Вот к примеру синхронизация... как я понимаю, нужно для появления например танка такого-то на точке возрождения такой-то. Для этого как я понимаю, таймер нужно постоянно у всех синхронизировать. А нельзя ли, чтобы по таймеру на сервере просто рассылалось всем сообщение - на возрождалке с (!)ID такой-то появился танк с ID таким-то. Все таймерные события перевести на такой движок - и не нужно будет постоянно синхронизировать таймеры. Каждому нужно быдет только рассылать нажатия кнопок каждого. Есть в чем-то ошибка?

 Отправлено: 04.05.08 10:27. Заголовок: Таймеры никто не си..

[vs] Таймеры никто не синхронизирует. Если к примеру танк сдох, то все и так знают через сколько секунд и где он родится. Все что нужно знать клиентам - это действия других игроков, а все события типа взрывов и рождений - всего лишь следствия этих действий. Следовательно, события вообще не надо передавать.