Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Сетевая игра. BCB6 [D6]

Страницы: < 1 2
megabyte-ceercop © (2005-12-12 07:21:00)
Привет всем.
Недавно увидел сетевого бомбермена, вот теперь уже окончательно понял что без сетевого варианта - игра не будет по-настоящему цепляющей : )

Ищу инфу по сетевому обмену. Игровой механизм уже продумал и реализовал. Теперь хочу сделать правильно Сетевой обмен.

Игра на два компа в локалке.
Обмен состоянием клавиш идет в каждом пакете. Плюс небольшими порциями передаются куски для синхронизации миров.

Интересуют такие вопросы:

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

Кокого размера буфер лучше передавать и как часто?
(из пределов 1-25кб / 20-50pps)

С какой частотой можно передавать буфер в 25кб не перегружая сетку (100Mb/s)? (25 кб - это полное описание всего мира без ландшавта (всех спрайтов), было бы не плохо просто клиенту копировать мир с сервака.)

Порт с номером из какого диапазона лучше пользовать?

Как получить список компов в локальной сети на которых открыты сервера игры, или хотя бы просто список всех компов в локалке?

Я по сетке вобщем ламак. Пытался делать поиск все запросы нулевые.

Как только реализую, выложу обновленную Альфу Киркопа III с сетевой игрой :)

Помогите кто знает.

cyborg (2005-12-28 13:45:00) [21]
Мана сенга ;)
http://www.realcoding.net/article/view/1833
Берёшь его примеры и перелопачиваешь под свои нужды.

megabyte-ceercop (2005-12-28 12:04:00) [22]

> Чтобы не заедало, создавай соединение в отдельном потоке.
> В блокирующем режиме даже нормально работать будет.

В том то и дело. Именно этот отдельный поток напрочь и виснет. обработка сети прекращается а игры живет дальше.
По винсокам2 искал. Слова что там все просто на каждом шагу, а вот работающего примера так нигде и не нашел. : |
С реализацией сети перебрал конечно несколько вариантов вроде ничего более быстрого простого и надежного не нашел чем та схема по которой сейчас работает. Боялся что не удастся динамику игры сохранить в сетевом варианте. Не ожиданно, но все движется гладко и быстро. :) Скорее бы все красиво обернуть и выложить уже :)

cyborg (2005-12-28 10:08:00) [23]
[16] megabyte-ceercop © (28.12.05 06:36)
По какому-то неверному пути ты пошёл. Скоро у тебя на каждый чих по соединению создаваться будет ;).
Чтобы не заедало, создавай соединение в отдельном потоке. В блокирующем режиме даже нормально работать будет.
И сеть, думаю, лучше на винсок сделать, там очень просто. В сети поищи, есть странички с описанием работы с ними в Дельфи.

megabyte-ceercop (2005-12-28 06:36:00) [24]

> Da Stranger © (27.12.05 12:33) [15]

Ну в смысле два соединения.

На каждом экземпляре игры есть tTCPсервер и tTCPклиент.
Клиент первого подключается к серверу второго, а клиент второго к серверу первго. Получается два сокет-соединения, по каждому соединению передача данных идет только в направлении от компонента tTCPклиент к компоненту tTCPсервер. Потомучто как я уже говорил, если передавать по одному соединению в обоих направлениях, прога виснет если используется сокет блокирующий поток. А если неблокирующий использовать, то не виснет, но опять же картинка на клиентской части игры дергается время от времени.

Сегодня начну реализацию внутриигрового чата.

Da Stranger (2005-12-27 12:33:00) [25]
Интересно, а что такое двойное соединение по TCP?..

megabyte-ceercop (2005-12-27 07:48:00) [26]
Всем привет.
Рассказываю : )

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

