Сетевые игры сеть для игры.

← →
Galiaf © (2006-06-07 05:26) [0]

Привет. Кто делал сетевые игры, нужно узнать, что лучше использовать для динамических игр. Какой компонент лучше использовать? Сеть в игре ещё не делал но уже некоторую часть продумал, осталось только узнать с каким компонентом работать. ServerSocket & ClientSocket знаю немного(не думаю что это лучший вариант), возможно tspclient\server или winsock без компонентов. UDP отпадает, насколько я знаю дейтаграммы не надёжны хотя и легче. Других компонентов нет но может быть у вас есть идеи.

← →
XProger © (2006-06-07 05:32) [1]

Для динамичной игры TCP отпадает

← →
tButton © (2006-06-07 05:55) [2]

> Для динамичной игры TCP отпадает

однозначно, хотя конечно от динамики зависит, точнее - от объёма передаваемых за раз данных.

> UDP отпадает

возникает вопрос а что же остаётся?

в принципе DirectPlay остаётся, но это уже не на уровне компоненты

← →
megabyte-ceercop © (2006-06-07 08:12) [3]

Я когда сетку на своем движке реализовывал, пробовал на UDP и на TCP передавать одни и теже данные, вариант с TCP оказался быстрее работает раза в два. Поэтому от UDP я отказался, хотя принцип дейтаграмм был для меня предпочтительнее чем поток.
Так я и не стал разбираться почему UDP медленнее :)
(использовал Indy компоненты в обоих случаях)

← →
XProger © (2006-06-07 12:50) [4]

tButton,
1) TCP бьёт не по размерам, а по скорости передачи потеряных пакетов
- Гарантирует доставку
- Гарантирует порядок
Теперь ситуация: послали пакет, он потерялся, вся очередь стоит и ждёт успешной отправки пакета. В итоге получаем время по меньшей мере = Ping.
Размер заголовка TCP пакета = 32 байта ;)
На UDP можно без особых проблем реализовать гарантированную доставку (если надо)
2) DPlay реализован на тех же сокетах

megabyte-ceercop, зря не разобрался, у меня совершенно наоборот выходило :)

← →
tButton © (2006-06-08 05:26) [5]

> Теперь ситуация: послали пакет, он потерялся, вся очередь
> стоит и ждёт успешной отправки пакета. В итоге получаем
> время по меньшей мере = Ping.

уж лучше чем забить на потеряный пакет =)

← →
megabyte-ceercop © (2006-06-08 07:41) [6]

А у меня так протокол задуман, что в случае если даже пакеты будут через один теряться, клиент сам расчитает движения объектов как надо и при первой же возможности синхронизируется с сервером.
Надо сейчас посидеть с UDP, поразбираться.

А возможно ли что ТСР работает быстрее, потому, что тесты я делал на одном компе и пакеты за пределы компа не уходили?

← →
tButton © (2006-06-08 07:59) [7]

> А возможно ли что ТСР работает быстрее, потому, что тесты
> я делал на одном компе и пакеты за пределы компа не уходили?

ессесно =)

← →
megabyte-ceercop © (2006-06-08 12:18) [8]

> ессесно

.
Всмысле TCP_локально_на_компе быстрее чем UDP_локально_на компе.

← →
megabyte-ceercop © (2006-06-08 12:20) [9]

...на том же самом компе.

По идее УДП должен быть быстрее.

← →
RzCoDer © (2006-06-08 13:59) [10]

> megabyte-ceercop

А зачем тебе скорость передачи данных через сетевые компоненты на одном компе?

← →
XProger © (2006-06-08 15:48) [11]

RzCoDer, может он таким образом взаимодействие между двумя программами делает ;)

tButton. ты основного фокуса не понял. Гарантированная доставка реализуется и на UDP без проблем, но "благодаря" гарантированному порядку в TCP - очередь стоит пока тот пакет не долетит успешно :)

← →
tButton © (2006-06-09 04:56) [12]

> в TCP - очередь стоит пока тот пакет не долетит успешно
> :)

а в УДП очередь что делает?
я так понимаю, что если пользователей несколько то пакет должен прийти всем и сразу...
и вот тут я realize, что понимаю всё меньше и меньше... =))))

← →
XProger © (2006-06-09 05:25) [13]

