1. До того, как я увидел тормоза на "клиенте" я считал, что выделить на клиента 1 порт - это хорошая идея. Сейчас я начинаю задумываться о том, что через 1 порт, наверное, информация идёт туговато. А может я ошибаюсь. Сколько примерно выделяют портов для игр?
Все зависит от ситуации. Если например ты будешь слать однотипные данные на 4 порта, нужно их собрать будет. при сборке нужно учитывать время отправки.
А вот выбрать несколько портов для разных данных это нормально. Например на первый порт идут данные сигналинга, на второй данные игры и т.д.
2. Таймер запущен только на хосте, для всех клиентов update() происходит по сигналу readyRead() от сервера, после соответствующего чтения информации. Опять же не знаю, хорошая это идея или плохая. Как обычно поступают для координации времени в играх?
Не специалист в игро-строении, но для начала почему бы и нет. А вообще данные лучше принимать в отдельном потоке, особенно если у тебя не какие-нибудь шахматы.
3. Все расчеты ведутся только на хосте. Поэтому информации приходится передавать очень много. Это решаемая проблема - каждый клиент может брать на себя часть расчетов и серверу придётся меньше передавать. Однако как же тогда работают настоящие игры, в которых информации передаётся уж явно в разы больше, причем не по локалке, а через интернет, и таких тормозов даже близко нет. Что можете посоветовать по этому поводу?
Насколько я знаю, серьезные сетевые игры обрабатывают все данные на серверах. Клиенты шлют только свои данные.
Отправка данных идет с той скоростью, которую тянет сеть. Частота отправки данных соответсвует (1 / ping). Ping зависит от размера пакета, но для 1..64(128) байт он в принципе одинаковый.
4. TCP-соединение. Может быть лучше UDP, ибо он быстрее? А что используется в настоящих играх? Тем более, если сделать так, чтобы клиенты сами расчитывали себе часть параметров, а передавались только ключевые, то потеря пакетов становится критичной. Можно, конечно, доработать игру до такой степени, что потери пакетов
казино brillx будут выявляться на стороне клиента и корректироваться с новыми полученными пакетами, но ведь потеря пакетов - это в любом случае плохо?
Смотря какие данные... например если посмотреть на игру шахматы... или покер, там важно чтобы пакет дошел. Количество данных небольшой. Можно для простоты воспользоваться и TCP.
UDP быстрее, но пакеты могут теряться. В локалке врядли, а вот через интернет уже вполне вероятно.
5. Поскольку учился я по книге М. Шлее, умею подключаться только к конкретному порту конкретного компьютера (по его имени). А как же сделать что-то типа "мониторинга" сети? Вот как, извиняюсь, в варкрафте: Кто-то создал игру - другие видят, что появился такой-то хост, и могут к нему законнектиться. Как происходит сей процесс?
В локальной сети есть широковещательные пакеты multicast.
Бывают архитектуры с сервером, к которому подключаются юзеры и там создают игры и видят обновления списка игр. Обновление может быть автоматом, либо по запросу от клиента (юзер нажал кнопку обновить например).
Варианты есть разные...
Поскольку ты хочешь чему-то научиться, а не создать аналог варкрафта, где высоконагруженные кластеры серверов обрабатывают данные от тысяч игроков, то делать все как в таких играх не нужно.
Начни с простого. А потом усложнишь.
Просмотр сообщений
