forum.boolean.name - Онлайн (Клиент <-> Сервер)

forum.boolean.name

forum.boolean.name (http://forum.boolean.name/index.php)

- 2D-программирование (http://forum.boolean.name/forumdisplay.php?f=13)

- - Онлайн (Клиент <-> Сервер) (http://forum.boolean.name/showthread.php?t=8061)

butcher

26.03.2009 15:48

Онлайн (Клиент <-> Сервер)

Решил сделать мини онлайн игру... - да бы получить опыт, работы с потоками...
Вопрос:
Что лучше выбрать для этого (TCP, UPD)?
- если UPD? - то есть, какой-нить пример тип Клиент <-> Сервер?

HAMANN

26.03.2009 20:47

Ответ: Онлайн (Клиент <-> Сервер)

юзай TCP Если мини онлайн игра)))) а пример в хелпе не плохой)

Randomize

26.03.2009 21:10

Ответ: Онлайн (Клиент <-> Сервер)

UDP - cверхбыстрый, но сохранность данных не гарантируется.
TCP - более медленный, но с проверкой и данных.

Phantom

26.03.2009 21:58

Ответ: Онлайн (Клиент <-> Сервер)

Однозначно TCP.

butcher

27.03.2009 00:05

Re: Онлайн (Клиент <-> Сервер)

"юзай TCP Если мини онлайн игра))))" - тобишь для норм онлайн рпг протокол не подойдет?

jimon

27.03.2009 00:12

Ответ: Онлайн (Клиент <-> Сервер)

butcher
если ты не знаешь что выбрать, то ты игру всё равно не сделаешь, какая разница тогда что использовать ?
и на том и на том можно сделать нормальную игру, просто грабли будут разные
но основные грабли которые убивают почти любой онлайн проект - синхронизация игрового времени
игровые события доставляются с задержками порядка 200-500 мс, а юзеру уже надо показывать что-то

moka	27.03.2009 03:23

Ответ: Онлайн (Клиент <-> Сервер)

jimon, ну ты загнул 200-500, это с модемом чтоли, если это фпс, то туда-сюда, (ping) если выше 120, то уже не играбельно, при этом что щас уже почти любой имеет интернет с нормальной скоростью, и пинги ниже 100. Я предпочетаю вообще ниже 40, чтобы нормально играть в FPS.

Phantom

27.03.2009 06:19

Ответ: Онлайн (Клиент <-> Сервер)

Ну я вот для мобилы всё собираюсь написать какую-нибудь онлайн игру. А там скорость интернета, извините за выражение, гавно :-D Вот как мне чувак сервер напишет на C++, тогда буду думать что написать. Но скорее всего сделаю что-то пошаговое и несложное. =)

jimon

27.03.2009 09:05

Ответ: Онлайн (Клиент <-> Сервер)

MoKa
дык, не всё же так просто - имеем игрок_1, игрок_2, сервер
между игрок_1 и сервером пинг A, между игрок_2 и сервером пинг B,сервер может отправлять пакеты с задержкой C (время между приемом и отправкой - тоесть обработка)

игрок_1 посылает данные в на сервер при этом клиент игрока_1 тут же после отсылки начинает анимацию движения (хотя задержка должна быть равна A+C), сервер получает данные и отправляет назад коректировочные параметры (античитерство)
тоже самое с игроком_2, там время разницы между игрой и сервером B+C
из-за того что двум игрокам надо знать друг получаем что игрок_1 получит данные от игрок_2 при времени A/2+B/2+2*C (половинный пинг, две обработки сервера - игроки же не одновременно отправляют данные)
но всё это идеализированая ситуация системы, крайне жестого завязаной на пингах, представим что у кого-то пинг очень резко подскачет до 500 мс (винда заглючила, игра ресурсы подгружает и тд)
в идеале коректировка должна правильно отобрасить всё движение игрока, но зачастую рывков не избежать, но что делать серверу ? он же получает почти что нажатия на клавиши (иначе как сделать античит?)
при этом сервер тупо не знает какая разница в внутри игровом времени себя и игроков, конечно оно синхронизируется, но это хорошо когда пинги не скачут, а иногда так подскочут что разница в внутриигровом времени будет больше и получится что к нам прийдут пакеты "из прошлого", по-сути в них игровое время уже меньше чем текущее

так что реальная задержка между данными может прыгать от A/2+B/2+2*C до A+B+2*C, надо еще учитывать что иногда мы теряем пакеты из-за времени (ихная актуальность теряется быстрее чем они доходят до клиента, а пока клиент запросит новый пакет тоже что-то надо отображать - процесс синхронизации еще больнее)
чтобы сделать задержку меньше моего написаного A/2+B/2+2*C всякие игры делают мега извращения - предсказания пути, то-есть по уже полученым данным о траектории пути, клиент начинает добавлять туда точки чтобы предсказать траекторию дальше, а если она не будет сходится с тем что мы получим от сервера ? ну тогда жестоко прийдется переставлять позицию или применять какую-то очень сложную коректировку которая не всегда правильно смотрится
из-за этого игровое время на сервере опережает игровое время на всех клиентах
но даже саму траекторию, полученую по-точкам от сервера, пусть даже без задержек, но надо же чем-то анимировать ? тут тоже свои причуды