UDP оранизован так, что сливает пакеты сразу. Нужно очень постараться, чтобы забить очередь пакетов ;)

← →
tButton © (2006-06-09 05:51) [14]

ну ладно =)
но я пока ничего столь динамичного, чтобы не хватало TCP ещё не делал =)

← →
Galiaf © (2006-06-09 11:49) [15]

Да и у меня кстати не супер-пупер шутер, бомбермен, только трёхмерный, и нет никаких примеров программ на UDP, чтобы изучить. Я ещё неточно вижу работу с сетью но думаю по ходу изучения компонентов пойму что к чему. Вот ещё уточнить: Чем отличается Indy от компонентов с закладки Internet и собственно что не стоит использовать?

← →
Galiaf © (2006-06-09 21:41) [16]

Я так подумал, может я не правильно представляю себе сеть. Я собирался передавать с клиента на сервер состояния клавишь, а передвижения обрабатывать на сервере, после отсылать на клиент положение игроков и информацию, например, о взрыве или уничтожении объекта. Как делать будет правильней?

← →
Galiaf © (2006-06-10 00:44) [17]

И ещё, как часто отсылать пакеты? И делать это в таймере или в других событиях (в каденсере например :))?

← →
Galiaf © (2006-06-12 00:01) [18]

Вот непонятно ещё: в indy есть UDP и сервер и клиент, это ж как понимать? Я думал, что он без таких иерархий работает, а просто отсылает куда ему скажут, на закладке internet только один компонент UDP.

← →
XProger © (2006-06-12 05:37) [19]

Galiaf, понимать очень просто - компоненты не удобны для работы с сетевым кодом игры.

← →
Galiaf © (2006-06-14 03:17) [20]

У тебя случайно примерчика работы с UDP не найдётся? По яндексу почти нет (то что я нашёл - это не точные рабочие примеры, а предположения...)

← →
megabyte-ceercop © (2006-06-14 07:02) [21]

> RzCoDer © (08.06.06 13:59) [10]
>
> > megabyte-ceercop
>
> А зачем тебе скорость передачи данных через сетевые компоненты
> на одном компе?
> <Цитата>
>
>
> XProger © (08.06.06 15:48) [11]
> RzCoDer, может он таким образом взаимодействие между двумя
> программами делает ;)

Повторю балин:

> тесты я делал на одном компе

Тестирую сетевую игру (запускаю сервер и клиент) на одном компе, и только после уладки крупной партии багов - на двух удаленных.

← →
XProger © (2006-06-16 00:04) [22]

Galiaf http://www.yandex.ru/yandsearch?text=%C1%E8%E1%EB%E8%EE%F2%E5%EA%E0+%E3%EE%F2%EE%E2%EE%E3%EE+%F1%E5%F2%E5%E2%EE%E3%EE+%EF%F0%EE%F2%EE%EA%EE%EB%E0&stype=www

megabyte-ceercop
Всё ты верно делаешь, но тестирование скорости отправки (заведомо не теряющихся) пакетов на локальной машине - даст результаты для игры на локальной машине ;) А мы вроде про сетевую игру говорим...

← →
megabyte-ceercop © (2006-06-16 07:15) [23]

Локально я игровой протокол просто отлаживал. Отписываюсь от темы. : )

← →
Galiaf © (2006-06-18 10:06) [24]

> XProger © (16.06.06 00:04) [22]

Благодарю. Вот только зачем было ссылку через яндекс давать, тем более с явным запросом на свою страницу :), я бы в яндексе подобное не писал.
Ещё одна проблема с теорией я думаю: в игре будут разные пакеты, как узнавать с чаем именно пакет пришёл? Я раньше только текст посылал и вставлял в начало символы для определения типа пакета но это уже другое, можно я думаю смотреть по размеру пакета.
И вот ещё вопрос по неопытности: например я хочу послать vector
NET_Write(vector, sizeof(vector)); NET_Send(nil, 21666, false);
я думаюю так но вот как такое принять там ведь array [0..255] of Char на сколько я помню приходит. Или мне перед посылкой переводить в такой вид а после принятия обратно переводить? Но это уже не правильно будет я думаю. Одним словом - ЗАПУТАЛСЯ.

← →
XProger © (2006-06-18 15:20) [25]

