Приветствую Вас Гость
Регистрация | Вход
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]

Страница 1 из 3123»
Модератор форума: Bizunow, Romixal 
Форум » Вопросы и проблемы » Проблема - решение » Нужны предложения по оптимизации
Нужны предложения по оптимизации
XDominatorДата: Вторник, 05.06.2012, 23:52 | Сообщение # 1
Въезжает
Группа: Пользователи
Сообщений: 34
Статус: Offline
Проблема вот в чем. Прдеставлю такую сферическую ситуацию в вакууме, чтобы было понятно.

Есть сервер, есть 2 клиента.

В каждом из клиентов есть некий объект, который может перемещаться вверх и вниз, и они расположены с разных сторон экрана.

Эти объекты стреляют друг в друга строго по горизонтали.

Пусть у клиентов пинг до сервера 100 мс.

А суть вот в чем. Допустим, что стрельба рассчитывается в клиенте. Тогда получается, что второй клиент получает инфу о том что первый клиент совершил выстрел только через 200 мс(пинг до сервера + обратка до 2 клиента без учета времени обработки), что приводит к такой ситуации, что в клиенте стреляющего он попадает, а во 2-м клиенте - промахивается, т.к. игрок может к тому времени уже находиться выше\ниже возможных точек попадания.

Теперь допустим, что стрельба рассчитывается на сервере, то есть 1 клиент нажимает кнопку выстрела, на сервер идет запрос, и если возможно, то обоим клиентам отсылается инфа что первый клиент выстрелил, и собственно пули в окнах обоих клиентов появляются одновременно, но тогда появляется задержка между нажатием кнопки выстрела и собственно выстрелом, что конечно можно приписать к игре как фичу - подготовку выстрела, и вероятность промаха в одном клиенте и одновременного попадания в другом уменьшается в 2 раза(думаю понятно почему).

Я реализовал 2 метод, но заметил что такая проблема в моем жанре все равно может стоять крайне остро. Увеличение размеров моделек конечно сделает проблему еще менее заметной, но все равно она останется, т.к. сильно увеличивать их я не могу. Что же выходит, единственный выход в том, чтобы все патроны заносить в массивы, рассчитывать попадания на сервере, и принудительно попавшие на сервере патроны уничтожать в клиентах? Это может очень отрицательно повлиять на производительность игры, что в моем случае нежелательно. Жду предложений
 
agentx001Дата: Среда, 06.06.2012, 00:53 | Сообщение # 2
Генерал-майор
Группа: Пользователи
Сообщений: 309
Статус: Offline
XDominator, делать по второму методу, но в выстрелившом клиенте создавать пулю после выстрела. Ну и как вариаант, я его использую, у того которому инфа о выстреле пришла делать скорость пули выше:))
 
XDominatorДата: Среда, 06.06.2012, 02:29 | Сообщение # 3
Въезжает
Группа: Пользователи
Сообщений: 34
Статус: Offline
Не совсем понял первую часть предложения, а вот про скорость хорошая мысль,кстати)))Просто если в выстрелевшем клиенте создавать пулю сразу, то это первый способ)
 
VinchensooДата: Среда, 06.06.2012, 11:48 | Сообщение # 4
Генерал-майор
Группа: Проверенные
Сообщений: 390
Статус: Offline
Дочитал до "стрельба рассчитывается в клиенте", дальше не читал.

Подобные извраты с созданием объектов на сервере, вынесением логики в клиент всегда доставляли.
Помниться, кто-то стебался на тесте Век Бивней, расставляя себе в клиенте порталы где попало.

У вас и так не очень хорошая ситуация со скорость исполнения кода сервера, а вы еще вешаете всякую хрень на него, типа объектов и определения их коллизий через функции ГМ.

Все это нужно делать мозгом и руками, иначе потеряете даже ту минимальную производительность, которую можно попытаться еще достичь на гм.

Сервер должен представлять из себя пустое рабочее окно и ничего более.





Сообщение отредактировал Vinchensoo - Среда, 06.06.2012, 15:26
 
XDominatorДата: Среда, 06.06.2012, 20:58 | Сообщение # 5
Въезжает
Группа: Пользователи
Сообщений: 34
Статус: Offline
Без проверок на сервере, очень легко вмешаться в игру даже с помощью банального ArtMoney... чего понятное дело нужно избежать. Конечно можно искусственно создавать задержку в стреляющем клиенте, а на сервере проверять только лишь возможно ли стрелять в данный момент(откатился ли скилл и пр.), но тогда вопрос - по какому клиенту проверять коллизии? даже при таком подходе, обязательно будет разброс на +-, и необходимо сгладить именно его. Кстати о производительности сервера - лично у меня он на пике, ест не больше 4% цп на 1 окно. Так как кроме меня он все равно ни у кого не будет запускаться, то вопрос производительности меня не волнует, потому что ресурсов более чем достаточно А вот как раз производительность клиента - это проблема довольно насущная. Конечно большинство проверок стараюсь осуществить в клиенте но все таки на сервере необходимо контролировать всяческие безобразия, чтобы игроки не могли вмешаться в откаты\скорости\координаты или мухлевали с принадлежностью к команде. Это важно. Как и попадания.
 
