Russian Qt Forum
Декабрь 10, 2019, 12:13 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: Сетевая игра в режиме реального времени. Qt  (Прочитано 2188 раз)
Nelkor
Гость
« : Октябрь 25, 2014, 18:27 »

Всем привет!
Решил в учебных целях сделать на Qt сетевую игру (для локальной сети) в режиме реального времени. Всё что я знаю о работе с сетью в Qt - глава из книги Макса Шлее. Ну и конечно, в силу своей нубости столкнулся с рядом проблем. А точнее проблема только одна - на "хосте" игра летает, на "клиентах" - лагает. Причин, наверное множество, и вот какие вопросы я хотел бы задать:

1. До того, как я увидел тормоза на "клиенте" я считал, что выделить на клиента 1 порт - это хорошая идея. Сейчас я начинаю задумываться о том, что через 1 порт, наверное, информация идёт туговато. А может я ошибаюсь. Сколько примерно выделяют портов для игр?

2. Таймер запущен только на хосте, для всех клиентов update() происходит по сигналу readyRead() от сервера, после соответствующего чтения информации. Опять же не знаю, хорошая это идея или плохая. Как обычно поступают для координации времени в играх?

3. Все расчеты ведутся только на хосте. Поэтому информации приходится передавать очень много. Это решаемая проблема - каждый клиент может брать на себя часть расчетов и серверу придётся меньше передавать. Однако как же тогда работают настоящие игры, в которых информации передаётся уж явно в разы больше, причем не по локалке, а через интернет, и таких тормозов даже близко нет. Что можете посоветовать по этому поводу?

4. TCP-соединение. Может быть лучше UDP, ибо он быстрее? А что используется в настоящих играх? Тем более, если сделать так, чтобы клиенты сами расчитывали себе часть параметров, а передавались только ключевые, то потеря пакетов становится критичной. Можно, конечно, доработать игру до такой степени, что потери пакетов будут выявляться на стороне клиента и корректироваться с новыми полученными пакетами, но ведь потеря пакетов - это в любом случае плохо?

5. Поскольку учился я по книге М. Шлее, умею подключаться только к конкретному порту конкретного компьютера (по его имени). А как же сделать что-то типа "мониторинга" сети? Вот как, извиняюсь, в варкрафте: Кто-то создал игру - другие видят, что появился такой-то хост, и могут к нему законнектиться. Как происходит сей процесс?

Буду благодарен любым советам! Возможно данные вопросы интересны не только мне, и данная тема разовьётся в хорошую дискуссию. Пожалуйста, активно принимаем участие)
Записан
vulko
Гость
« Ответ #1 : Октябрь 27, 2014, 10:43 »

1. До того, как я увидел тормоза на "клиенте" я считал, что выделить на клиента 1 порт - это хорошая идея. Сейчас я начинаю задумываться о том, что через 1 порт, наверное, информация идёт туговато. А может я ошибаюсь. Сколько примерно выделяют портов для игр?
Все зависит от ситуации. Если например ты будешь слать однотипные данные на 4 порта, нужно их собрать будет. при сборке нужно учитывать время отправки.
А вот выбрать несколько портов для разных данных это нормально. Например на первый порт идут данные сигналинга, на второй данные игры и т.д.

2. Таймер запущен только на хосте, для всех клиентов update() происходит по сигналу readyRead() от сервера, после соответствующего чтения информации. Опять же не знаю, хорошая это идея или плохая. Как обычно поступают для координации времени в играх?
Не специалист в игро-строении, но для начала почему бы и нет. А вообще данные лучше принимать в отдельном потоке, особенно если у тебя не какие-нибудь шахматы.

3. Все расчеты ведутся только на хосте. Поэтому информации приходится передавать очень много. Это решаемая проблема - каждый клиент может брать на себя часть расчетов и серверу придётся меньше передавать. Однако как же тогда работают настоящие игры, в которых информации передаётся уж явно в разы больше, причем не по локалке, а через интернет, и таких тормозов даже близко нет. Что можете посоветовать по этому поводу?
Насколько я знаю, серьезные сетевые игры обрабатывают все данные на серверах. Клиенты шлют только свои данные.
Отправка данных идет с той скоростью, которую тянет сеть. Частота отправки данных соответсвует (1 / ping). Ping зависит от размера пакета, но для 1..64(128) байт он в принципе одинаковый.

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

5. Поскольку учился я по книге М. Шлее, умею подключаться только к конкретному порту конкретного компьютера (по его имени). А как же сделать что-то типа "мониторинга" сети? Вот как, извиняюсь, в варкрафте: Кто-то создал игру - другие видят, что появился такой-то хост, и могут к нему законнектиться. Как происходит сей процесс?
В локальной сети есть широковещательные пакеты multicast.
Бывают архитектуры с сервером, к которому подключаются юзеры и там создают игры и видят обновления списка игр. Обновление может быть автоматом, либо по запросу от клиента (юзер нажал кнопку обновить например).
Варианты есть разные...

Поскольку ты хочешь чему-то научиться, а не создать аналог варкрафта, где высоконагруженные кластеры серверов обрабатывают данные от тысяч игроков, то делать все как в таких играх не нужно.
Начни с простого. А потом усложнишь.
Записан
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.064 секунд. Запросов: 20.