Galiaf,
ID := PLAYER_POS; // пакет будет содержать позицию игрока NET_Write(ID, SizeOf(ID)); // пишем идентификатор пакета NET_Write(Player.Pos, SizeOf(Player.Pos)); // пишем позицию игрока типа TVector NET_Send(nil, 21666, false); // послали широковещательный пакет (на всю локалку) ... buf : array [0..1024] of Byte; while NET_Recv(@buf, 255, IP, Port, recv) > 0 do begin Move(buf, ID, SizeOf(ID); // получаем тип данных в пакете case ID of PLAYER_POS : Move(buf[SizeOf(ID)], Player.Pos, SizeOf(Player.Pos)); .. end; end;
Работаем с памятью :)

← →
@!!ex (2006-06-19 02:02) [26]

UDP - это протокол не гарантированной доставки.
Broadcast"ы(еслия правильно помню) - бросают сообщения по всей локалке.
Вообще UDP для передачи данных никто не использует.
Обычно с помощью него идет поиск серваков локалке.
А дальше TCP/IP - гарантированная доставка. Отличный протокол. Самый распространенный. Сеть не засоряет бесхозными сообщениям, через маршрутизаторы спокойной проходит, поэтому по инету можно играть. И в локалке рулит. Вот как ты в UDP узнаешь, что комп друга от сети отвалился? А никак. только таймаут ловить. Потому что соединения нету постоянного. А TCP/IP соединение постоянно держит. И если вдруг че случилось, сразу знаешь, а что собственно произошло.
Это из распространенных, универсальных протоколов - самый быстрый.
Просто компоненты - отстой полный. Тормозные, глючные.... Бррр.
WinSock API рулит.
Там кода то получаеться строк 50....

← →
XProger © (2006-06-19 12:50) [27]

@!!ex,
1) Асинхронная гарантированная доставка на UDP реализуется за 100 строк кода. Причём, очередь в случае "не доставки" не стоит на месте.
2) Quake 2-4, Блитцкриг, StarCraft, HL 1-2 и т.п... а ты за своё "никто не использует"...
3) UDP быстрее чем TCP (аксиома)
4) Заголовок UDP пакета на порядок меньше
5) TCP работает на таймаутах, так что не верти носом и без проблем реализуй его на UDP
6) Не вижу проблем (и не я один, см. п. 2) с работой UDP в интернете. И маршрутизаторы тут причём?
6) 50 строк кода на WinSock API - это не сетевой протокол игры, это бред...

← →
@!!ex (2006-06-19 15:02) [28]

1) Если я правильно помню, очередь в TCP не зависит от доставки. Хотя не уверен.
2) Честно открыл сорсы кваки 2. Клиентсукю часть. UDPшный поиск серваков. Ткните мне, в каком хедере используеться UDP для передчачи данных во время игры?????
3 кваки сорсы на работе, не могу ща посмотреть.
Блитцкрига нету. Жаль.
StarCraft честно предложил для игры по инету TCP/IP, для локалки - IPX,
через модем, через последовательный порт.
HL 1 - TCP/IP.
HL 2 - у меня сейчас нету. Но Steam - точно через TCP/IP.
3) Быстрее?
UDP - пакеты идут один за другим.
TCP - пакеты идут один за другим, в ответ идут подтверждения доставки.
Скорость отличаеться чуть-чуть.
4)Обычно размер TCP заголовка составляет 20 байт, если не присутствуют опции.
Минимальное значение для заголовка UDP составляет 8 байт.
Смешное отличие меньше чем в 3 раза. Далеко до порядка.
А учитывая размеры пакетов, вообще сущая ерунда.
5) Зачем реализовывать это на UDP, если это уже реализовано на уровне драйверов TCP.
6) Согласен. Идиот. Ступил.
7) Это не сетевой протокол. Хотя бы потому что сетевой портокол реализован на уровне драйверов. А 50 строк - это минимальный интерфейс для TCP.

← →
@!!ex (2006-06-19 15:05) [29]

P.S.
Кстати, еще придеться реализовывать сборку пакетов в ручную, проверку контрольной суммы, писать реализацию повтороного отсылания пакета, если не прешло уведомление и т.д.
Все это в TCP уже реализовано.
Собственно TCP от UDP только этими вещами и отличаеться.
Гемороя море. А плюсы какие?