VinchensooДата: Среда, 06.06.2012, 21:32 | Сообщение # 6
Генерал-майор
Группа: Проверенные
Сообщений: 390
Статус: Offline
Ты даже не пытался понять, что я написал. Печально.


 
QvantДата: Четверг, 07.06.2012, 22:43 | Сообщение # 7
Въехавший
Группа: Проверенные
Сообщений: 64
Статус: Offline
Quote (Vinchensoo)
Помниться, кто-то стебался на тесте Век Бивней, расставляя себе в клиенте порталы где попало.

Ага , кроме порталов я далал ещё бесконечный шмот
Причём , так как расчитывалось всё в клиенте - то на сервере это вообще никак нельзя было отследить !

используй вместо TCP - протокол UDP , пинг будит раза в 3 меньше и заметно не будит ... а пара потереных пакетов с пульками в игре будит незаметно
 
agentx001Дата: Суббота, 09.06.2012, 02:14 | Сообщение # 8
Генерал-майор
Группа: Пользователи
Сообщений: 309
Статус: Offline
Quote (Qvant)
используй вместо TCP - протокол UDP

Сейчас сбегутся Зик с Винчём и начнуть стебаться, дескать в современных каналах TCP на равне с UDP, и т. д. и т. п.
 
XDominatorДата: Суббота, 09.06.2012, 10:04 | Сообщение # 9
Въезжает
Группа: Пользователи
Сообщений: 34
Статус: Offline
А реализовать 2 типа подключения в 1 клиенте возможно?Передавать информацию которая идет постоянно, например, координаты, направление, можно и через UDP было бы, а то что идет отдельными разовыми пакетами, которые терять нельзя - через ТСП.
 
VinchensooДата: Суббота, 09.06.2012, 15:10 | Сообщение # 10
Генерал-майор
Группа: Проверенные
Сообщений: 390
Статус: Offline
Quote (agentx001)
Сейчас сбегутся Зик с Винчём и начнуть стебаться, дескать в современных каналах TCP наогромныйжирныйпробелравне с UDP, и т. д. и т. п.

Раз меня объявили жирным троллем, то я буду еще и к орфографии цепляться.
Quote (XDominator)
А реализовать 2 типа подключения в 1 клиенте возможно?Передавать информацию которая идет постоянно, например, координаты, направление, можно и через UDP было бы, а то что идет отдельными разовыми пакетами, которые терять нельзя - через ТСП.

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

Имхо, снова геммор, писать сервер на гм и использовать UDP- гениТально)





Сообщение отредактировал Vinchensoo - Суббота, 09.06.2012, 15:11
 
agentx001Дата: Суббота, 09.06.2012, 16:05 | Сообщение # 11
Генерал-майор
Группа: Пользователи
Сообщений: 309
Статус: Offline
Quote (Vinchensoo)
Имхо, снова геммор, писать сервер на гм и использовать UDP- гениТально)

Так то да, если запариватся с UDP, то нужно бы на делфи, и дин. программирование неплохо бы знать
 
VinchensooДата: Суббота, 09.06.2012, 16:19 | Сообщение # 12
Генерал-майор
Группа: Проверенные
Сообщений: 390
Статус: Offline
Quote (agentx001)
дин. программирование

Что это такое?
К тебе привязывают динамо-машину, ты бегаешь по колесу, которое прикреплено к машине, тебя бьет током и ты при этом программируешь?
Quote (agentx001)
то нужно бы на делфи

Если делать однопоточный сервер- смысла не сильно много.

На гм проще заменить потоки процессами, либо гм сам разносит некоторые вещи в разные потоки, но у юзверя способности управлять потоками нет.



 
agentx001Дата: Суббота, 09.06.2012, 18:12 | Сообщение # 13
Генерал-майор
Группа: Пользователи
Сообщений: 309
Статус: Offline
Vinchensoo, за что ты так не любишь делфина? Грамотно оптимизируя и используя динамические массивы можно добится нехилого прироста в производительности. Ну а многопоточность - бред.
 
VinchensooДата: Суббота, 09.06.2012, 19:36 | Сообщение # 14
Генерал-майор
Группа: Проверенные
Сообщений: 390
Статус: Offline
Quote (agentx001)
Vinchensoo, за что ты так не любишь делфина? Грамотно оптимизируя и используя динамические массивы можно добится нехилого прироста в производительности.