Прочитал про UDP переделал все полностью на DataGrams, думал будет работать быстрее, ведь протокол легче по идее. Но не тут-то было при отправке по UDP комп ваще стал 100% CPU забирать. Но чем UDP понравился - это поиск серверов игры в локалче через BroadCast. И еще через него очень легко сделать Внутренний чат и обмен текстовыми командами по подгрузке уровней и воспроизведению музыки.
В результате:
UDPServer UDPClient + TCPServer TCPClient (блокирующие поток).
В начале по удп клиент посылает широковещательную датаграмму сервера отвечают отсялая свой хост. Клиен берет понравившийся и отправляет ему подтверждение IJoin. После чего устанавливается TCP соединение, двойное причем. Для отправки данных в обоих направления. В процессе игры по UDP буду передаваться единовременные команды и сообщения чата, но это еще доработаю. Вот. Вроде теперь все летает, и компы в локалке находят друг друга без проблем :)

Непонятно только почему отправка тех же самых данных, в том же количестве но через UDP так сильно тормозит, когда по TCP ваще 1% загрузки?? : |

megabyte-ceercop (2005-12-14 09:54:00) [27]

> cyborg [12]

ок. С блокированием ясно. сделаю значит нонБлокинг :)
может и тормоза пропадут я не пробовал почемуто ^_^

Ну ладно. Буду по-тихой разбираться.
Буду держать все в курсе.

cyborg (2005-12-14 09:07:00) [28]

> Но стоит только отправить хоть один байт в обратном направлении
> - серверная часть начинает виснуть и занимать 99% производительности
> проца.
> Из-за чего такое может быть??

Скорей всего у тебя неправильно это дело обрабатывается. Цикл может какой крутится?

> И еще, что означает свойство tServer\ClientSocket->SocketType
> (Blocken\nonBlocket)??

Это в каком режиме работает соединение. В блокирующем режиме пока не отошлются или не примутся данные, передача управления на следующий оператор не произойдёт. Т.е. твоя программа приостановится, ожидая завершение приёма/передачи.

megabyte-ceercop (2005-12-14 07:20:00) [29]
ммм. Привет всем, еще раз.

Вот на такую проблему натолкнулся:
При передаче данных в одном направлении (с сервака на клиент) все ок.
Но стоит только отправить хоть один байт в обратном направлении - серверная часть начинает виснуть и занимать 99% производительности проца.
Из-за чего такое может быть?? : |
Я для эксперимента просто по нажатии кнопки на клиенте пишу в сокет один байт и все, а сервак сразу затормаживается. Читаю этот байт - тормозит, не читаю - тоже тормозит. Значит тут дело не в процедуре считывания этого байта, а в чем-то другом.
И еще, что означает свойство tServer\ClientSocket->SocketType (Blocken\nonBlocket)?? Я в блокет его поставил.

Может эти компоненты не подходят для двустороннего обмена?? Хотя это глупость конечно.
Я уже думаю о том, что придется второе соединение устанавливать - для обратной передачи данных.

megabyte-ceercop (2005-12-13 14:40:00) [30]
Ну я вобщем вчера вечером покопался немного.
Сделал так:

С сервера по таймеру с интервалом 50мСек передаются пакеты 7кб.
В каждом пакете клавиши сервера и 1/4 часть мира которая на клиенте вставляется в нужное место. Т.е. мир полностью синхранизуется за 4 прохода. В пакетах инфа о координатах скорости цвете всех спрайтов. Текущии позиции для обработки алгоритмов каждого спрайта и.т.д. Промежуточные фреймы расчитываются уже клиентом самостоятельно инфы для этого достаточно.
7кб x 20 в секунду при таком обмене все идет абсолютно гладко без скачков. Игра динамичная - там Киркопы (Да пришлось пока двоих киркопов гонять. , ^_^ потом заменю на девочку - его подружку :) ) Киркопы носятся как угорелые всеравно все гладко и синхронно :) Если что можно будет с интервалом отправки и размером пакета по экспереминтировать и снизить нагрузки на сеть.

На клиенте в отдельном потоке запущена процедура непрерывного чтения из сокета. Таким способом отставание которое появлялось раньше через минуту - исчезло ваще:) На картинках сервера и клиента действия абсолютно синхронны.