@!!ex,
1) TCP гарантирует порядок доставки и саму доставку. Допустим, посылаем 10 пакетов (блоков данных). Вдруг, первый же блок затерялся и нам приходится повторно выслать его (минимальное время до подтверждения = пингу). В это время вся сборка блоков стоит и ждёт когда этот пакетик прийдёт, чтобы сформировать поток...
2) Размер TCP заголовка = 32 байтам. В шутерах типа Quake 2-3 был выбор протокола. В HL 1-2 он также присутствует.
3) В игре по интурнету могут возникнуть такие ситуации, когда связь полностью обрывается и идёт реконнект. UDP в этом случае всё разрулит ;)
4) Зачем проверять контрольную сумму? Данные не поточные, сколько байт отправил в пакете, столько и принял. Если приходит пакет с позицией игрока - будь уверен, что там будет позиция игрока, а не половина данных о ней ;)

1) Ну и приавльно. А че ты будешь делать с половиной пакета?
Если вместе "How do you do?" придет "How "..."you do?", что это тебе даст? Все равно придеться ждать части пакета.
2) Размер TCP заголовка = 32 байтам. - Уверен? ;)
В шутерах типа Quake 2-3 был выбор протокола. В HL 1-2 он также присутствует. - не видел. Где?
3) В игре по интурнету могут возникнуть такие ситуации, когда связь полностью обрывается и идёт реконнект. UDP в этом случае всё разрулит ;)
Не понимаю. Какое здесь преимущество у UDP.
4) ТОрмознул.. Ведь контролька же драйвером проверяеться.

Народ! Спор здесь не уместен! Вы сейчас только ветку зафлудите...
@!!ex, ты чтоль до сих пор не понял на чем XProger настаивает?
(я не к тому, что ты не прав, пусть мое мнение будет темным, я к тому,
что спор надо завершать)

@!!ex,
1) Прийдёт "How do you do?", UDP не бьёт пакеты на части...
2) советую почитать http://www.zeiss.net.ru/docs/technol/tcpip/tcp00.htm
а по поводу игр - подсказка: жми тильду ;)
3) UDP не разорвёт соединение и после реконнекта игра продолжится.
4) Основная контрольная сумма лежит в заголовке пакета и характеризует целостность его содержимого, TCP в любом случае бьёт данные на пакеты следовательно приходится вторично проверять целостность всего потока данных.

Cash, мы не воюем. Легкий спор, истина рождаеться в споре. Не флудим, а пытаемся выяснить истину.
1) Ла это то понятно, но все равно большой объем данных придеться в ручную бить на сегменты. Иначе в случае не доставки придеться опять посылать всю большую датаграмму.
2) Как это не смешно, но я его уже читал. :) И на столе лежит "Программирование в сетях Windows"
3) А что делать с утерянными пакетами? НА TCP то синхра реалтаймовых игр - большая проблема, а тут вообще кошмар получаеться...
4) Мгновенная порверка.

>>2) советую почитать http://www.zeiss.net.ru/docs/technol/tcpip/tcp00.htm
Кстати, ты бы тоже почитал эту ссылочку. Потому что
Про 20 байт я оттуда взял.
"На рисунке 17.2 показан формат TCP заголовка. Обычно его размер составляет 20 байт, если не присутствуют опции."

Cash, мы не воюем.
Мое дело предупредить. :)

О! Раз уж вы тут ссылками начали кидаться, мож наваляеете побольше! :)))
(А то чую, мой запас знаний в этой теме устаревает...)

пытаемся выяснить истину
Это многие пытаются сделать, но трение кроме огня ничего не дает...

Cash,
Да собственно лично мне уже нечего сказать в этой дискуссии.
ИМХО TCP более подходит для этого дела. Я попытался объяснить почему.
Решать автору. Немного изменил свое мнение об UDP, благодаря XProger"у. За что ему спасибо. Во многом он прав. Тут рассмотрели все плюсы-минусы.
Глядишь кому поможет выбрать.

XProger, спасибо за интересный разговор.

А UDP быстрее...

а я уже решил на XProger"овском l_net"е писать, там всё просто, да и игра у меня простая

вопросы:
1) IPX?
2) посоветуйте литературу для ознакомления с программированием сетевого взаимодействия в Delphi.

Сетевые игры сеть для игры. Найти похожие ветки