По сравнению с гм?
Ты хотя бы понимаешь, как работает ОС, распределяя между процессами и потоками процессорное время?
Грубо говоря, если у тебя запущен однопоточный сервер на серверной машине, на которой, скажем, 6 ядер, то 5 ядер будут тупо стоять, все будет жеваться на одном ядре.
А если у тебя онлайн 1000 человек?

Вы, вроде как, используете цикл, пробегая массив всех сокетов. Если получилось так, что сообщение для 999-го сокета пришло в тот момент, когда мы проверяем 0-й? То мы проверяем 999 сокетов, причем, возможно, в них тоже есть сообщения и нам придется что-то обработать и отослать ответ.
Среднее время обработки запроса- ну возьмем 7 мс, хотя смотря какой запрос.

Пусть вышло так, что 25% активных игроков стуканулись в этот момент на сервер(и эта цифра, имхо, занижена, особенно для Экшн игры, типа шутера).
Что мы имеем:
250* 7 = 1750 мс.
Это время, которое пройдет ТОЛЬКО до того момента, когда мы примем запрос нашего игрока. Плюс на обработку 7 мс и отсылку их.
Итого, пинг в критической ситуации получается 1750 мс.

Человеку требуется пинг в 100 мс и ниже. Причем, если учтем, что у нас Экшн игра и координаты передаются, скажем, каждые 50 мс, то мы получаем куда более высокую нагрузку, умножь это число на 4 или 5.

В общем, даже такой грубый рассчет показывает, что твоему серверу пришел капец за 0.1 секунды при нагрузке в 1000 человек.

Пойдем дальше, посчитаем, а сколько такой сервер может в теории выдержать человек.

Пусть n- критическая нагрузка.
За критический пинг возьмем 100 мс.
Считает, что обновление координат для игры происходит раз в 50 мс. Т.к. 20 раз за секунду.

Пусть случай критический, и произошло так, что в один момент времени все клиенты кинули запрос на обновление.

Время обновления координаты, возьмем 2 мс.

Итого:
2*n= 100- 2 - время на доставку. Время на доставку, возьмем 20 мс. Итого, n= 39 человек.

Стоит писать ММО шутер на 39 человек? Не думаю.

К чему была взята цифра обновления координат раз в 50 мс?
Тут все просто:

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

Если 51 игрок, то в любом случае, в любой момент времени будет 2 игрока, которые "долбятся" на сервер с желанием обновить координаты всех и вся.
И т.д. и т.п., дальше занимайся рассчетами сам, мне лениво.

Quote (agentx001)
Ну а многопоточность - бред.

Из изложенного выше- сам ты бред.

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

Многопоточное приложение весьма сложно написать и отладить, перво-наперво встает вопрос архитектуры, которую нужно продумать очень хорошо. Критический просчет в архитектуре приведет к необходимости переписывать сервер заного.

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





Сообщение отредактировал Vinchensoo - Суббота, 09.06.2012, 19:42
 
QvantДата: Воскресенье, 10.06.2012, 00:07 | Сообщение # 15
Въехавший
Группа: Проверенные
Сообщений: 64
Статус: Offline
Quote (agentx001)
Сейчас сбегутся Зик с Винчём и начнуть стебаться, дескать в современных каналах TCP на равне с UDP, и т. д. и т. п.

В TCP идёт сначала запрос на передачу пакета , если ответ пришёл , тогда передаётся сам пакет и по окончании передаётся ещё и ответ что пакет дошёл ... в UDP сразу посылается пакет - никаких подтверждений нет .
Поэтому если пакет маленький , то скорость UDP больше TCP Почти в 3 раза!
Если пакеты большие и скорость канала низкая то выйгрыш в скорости конечно меньше , но он есть.

Quote (Vinchensoo)
Имхо, снова геммор, писать сервер на гм и использовать UDP- гениТально)

Вообщето я не призывал писать сервер на ГМ
Сервер нужно писать на компилированном ЯП - это вообще без вариантов.

Quote (agentx001)
Ну а многопоточность - бред.

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

Quote (Vinchensoo)
Многопоточное приложение весьма сложно написать и отладить, перво-наперво встает вопрос архитектуры, которую нужно продумать очень хорошо. Критический просчет в архитектуре приведет к необходимости переписывать сервер заного.

Да ну ? Чего там сложного ?
На сервере создаётся необхое количество потоков для клиентов и он работает в качестве слушателя.
Клиенты присоединяются к нему - сервер ищет свободный поток и отсылает id клиенту.
Клиент присоединятся к этому потоку по этому id.
А дальше каждый клиент обрабатывается независимо от остальных в асинхронном режиме .
Всё...
 
Форум » Вопросы и проблемы » Проблема - решение » Нужны предложения по оптимизации
Страница 1 из 3123»
Поиск:
Хостинг от uCoz