исходя из этого можно сказать что проблемы следуйшие :
1) пинги не стабильны
2) разница в игровом времени на всех клиентах и сервере
3) нечеловеческие усилия алгоритмов предсказания и коректировщиков траектории
4) слишком большая разница во времени между действительно актуальными пакетами (движек q3 тупо игнорит не актуальные), а во время этой разницы надо отрисовать хотя бы 100 кадров (обычно)

так что создание хорошей сетевой части игры равноценно программированию всей игры

DartWaider aka Yxo

28.03.2009 04:43

Ответ: Онлайн (Клиент <-> Сервер)

Быстро чётко и понятно, спасибо большое.
Кстати читал что сервы ВОВ изначально расчитывалиль на пинг в районе 400мс. И некоторые дядьки говорят что игру надо расчитывать с минимумом в 500мс, так как есть дяди игращие с чукотки через спутник...

tormoz

28.03.2009 12:19

Ответ: Онлайн (Клиент <-> Сервер)

Цитата:

3) нечеловеческие усилия алгоритмов предсказания и коректировщиков траектории

вот этот пункт является главной сложностью всех динамичных сетевых игр.
все остальное - делается левой ногой (по сравнению с этим)
я еще не видел не одной нормальной аматорской сетевой игры с удовлетворительно реализованным предсказанием

ffinder

28.03.2009 12:54

Ответ: Онлайн (Клиент <-> Сервер)

2 jimon: можно было все это сказать короче.
онлайновые RPG - пошаговые игры, которые притворяются что они realtime (тик игровой логики может достигать нескольких секунд, а на клиенте просто проигрывается какая-то анимация для создания видимости движения)
онлайновые шутеры - HL2 например - используют свою систему времени, когда в отправленом пакете есть время (игровое) его отправки, поэтому даже когда пакет приходит позже (в разумных пределах), сервер смотрит что было в тот момент времени и корректирует попадания. Из-за этого возможен снайпинг на больших чем в локалке пингах.
что делать с онлайновыми файтингами я не знаю.

jimon

28.03.2009 13:05

Ответ: Онлайн (Клиент <-> Сервер)

ffinder
в онлайновых рпг тоже надо делать некоторую синхронизацию, иначе у всех на экранах будет разное состояние игрового мира

SBJoker

28.03.2009 13:34

Ответ: Онлайн (Клиент <-> Сервер)

На кри'08 на лекции по предсказанию в сетевых играх докладчик делился своими данными, они помещали сервер в"будущее" на 500мс, чтобы это компенсировало отставание клиентов. Однако по их словам при тестировании Москва-Чикаго пинг доходил до 1400мс... так что лучше больше чем меньше.

Разницу времени клиентов обычно обходят хранением истории игровых состояний на сервере за последние несколько секунд. Что нам это даёт, если у игрока огромный пинг, но его комп предсказывает поведение врагов (нет скачкообразных движений), то игрок попав во врага у себя на экране должен попасть и на сервере, для этого сервер для проверки попадания во врага, отматывает игровое состояние назад на величину пинга игрока. И смотрит попал ли он, если да клиенту шлётся подтверждение. Т.е. сервер должен обрабатывать игру в всоответствии с временем клиента.

moka	28.03.2009 20:15

Ответ: Онлайн (Клиент <-> Сервер)

SBJoker, ужс, мне страшно становится, с временными факторами..
Хотя в CoD4 и HL2, очень чуствуется что реально игра происходит у тебя на компе, а не на сервере..

jimon

28.03.2009 21:40

Ответ: Онлайн (Клиент <-> Сервер)

MoKa
в таких играх программисты и проявляют своё мастерство

3dr1aN

29.03.2009 01:33

Ответ: Онлайн (Клиент <-> Сервер)

а как на счет гонок, на PhysX , как тут реализовать столкновения тачек? как передать позицию авто?
под офтопом идет моя догадка по этому поводу, идея туповата поэтому можно внимания необращать

impersonalis

29.03.2009 03:43

Ответ: Онлайн (Клиент <-> Сервер)

В принципе физику и прочие внутренности некой функции состояния (т.н. пси-функция) можно (в большинстве случаев именно так) обрабатывать непосредственно на машине плеера, а на серевер передавать лишь результат - координаты, углы вращения и прочий стафф (т.н. обобщённые координаты).
Есть у данной реализации минус - сервер верит на слово клиенту, а потому адекватной системы защиты от читера нет: можно, конечно, ограничить на сервере скорость автомобиля на 300км\ч - но где гарантия, что подобная сокрость не результат падения с большой высоты и т.п.
Первый же вариант влечёт имхо нереальные траблы по интерполяции, защите от рассинфазирования, оптимизации кода.

Baisangur

29.03.2009 04:13

Ответ: Онлайн (Клиент <-> Сервер)

Ужс! Какими вещами завалили человека то!
Юзать UDP - это однозначно, если будешь с TCP играться, то на проверку дохода пакета будет уходить туча времени.
Лучше всего на сервере раз 5 в секунду проходить т.н. "главный цикл", в нем сначала принимать поступившие от всех клиентов данные, сравнивать с теми, которые установлены в настройках сервера и если у кого то, скорость чего либо или сила чего либо выше той, что назначена в сервере сразу банить по IP адресу(ну ето если есть БД, а так можно просто например в текстовичок запрещенные IP складывать), после этой стадии уже делать снимок игрового мира(на сервере) и отсылать данные обратно клиентам. Лучше в этом деле это организовать систему нитей(потоки) ибо если делать все в цикле то тормоза при n-ом кол-ве клиентов будут расти просто в геометрической прогрессии.

Предположим, что есть у тебя сервер и клиент, как сделать так чтобы без задержек у клиента шел процесс:
Как уже говорилось от сервера приходят "снимки" игрового мира, в нашем случае 5 раз в секунду, можно и больше, но это больший объем информации. Строить логику клиента надо так, чтобы получив два снимка он двигал объекты и проигрывал анимацию основываясь на положениях объектов на сервере(стоит, идет, бежит, едет) и полагаясь на полученные две координаты начальные и конечные двигать что - либо, если юзер изменит конечные координаты, то за начальные принять те, что были при изменении конечных. При этом не будут видны задержки движения врагов, или других объектов полагающихся на сервер.
Также, как без задержки обрабатывать врагов:
Допустим есть у тебя в игре монстры(например игра жанра РПГ с мобами):
Если они будут атаковать тебя полагаясь только на сервер то может быть такой эффект, стоишь ты спокойно и через секунду уже лежишь дохлый, это получится если твой интернет канал тормознет, а на сервере уже тебя убъют. Лучше всего делать реакцию монстра на присутствие игрока в самом клиенте, а на сервере только проверять его стейты(живой, мертвый, атакует и т.п.). И умирать должен игрок или монстр только в клиенте, а патом уже отсылаться на сервер. Конечно это все не так просто ибо взломать клиент и набивать таким образом мобов может любой хацкирь-геймер. Что делать? Необходимо принять минимальный промежуток времени, за который моба можно убить средствами клиента - это впринципе спасёт, а вот защита от ботов, блоу фиш ключи это уже другая тема.. =)
В общем думаю из всей этой писанины ясно что и как делать и в какую сторону дышать...

3dr1aN

03.04.2009 22:16

Ответ: Онлайн (Клиент <-> Сервер)

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

Код:

AppTitle "client"

strmGame=OpenTCPStream("192.168.1.2",8080) 



If strmGame<>0 Then 

Print "Клиент соединился с сервером." 

Else 

Print "Сервер не отвечает." 

WaitKey 

;End 

End If 

While Not KeyHit(1)



WriteString strmGame, Input()

Print "Сообщение Центр Управления отправлено успешно..." 

Wend

End

при чем сервер незапущен, он мне выдает
{"Клиент соединился с сервером."}

ЗЫ: 192.168.1.2 - мой IP в домашней сети через роутер

jimon

03.04.2009 22:26

Ответ: Онлайн (Клиент <-> Сервер)

3dr1aN
может у тебя открыт порт 8080 ?

3dr1aN

03.04.2009 22:29

Ответ: Онлайн (Клиент <-> Сервер)

на другой ставил, аналогично, порт 8000
[добавлено]
а на савсем другой да, неработает, порт 11000

LeonSmile

10.09.2009 04:07

Онлайн Клиент t t Сервер

смысол в том, что бы без переупаковки это все делать. А файл передовать с буфферезацией. Естественно если лаг будет большим то не поможет.
А сервер раздает все центрлизованно. следить именно за скоростью передачи данных. Пока это все обстрактно

ІГРОГРАЙКО

19.09.2009 23:09

Ответ: Онлайн (Клиент <-> Сервер)

Народ. Кто знает как для сервера (написаном на Blitz3D) с протоколом UDP устанавливать маршруты? Предположым эсть у нас сервер с виделеным IP а клиэнт находитса гдето в подсети провайдера и отправить клиенту сообщение так просто не получитса :dontknow: ...
Можно ли както в Блице установить ето или все таки юзать в CMD команду: route add

ІГРОГРАЙКО

21.09.2009 20:11

Ответ: Онлайн (Клиент <-> Сервер)

Ище один вопрос! А можно както так зделать VPN сервер штобы когда подключатса к нему ненадо било создавать VPN подключение клиента?
:4to:

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

vBulletin® Version 3.6.5.
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Перевод: zCarot