С клиента сейчас в ответ на каждый пакет сервера отправляю 1 байт с инфой о состоянии клавиш, вот с чтением этого байта на серваке сегодня постараюсь разобраться, что-то немного нестабильно, похоже из-за обращения к сокету из двух Thread`ов одновременно. Попробую семафор.

На счет ужатия инфы, можно конечно ужать, но хочется иметь просто две абсолютных копии мира. По нету конечно играть не получится, расчитываю только не локалку, даже на 10кбитах по расчетам должно работать без лагов :)

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

Ну пока. Сегодня вечером дома посмотрим что получится. На работе с Киркопом завязал :)

П7 (2005-12-12 17:05:00) [31]
При одинаковом подходе тормоза возникают при использовании TCP. При юзании UDP возникают сложности другого плана.

cyborg (2005-12-12 16:25:00) [32]
Крайне интересная тема!
Тоже пытался одно время именно бомбермена делать, но толком не получилось из за недостатка информации. Получилось сделать обработку на сервера, а клиент только состояния объектов получает. Только так меня не устроила задержка у клиента, слишком медлено по инету передавалось, иногда до двух секунд бывало.

Во первых, желательно ориентироваться на модемную связь. Грубо говоря 4 килобайта в секунду, не больше. 200 байт за пакет. В эти 200 байт можно ужать много полезной информации. Основное, это координаты важныхобъектов. Т.е. других игроков и близлежащих врагов (можно всех). Остальное (анимации всякие) не обязательно и передавать, а о состояниях дверей или ещё каких нибудь ключевых вещей можно передавать один раз при их изменении.

Если у тебя получится воплотить это в игру, то крайне любопытно было бы почитать об этом. ;)

megabyte-ceercop (2005-12-12 14:54:00) [33]
Читал о возможностях DirecPlay. Оно и само регестрирует созданые игры и само их ищет для клиента и много много чего.
Но для игры камп<->комп это лишнее.
Не хочется просто продумывать взаимодействие со всем этим из скриптового языка.

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

П7 (2005-12-12 14:35:00) [34]

> WondeRu © (12.12.05 14:11) [5]

В топку! (:

WondeRu (2005-12-12 14:11:00) [35]
DirectPlay - специально для этого придуман

_Lucky_ (2005-12-12 13:43:00) [36]
http://www.gamedev.ru/articles/?sect=8

megabyte-ceercop (2005-12-12 12:44:00) [37]
ого :) Похоже я зря боялся за перегрузку сети : ) подключение 100Мбит при отправке 20 пакетов в секунду размером в 7 Кб каждый - загрузка сети меньше 3% :)
Может я конечно неправильно измеряю :)?

megabyte-ceercop (2005-12-12 12:29:00) [38]
Я тут потестил немного.
Пакет 7Кб мне понравился. При стабильном конекте 3мс на передачу уходит.

7к будет передаваться только в одном направлении, обратно сервак получает только 1 байт инфы о клавишах.

А где посмотреть пример правильного установления и разрыва соединения.
У меня вроде получается, но как-то все просто слишком :)

Еще такой косяк наблюдается - запускаю два экземпляра игры сервак и клиент. На серваке управляю героем на клиенте все тоже самое происходит, но вот примерно через минуту клиент начинает отставать на полсекунды примерно в действиях героя. Похоже сервак пишет немного чаще чем клиент считывает. Чтение запись и там и там у меня просто по таймеру с одинаковым интервалом.
Нужен пример синхронизации сервера и клиента в исходниках желательно:), чтобы например при отправке каждого пакета с сервера на клиенте вызывался обработчик события. TClientSocket имеет вроде такое событие вот только оно не срабатывает ни в какую.

Есть ли у кого описание TServerSocket TClientSocket с примером, и стоит ли использовать именно эти компоненты? МОжет есть чтото быстрее и удобнее? :)

П7 (2005-12-12 11:16:00) [39]
1. Где ты видел низкоуровневые компоненты? (:
2. Оптимайзить и ещё раз оптимайзить. 25кб можно сильно ужать, или передавать мир частями в тот момент, когда он изменяется.
3. Учится работать с поиском. Нулевыми они не могут быть.
4. Читать форум "Сети".
5. Порт юзать больше 1024.

Страницы: < 1 2

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »