Russian Qt Forum
Ноябрь 22, 2024, 17:09
Добро пожаловать,
Гость
. Пожалуйста,
войдите
или
зарегистрируйтесь
.
Вам не пришло
письмо с кодом активации?
1 час
1 день
1 неделя
1 месяц
Навсегда
Войти
Начало
Форум
WIKI (Вики)
FAQ
Помощь
Поиск
Войти
Регистрация
Russian Qt Forum
>
Forum
>
Программирование
>
Разработка игр
>
Сетевая игра в режиме реального времени. Qt
Страниц: [
1
]
Вниз
« предыдущая тема
следующая тема »
Печать
Автор
Тема: Сетевая игра в режиме реального времени. Qt (Прочитано 33665 раз)
Nelkor
Гость
Сетевая игра в режиме реального времени. Qt
«
:
Октябрь 25, 2014, 18:27 »
Всем привет!
Решил в учебных целях сделать на Qt сетевую игру (для локальной сети) в режиме реального времени. Всё что я знаю о работе с сетью в Qt - глава из книги Макса Шлее. Ну и конечно, в силу своей нубости столкнулся с рядом проблем. А точнее проблема только одна - на "хосте" игра летает, на "клиентах" - лагает. Причин, наверное множество, и вот какие вопросы я хотел бы задать:
1. До того, как я увидел тормоза на "клиенте" я считал, что выделить на клиента 1 порт - это хорошая идея. Сейчас я начинаю задумываться о том, что через 1 порт, наверное, информация идёт туговато. А может я ошибаюсь. Сколько примерно выделяют портов для игр?
2. Таймер запущен только на хосте, для всех клиентов update() происходит по сигналу readyRead() от сервера, после соответствующего чтения информации. Опять же не знаю, хорошая это идея или плохая. Как обычно поступают для координации времени в играх?
3. Все расчеты ведутся только на хосте. Поэтому информации приходится передавать очень много. Это решаемая проблема - каждый клиент может брать на себя часть расчетов и серверу придётся меньше передавать. Однако как же тогда работают
настоящие
игры, в которых информации передаётся уж явно в разы больше, причем не по локалке, а через интернет, и таких тормозов даже близко нет. Что можете посоветовать по этому поводу?
4. TCP-соединение. Может быть лучше UDP, ибо он быстрее? А что используется в настоящих играх? Тем более, если сделать так, чтобы клиенты сами расчитывали себе часть параметров, а передавались только ключевые, то потеря пакетов становится критичной. Можно, конечно, доработать игру до такой степени, что потери пакетов будут выявляться на стороне клиента и корректироваться с новыми полученными пакетами, но ведь потеря пакетов - это в любом случае плохо?
5. Поскольку учился я по книге М. Шлее, умею подключаться только к конкретному порту конкретного компьютера (по его имени). А как же сделать что-то типа "мониторинга" сети? Вот как, извиняюсь, в варкрафте: Кто-то создал игру - другие видят, что появился такой-то хост, и могут к нему законнектиться. Как происходит сей процесс?
Буду благодарен любым советам! Возможно данные вопросы интересны не только мне, и данная тема разовьётся в хорошую дискуссию. Пожалуйста, активно принимаем участие)
Записан
vulko
Гость
Re: Сетевая игра в режиме реального времени. Qt
«
Ответ #1 :
Октябрь 27, 2014, 10:43 »
Цитата: Nelkor от Октябрь 25, 2014, 18:27
1. До того, как я увидел тормоза на "клиенте" я считал, что выделить на клиента 1 порт - это хорошая идея. Сейчас я начинаю задумываться о том, что через 1 порт, наверное, информация идёт туговато. А может я ошибаюсь. Сколько примерно выделяют портов для игр?
Все зависит от ситуации. Если например ты будешь слать однотипные данные на 4 порта, нужно их собрать будет. при сборке нужно учитывать время отправки.
А вот выбрать несколько портов для разных данных это нормально. Например на первый порт идут данные сигналинга, на второй данные игры и т.д.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
2. Таймер запущен только на хосте, для всех клиентов update() происходит по сигналу readyRead() от сервера, после соответствующего чтения информации. Опять же не знаю, хорошая это идея или плохая. Как обычно поступают для координации времени в играх?
Не специалист в игро-строении, но для начала почему бы и нет. А вообще данные лучше принимать в отдельном потоке, особенно если у тебя не какие-нибудь шахматы.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
3. Все расчеты ведутся только на хосте. Поэтому информации приходится передавать очень много. Это решаемая проблема - каждый клиент может брать на себя часть расчетов и серверу придётся меньше передавать. Однако как же тогда работают
настоящие
игры, в которых информации передаётся уж явно в разы больше, причем не по локалке, а через интернет, и таких тормозов даже близко нет. Что можете посоветовать по этому поводу?
Насколько я знаю, серьезные сетевые игры обрабатывают все данные на серверах. Клиенты шлют только свои данные.
Отправка данных идет с той скоростью, которую тянет сеть. Частота отправки данных соответсвует (1 / ping). Ping зависит от размера пакета, но для 1..64(128) байт он в принципе одинаковый.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
4. TCP-соединение. Может быть лучше UDP, ибо он быстрее? А что используется в настоящих играх? Тем более, если сделать так, чтобы клиенты сами расчитывали себе часть параметров, а передавались только ключевые, то потеря пакетов становится критичной. Можно, конечно, доработать игру до такой степени, что потери пакетов будут выявляться на стороне клиента и корректироваться с новыми полученными пакетами, но ведь потеря пакетов - это в любом случае плохо?
Смотря какие данные... например если посмотреть на игру шахматы... или покер, там важно чтобы пакет дошел. Количество данных небольшой. Можно для простоты воспользоваться и TCP.
UDP быстрее, но пакеты могут теряться. В локалке врядли, а вот через интернет уже вполне вероятно.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
5. Поскольку учился я по книге М. Шлее, умею подключаться только к конкретному порту конкретного компьютера (по его имени). А как же сделать что-то типа "мониторинга" сети? Вот как, извиняюсь, в варкрафте: Кто-то создал игру - другие видят, что появился такой-то хост, и могут к нему законнектиться. Как происходит сей процесс?
В локальной сети есть широковещательные пакеты multicast.
Бывают архитектуры с сервером, к которому подключаются юзеры и там создают игры и видят обновления списка игр. Обновление может быть автоматом, либо по запросу от клиента (юзер нажал кнопку обновить например).
Варианты есть разные...
Поскольку ты хочешь чему-то научиться, а не создать аналог варкрафта, где высоконагруженные кластеры серверов обрабатывают данные от тысяч игроков, то делать все как в таких играх не нужно.
Начни с простого. А потом усложнишь.
Записан
reyamo6736
Новичок
Offline
Сообщений: 1
Играйте в крутые сайта и получайте отличные преиму
Re: Сетевая игра в режиме реального времени.
«
Ответ #2 :
Октябрь 24, 2022, 16:48 »
Все зависит от ситуации. Если например ты будешь слать однотипные данные на 4 порта, нужно их собрать будет. при сборке нужно учитывать время отправки.
А вот выбрать несколько портов для разных данных это нормально. Например на первый порт идут данные сигналинга, на второй данные игры и т.д.
В локальной сети есть широковещательные пакеты multicast.
Бывают архитектуры с сервером, к которому подключаются юзеры и там создают игры и видят обновления списка игр. Обновление может быть автоматом, либо по запросу от клиента (юзер нажал кнопку обновить например).
«
Последнее редактирование: Октябрь 24, 2022, 21:58 от gil9red
»
Записан
Turbo Casino — это новое онлайн-казино, предлагающее игрокам шанс выиграть реальные деньги и призы. Площадка
казино turbo на деньги
поддерживается ведущими поставщиками программного обеспечения, включая Playtech и Micr
negova
Новичок
Offline
Сообщений: 2
Re: Сетевая игра в режиме реального времени. Qt
«
Ответ #3 :
Ноябрь 18, 2022, 20:37 »
Цитата: vulko от Октябрь 27, 2014, 10:43
Цитата: Nelkor от Октябрь 25, 2014, 18:27
1. До того, как я увидел тормоза на "клиенте" я считал, что выделить на клиента 1 порт - это хорошая идея. Сейчас я начинаю задумываться о том, что через 1 порт, наверное, информация идёт туговато. А может я ошибаюсь. Сколько примерно выделяют портов для игр?
Все зависит от ситуации. Если например ты будешь слать однотипные данные на 4 порта, нужно их собрать будет. при сборке нужно учитывать время отправки.
А вот выбрать несколько портов для разных данных это нормально. Например на первый порт идут данные сигналинга, на второй данные игры и т.д.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
2. Таймер запущен только на хосте, для всех клиентов update() происходит по сигналу readyRead() от сервера, после соответствующего чтения информации. Опять же не знаю, хорошая это идея или плохая. Как обычно поступают для координации времени в играх?
Не специалист в игро-строении, но для начала почему бы и нет. А вообще данные лучше принимать в отдельном потоке, особенно если у тебя не какие-нибудь шахматы.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
3. Все расчеты ведутся только на хосте. Поэтому информации приходится передавать очень много. Это решаемая проблема - каждый клиент может брать на себя часть расчетов и серверу придётся меньше передавать. Однако как же тогда работают
настоящие
игры, в которых информации передаётся уж явно в разы больше, причем не по локалке, а через интернет, и онлайн-казино Селектор является ведущим онлайн
-
казино на рынке. Он предлагает широкий выбор игровых автоматов и настольных игр в рулетку. таких тормозов даже близко нет. Что можете посоветовать по этому поводу?
Насколько я знаю, серьезные сетевые игры обрабатывают все данные на серверах. Клиенты шлют только свои данные.
Отправка данных идет с той скоростью, которую тянет сеть. Частота отправки данных соответсвует (1 / ping). Ping зависит от размера пакета, но для 1..64(128) байт он в принципе одинаковый.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
4. TCP-соединение. Может быть лучше UDP, ибо он быстрее? А что используется в настоящих играх? Тем более, если сделать так, чтобы клиенты сами расчитывали себе часть параметров, а передавались только ключевые, то потеря пакетов становится критичной. Можно, конечно, доработать игру до такой степени, что потери пакетов будут выявляться на стороне клиента и корректироваться с новыми полученными пакетами, но ведь потеря пакетов - это в любом случае плохо?
Смотря какие данные... например если посмотреть на игру шахматы... или покер, там важно чтобы пакет дошел. Количество данных небольшой. Можно для простоты воспользоваться и TCP.
UDP быстрее, но пакеты могут теряться. В локалке врядли, а вот через интернет уже вполне вероятно.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
5. Поскольку учился я по книге М. Шлее, умею подключаться только к конкретному порту конкретного компьютера (по его имени). А как же сделать что-то типа "мониторинга" сети? Вот как, извиняюсь, в варкрафте: Кто-то создал игру - другие видят, что появился такой-то хост, и могут к нему законнектиться. Как происходит сей процесс?
В локальной сети есть широковещательные пакеты multicast.
Бывают архитектуры с сервером, к которому подключаются юзеры и там создают игры и видят обновления списка игр. Обновление может быть автоматом, либо по запросу от клиента (юзер нажал кнопку обновить например).
Варианты есть разные...
Поскольку ты хочешь чему-то научиться, а не создать аналог варкрафта, где высоконагруженные кластеры серверов обрабатывают данные от тысяч игроков, то делать все как в таких играх не нужно.
Начни с простого. А потом усложнишь.
В локальной сети есть широковещательные пакеты multicast.
Записан
layex
Новичок
Offline
Сообщений: 1
Re: Сетевая игра в режиме реального времени. Qt
«
Ответ #4 :
Ноябрь 19, 2022, 00:23 »
Цитата: vulko от Октябрь 27, 2014, 10:43
Цитата: Nelkor от Октябрь 25, 2014, 18:27
1. До того, как я увидел тормоза на "клиенте" я считал, что выделить на клиента 1 порт - это хорошая идея. Сейчас я начинаю задумываться о том, что через 1 порт, наверное, информация идёт туговато. А может я ошибаюсь. Сколько примерно выделяют портов для игр?
Все зависит от ситуации. Если например ты будешь слать однотипные данные на 4 порта, нужно их собрать будет. при сборке нужно учитывать время отправки.
А вот выбрать несколько портов для разных данных это нормально. Например на первый порт идут данные сигналинга, на второй данные игры и т.д.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
2. Таймер запущен только на хосте, для всех клиентов update() происходит по сигналу readyRead() от сервера, после соответствующего чтения информации. Опять же не знаю, хорошая это идея или плохая. Как обычно поступают для координации времени в играх?
Не специалист в игро-строении, но для начала почему бы и нет. А вообще данные лучше принимать в отдельном потоке, особенно если у тебя не какие-нибудь шахматы.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
3. Все расчеты ведутся только на хосте. Поэтому информации приходится передавать очень много. Это решаемая проблема - каждый клиент может брать на себя часть расчетов и серверу придётся меньше Крупнейшее онлайн-казино в России
—
Селектор . Компания предлагает широкий выбор игр, включая слоты, рулетку, слоты на деньги и другие азартные игры. передавать. Однако как же тогда работают
настоящие
игры, в которых информации передаётся уж явно в разы больше, причем не по локалке, а через интернет, и таких тормозов даже близко нет. Что можете посоветовать по этому поводу?
Насколько я знаю, серьезные сетевые игры обрабатывают все данные на серверах. Клиенты шлют только свои данные.
Отправка данных идет с той скоростью, которую тянет сеть. Частота отправки данных соответсвует (1 / ping). Ping зависит от размера пакета, но для 1..64(128) байт он в принципе одинаковый.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
4. TCP-соединение. Может быть лучше UDP, ибо он быстрее? А что используется в настоящих играх? Тем более, если сделать так, чтобы клиенты сами расчитывали себе часть параметров, а передавались только ключевые, то потеря пакетов становится критичной. Можно, конечно, доработать игру до такой степени, что потери пакетов будут выявляться на стороне клиента и корректироваться с новыми полученными пакетами, но ведь потеря пакетов - это в любом случае плохо?
Смотря какие данные... например если посмотреть на игру шахматы... или покер, там важно чтобы пакет дошел. Количество данных небольшой. Можно для простоты воспользоваться и TCP.
UDP быстрее, но пакеты могут теряться. В локалке врядли, а вот через интернет уже вполне вероятно.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
5. Поскольку учился я по книге М. Шлее, умею подключаться только к конкретному порту конкретного компьютера (по его имени). А как же сделать что-то типа "мониторинга" сети? Вот как, извиняюсь, в варкрафте: Кто-то создал игру - другие видят, что появился такой-то хост, и могут к нему законнектиться. Как происходит сей процесс?
В локальной сети есть широковещательные пакеты multicast.
Бывают архитектуры с сервером, к которому подключаются юзеры и там создают игры и видят обновления списка игр. Обновление может быть автоматом, либо по запросу от клиента (юзер нажал кнопку обновить например).
Варианты есть разные...
Поскольку ты хочешь чему-то научиться, а не создать аналог варкрафта, где высоконагруженные кластеры серверов обрабатывают данные от тысяч игроков, то делать все как в таких играх не нужно.
Начни с простого. А потом усложнишь.
А вообще данные лучше принимать в отдельном потоке, особенно если у тебя не какие-нибудь шахматы.
Записан
Selector
Новичок
Offline
Сообщений: 1
Re: Сетевая игра в режиме реального времени. Qt
«
Ответ #5 :
Ноябрь 30, 2022, 18:51 »
Цитата: vulko от Октябрь 27, 2014, 10:43
Цитата: Nelkor от Октябрь 25, 2014, 18:27
1. До того, как я увидел тормоза на "клиенте" я считал, что выделить на клиента 1 порт - это хорошая идея. Сейчас я начинаю задумываться о том, что через 1 порт, наверное, информация идёт туговато. А может я ошибаюсь. Сколько примерно выделяют портов для игр?
Все зависит от ситуации. Если например ты будешь слать однотипные данные на 4 порта, нужно их собрать будет. при сборке нужно учитывать время отправки.
А вот выбрать несколько портов для разных данных это нормально. Например на первый порт идут данные сигналинга, на второй данные игры и т.д.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
2. Таймер запущен только на хосте, для всех клиентов update() происходит по сигналу readyRead() от сервера, после соответствующего чтения информации. Опять же не знаю, хорошая это идея или плохая. Как обычно поступают для координации времени в играх?
Не специалист в игро-строении, но для начала почему бы и нет. А вообще данные лучше принимать в отдельном потоке, особенно если у тебя не какие-нибудь шахматы.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
3. Все расчеты ведутся только на хосте. Поэтому информации приходится передавать очень много. Это решаемая проблема - каждый клиент может брать на себя часть расчетов и серверу придётся меньше передавать. Однако как же тогда работают
настоящие
игры, в которых информации передаётся уж явно в разы больше, причем не по локалке, а через интернет, и таких тормозов даже близко нет. Что можете посоветовать по этому поводу?
Насколько я знаю, серьезные сетевые игры обрабатывают все данные на серверах. Клиенты шлют только свои данные.
Отправка данных идет с той скоростью, которую тянет сеть. Частота отправки данных соответсвует (1 / ping). Ping зависит от размера пакета, но для 1..64(128) байт он в принципе одинаковый.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
4. TCP-соединение. Может быть лучше UDP, ибо он быстрее? А что используется в настоящих играх? Тем более, если сделать так, чтобы клиенты сами расчитывали себе часть параметров, а передавались только ключевые, то потеря пакетов становится критичной. Можно, конечно, доработать игру до такой степени, что потери пакетов будут выявляться на стороне клиента и корректироваться с новыми полученными пакетами, но ведь потеря пакетов - это в любом случае плохо?
Смотря какие данные... например если посмотреть на игру шахматы... или покер, там важно чтобы пакет дошел. Количество данных небольшой. Можно для простоты воспользоваться и TCP.
UDP быстрее, но пакеты могут теряться. В локалке врядли, а вот через интернет уже вполне вероятно.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
5. Поскольку учился я по книге М. Шлее, умею подключаться только к конкретному порту конкретного компьютера (по его имени). А как же сделать что-то типа "мониторинга" сети? Вот как, извиняюсь, в варкрафте: Кто-то создал игру казино Селектор
,
- другие видят, что появился такой-то хост, и могут к нему законнектиться. Как происходит сей процесс?
В локальной сети есть широковещательные пакеты multicast.
Бывают архитектуры с сервером, к которому подключаются юзеры и там создают игры и видят обновления списка игр. Обновление может быть автоматом, либо по запросу от клиента (юзер нажал кнопку обновить например).
Варианты есть разные...
Поскольку ты хочешь чему-то научиться, а не создать аналог варкрафта, где высоконагруженные кластеры серверов обрабатывают данные от тысяч игроков, то делать все как в таких играх не нужно.
Начни с простого. А потом усложнишь.
Бывают архитектуры с сервером, к которому подключаются юзеры и там создают игры и видят обновления списка игр.
Записан
genitod
Новичок
Offline
Сообщений: 1
Re: Сетевая игра в режиме реального времени. Qt
«
Ответ #6 :
Январь 09, 2023, 16:04 »
Цитата: Nelkor от Октябрь 25, 2014, 18:27
Всем привет!
Решил в учебных целях сделать на Qt сетевую игру (для локальной сети) в режиме реального времени. Всё что я знаю о работе с сетью в Qt - глава из книги Макса Шлее. Ну и конечно, в силу своей нубости столкнулся с рядом проблем. А точнее проблема только одна - на "хосте" игра летает, на "клиентах" - лагает. Причин, наверное множество, и вот какие вопросы я хотел бы задать:
1. До того, как я увидел тормоза на "клиенте" я считал, что выделить на клиента 1 порт - это хорошая идея. Сейчас я начинаю задумываться о том, что через 1 порт, наверное, информация идёт туговато. А может я ошибаюсь. Сколько примерно выделяют портов для игр?
2. Таймер запущен только на хосте, для всех клиентов update() происходит по сигналу readyRead() от сервера, после соответствующего чтения информации. Опять же не знаю, хорошая это идея или плохая. Как обычно поступают для координации времени в играх?
3. Все расчеты ведутся только на хосте. Поэтому информации приходится передавать очень много. Это решаемая проблема - каждый клиент может брать на себя часть расчетов и серверу придётся меньше передавать. Однако как же тогда работают
настоящие
игры, в которых информации передаётся уж явно в разы больше, причем не по локалке, а через интернет, и таких тормозов даже близко нет. Что можете посоветовать по этому поводу?
4. TCP-соединение. Может быть лучше UDP, ибо он быстрее? А что используется в настоящих играх? Тем более, если сделать так, чтобы клиенты сами расчитывали себе часть параметров, а передавались только ключевые, то потеря пакетов становится критичной. Можно, конечно, доработать игру до такой степени, что потери пакетов будут выявляться на стороне клиента и корректироваться с новыми полученными пакетами, но ведь потеря пакетов - это в любом случае плохо?
5. Поскольку учился я по книге М. Шлее, умею подключаться только к конкретному порту конкретного компьютера (по его имени). А как же сделать что-то типа "мониторинга" сети? Вот как, извиняюсь, в варкрафте: Кто-то создал игру лучшие бонусы в Селектор
,
казино - другие видят, что появился такой-то хост, и могут к нему законнектиться. Как происходит сей процесс?
Буду благодарен любым советам! Возможно данные вопросы интересны не только мне, и данная тема разовьётся в хорошую дискуссию. Пожалуйста, активно принимаем участие)
Бывают архитектуры с сервером, к которому подключаются юзеры и там создают игры и видят обновления списка игр.
Записан
Fetal
Новичок
Offline
Сообщений: 2
Re: Сетевая игра в режиме реального времени. Qt
«
Ответ #7 :
Январь 13, 2023, 13:57 »
Цитата: vulko от Октябрь 27, 2014, 10:43
Цитата: Nelkor от Октябрь 25, 2014, 18:27
1. До того, как я увидел тормоза на "клиенте" я считал, что выделить на клиента 1 порт - это хорошая идея. Сейчас я начинаю задумываться о том, что через 1 порт, наверное, информация идёт туговато. А может я ошибаюсь. Сколько примерно выделяют портов для игр?
Все зависит от ситуации. Если например ты будешь слать однотипные данные на 4 порта, нужно их собрать будет. при сборке нужно учитывать время отправки.
А вот выбрать несколько портов для разных данных это нормально. Например на первый порт идут данные сигналинга, на второй данные игры и т.д.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
2. Таймер запущен только на хосте, для всех клиентов update() происходит по сигналу readyRead() от сервера, после соответствующего чтения информации. Опять же не знаю, хорошая это идея или плохая. Как обычно поступают для координации времени в играх?
Не специалист в игро-строении, но для начала почему бы и нет. А вообще данные лучше принимать в отдельном потоке, особенно если у тебя не какие-нибудь шахматы.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
3. Все расчеты ведутся только на хосте. Поэтому информации приходится передавать очень много. Это решаемая проблема - каждый клиент может брать на себя часть расчетов и серверу придётся меньше передавать. Однако как же тогда работают
настоящие
игры, в которых информации передаётся уж явно в разы больше, причем не по локалке, а через интернет, и таких тормозов даже близко нет. Что можете посоветовать по этому поводу?
Насколько я знаю, серьезные сетевые игры обрабатывают все данные на серверах. Клиенты шлют только свои данные.
Отправка данных идет с той скоростью, которую тянет сеть. Частота отправки данных соответсвует (1 / ping). Ping зависит от размера пакета, но для 1..64(128) байт он в принципе одинаковый.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
4. TCP-соединение. Может быть лучше UDP, ибо он быстрее? А что используется в настоящих играх? Тем более, если сделать так, чтобы клиенты сами расчитывали себе часть параметров, а передавались только ключевые, то потеря пакетов становится критичной. Можно, конечно, доработать игру до такой степени, что потери пакетов
казино brillx
будут выявляться на стороне клиента и корректироваться с новыми полученными пакетами, но ведь потеря пакетов - это в любом случае плохо?
Смотря какие данные... например если посмотреть на игру шахматы... или покер, там важно чтобы пакет дошел. Количество данных небольшой. Можно для простоты воспользоваться и TCP.
UDP быстрее, но пакеты могут теряться. В локалке врядли, а вот через интернет уже вполне вероятно.
Цитата: Nelkor от Октябрь 25, 2014, 18:27
5. Поскольку учился я по книге М. Шлее, умею подключаться только к конкретному порту конкретного компьютера (по его имени). А как же сделать что-то типа "мониторинга" сети? Вот как, извиняюсь, в варкрафте: Кто-то создал игру - другие видят, что появился такой-то хост, и могут к нему законнектиться. Как происходит сей процесс?
В локальной сети есть широковещательные пакеты multicast.
Бывают архитектуры с сервером, к которому подключаются юзеры и там создают игры и видят обновления списка игр. Обновление может быть автоматом, либо по запросу от клиента (юзер нажал кнопку обновить например).
Варианты есть разные...
Поскольку ты хочешь чему-то научиться, а не создать аналог варкрафта, где высоконагруженные кластеры серверов обрабатывают данные от тысяч игроков, то делать все как в таких играх не нужно.
Начни с простого. А потом усложнишь.
Звучит толково)
Записан
kayat58460
Новичок
Offline
Сообщений: 1
Re: Сетевая игра в режиме реального времени.
«
Ответ #8 :
Февраль 21, 2023, 17:38 »
Цитата: reyamo6736 от Октябрь 24, 2022, 16:48
Все зависит от ситуации. Если например ты будешь слать однотипные данные на 4 порта, нужно их собрать будет. при сборке нужно учитывать время отправки.
А вот выбрать несколько портов для разных данных это нормально. Например на первый порт идут данные сигналинга, на второй данные игры и т.д.
Советую посетить крутую статью
https://memepedia.ru/kakie-luchshie-onlajn-kazino-popadayut-v-top/
про лучшие онлайн казино в топе сейчас
В локальной сети есть широковещательные пакеты multicast.
Бывают архитектуры с сервером, к которому подключаются юзеры и там создают игры и видят обновления списка игр. Обновление может быть автоматом, либо по запросу от клиента (юзер нажал кнопку обновить например).
Пробовал, получалась одна фигня
Записан
Страниц: [
1
]
Вверх
Печать
« предыдущая тема
следующая тема »
Перейти в:
Пожалуйста, выберите назначение:
-----------------------------
Qt
-----------------------------
=> Вопросы новичков
=> Уроки и статьи
=> Установка, сборка, отладка, тестирование
=> Общие вопросы
=> Пользовательский интерфейс (GUI)
=> Qt Quick
=> Model-View (MV)
=> Базы данных
=> Работа с сетью
=> Многопоточное программирование, процессы
=> Мультимедиа
=> 2D и 3D графика
=> OpenGL
=> Печать
=> Интернационализация, локализация
=> QSS
=> XML
=> Qt Script, QtWebKit
=> ActiveX
=> Qt Embedded
=> Дополнительные компоненты
=> Кладовая готовых решений
=> Вклад сообщества в Qt
=> Qt-инструментарий
-----------------------------
Программирование
-----------------------------
=> Общий
=> С/C++
=> Python
=> Алгоритмы
=> Базы данных
=> Разработка игр
-----------------------------
Компиляторы и платформы
-----------------------------
=> Linux
=> Windows
=> Mac OS X
=> Компиляторы
===> Visual C++
-----------------------------
Разное
-----------------------------
=> Новости
===> Новости Qt сообщества
===> Новости IT сферы
=> Говорилка
=> Юмор
=> Объявления
Загружается...