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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 кадров (обычно)

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

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

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

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

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

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

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

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

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

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

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

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

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

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