ВНИМАНИЕ!
Наша конференция посвящена космической тематике и компьютерным играм.
Политические вопросы и происходящие в мире события в данный момент на нашем сайте не обсуждаются!
|
| » Solarwind | страница 2 |
|
|
|
|
Канал Игры Мечты: «Solarwind» |
|
|
|
Sh.Tac.
 151 EGP
 
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
  |
|
| Jurec : |
|
Прям вот так все за мультиплеер?
|
там вроде нет ничего сложного, единственное клиентская часть на шарпе, и тут либо
1. игровой сервер тоже на шарпе (и какой-нить lidgren)
2. городить огород
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Jurec
348 EGP
 
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
 |
|
| Sh.Tac. : |
|
там вроде нет ничего сложного
|
много сетевых игр сделал? если не учитывать сеть в начале - потом её не встроить без переписывания всей игровой логики
_________________
MOV topka, C++ |
|
|
|
БулерМэн
420 EGP
Рейтинг канала: 2(21)
Репутация: 68
Сообщения: 1580
Откуда: Гороховец
Зарегистрирован: 07.02.2006
|
|
| Jurec : |
|
потом её не встроить без переписывания всей игровой логики
|
Вопрос на мой взгляд - спорный.
Если позволить игроку менять все - а сервер выступает в роли посредника между клиентами и не несет контент/локации - то все перепиливание кода упирается в отслеживании инициализации/уничтожения игровых объектов, передачи состояний этих объектов при возникновении события у объектов. То есть я бы не сказал, что это суперсложная задача.
А вот если хочется сервер, на котором запущена вселенная, и все игровые объекты создаются на сервере, а клиентам отправляются данные о состоянии родительских, серверных объектах - то это сложнее, вот тут огород, таки да.
Просто так летит кораблик, бац, в него попадает ракета - на уровне сетевого обмена это мешанинка, хотя опять таки, если клиент видит только результат взаимодействия объектов на сервере - то это несколько упрощает задачу.
добавлено спустя 3 минуты:
ЗЫ то есть для написания сетевой версии игры - будет достаточно прикрутить к существующей игре - возможность отправлять и принимать состояния объектов. На сервере можно отбросить графику, если только она не участвует в проверке столкновений, что маловероятно, раз ты говоришь, что у тебя 3d.
добавлено спустя 1 минуту:
ЗЫЫ Вообще да, не все так просто 
Последний раз редактировалось: БулерМэн (13:51 27-04-2016), всего редактировалось 2 раз(а) |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
| БулерМэн : |
|
Если позволить игроку менять все - а сервер выступает в роли посредника между клиентами и не несет контент/локации - то все перепиливание кода упирается в отслеживании инициализации/уничтожения игровых объектов, передачи состояний этих объектов при возникновении события у объектов. То есть я бы не сказал, что это суперсложная задача.
|
Гугли lag compensation. Читай http://www.gabrielgambetta.com/fpm3.html
_________________
MOV topka, C++ |
|
|
|
Kann
64 EGP
Рейтинг канала: 3(45)
Репутация: 7
Сообщения: 232
Откуда: Москва
Зарегистрирован: 11.04.2008
|
|
У вас же вроде поинт-клик управление ?
тогда причем тут лагокомпенсация ?
|
|
|
|
БулерМэн
420 EGP
Рейтинг канала: 2(21)
Репутация: 68
Сообщения: 1580
Откуда: Гороховец
Зарегистрирован: 07.02.2006
|
|
Очевидные вещи написаны. Лично я делаю так: сервер - это полновесная игра со всей физикой и математикой, кроме графики, т.к. она там не нужна, да и не может быть, из-за ограничений.
Клиент - движок с прикрученной логикой передачи/приема данных о состоянии объектов.
Следует уточнить, что в моем прототипе игры - одна вселенная или если хотите - одна локация, но бесконечно большая.
Количество игроков в данный момент ограничено 30-ю.
Серверный цикл проверяет наличие поступивших сообщений от игроков. Это позволяет одномоментно изменить все параметры игры для всех игроков, если один из них нажал ВЛЕВО, другой ВПРАВО, а третий стоит на месте. Для всех трех придет ответ о конечном состоянии всей сцены в окрестности игрока.
То есть, на стороне сервера объект уже знает, в пределах какого радиуса вокруг него проверять наличие других объектов, чтобы послать игроку пакет с данными о положении появившегося объекта.
Следовательно, как только объект покидает поле зрения игрока - сервер посылает команду клиенту - уничтожить экземпляр объекта на стороне клиента.
Казалось бы, а что если использовать очереди? Получится, что один шаг сервера это одно действие игрока, то есть цикл проверки входящих значений заменяем циклом работы сервера.
Скажу я так - это геморрой. Три довольно серьезных программы сделал с таким циклом, не советую. Как минимум в плане реализации. Скорости это не прибавит, а вот мучений - гарантированно, и потом не разберешь, откуда ноги растут.
Да, "размазанный цикл" по циклу сервера позволяет показывать процесс работы, отправлять данные по ходу дела, но на скорости работы системы клиент-сервер это в общем не отразится. Если клиенты тормозят на текущей скорости - они так же будут тормозить.
Второй вопрос - сглаживание движения: да, движение объектов задается не передачей ленты UDP-пакетов с текущими координатами объекта игрока, а только изменение состояния - скорости, клавиши.
А вот столкновения - обрабатываются на стороне сервера. Летит корабль, например с постоянной скоростью, при этом игрок управляет "призраком" объекта, который движется в космическом пространстве на сервере. Игрок нажимает клавишу ОГОНЬ, отправляется пакет, временной лаг №1 - пока дойдет команда огонь до управляемого корабля.
Сервер получив команду - "стреляет" кораблем игрока.
Если говорить об энергетическом оружии - то ответ о попадении в другой объект, если он находится в радиусе видимости игрока и в радиусе убойности оружия - приходит сразу. Временной лаг №2.
Если запускается ракета, то сервер создает объект "ракета" и отправляет команду "создать ракету" на стороне клиента. Ракета будет двигаться по той же траектории, что и на сервере, т.к. будет видна игроку. Как только игрок не видит ракету - сервер не посылает данные о положении существующей сейчас ракеты, но ракета продолжает двигаться на стороне сервера, и в конечном счете догоняет противника.
Противник, видит приближение ракеты на радаре, если его радар настроен на прием данных в указанном радиусе. То есть сервер ему уже отправляет данные об изменении траектории ракеты и фактически в клиентском приложении уже создан экземпляр объекта "ракета". Почему это возможно: игрок изменяя радиус дальнобойности своего радара - посылает данные о выбранном масштабе - на сервер, а сервер в свою очередь - проверяет вокруг истинного объекта игрока - наличие других объектов.
Из этого можно сделать вывод - что чем больше объектов в пределах видимости игрока тем больше нагрузка на сервер.
Суммарная нагрузка на сервер тем выше чем дальше друг от друга будут игроки и чем больше будет масштаб выбранный игроками.
Как вариант - запретить игроку изменять масштаб до галактических масштабов. Еще вариант - уменьшать масштаб при увеличении нагрузки на сервер.
На счет плавных движений объектов: допустим у игрока тормозит сеть и появляется задержка 300 мс, за это время игрок думает, что он повернул в сторону от астероида, а через 300мс приходит состояние о том, что он уже врезался в скалу.
Почему вариант с показом игрока "в прошлом" не подходит - дело в том, что игрок и так получает данные "из прошлого", с задержкой 300мс.
Как вариант решения данной проблемы - это ряд мер: определение средней скорости соединения - позволит клиенту отправлять на сервер контрольные пакеты через указанный промежуток времени, и если пакеты пришли позднее/раньше - определить скорость соединения, обновить запись таймаута для текущего игрока на стороне сервера.
То есть если контрольный пакет пришел позднее - снизить тягу корабля пропорционально увеличению временного лага. Тогда игрок у себя в клиенте уворачивается от астероида - на самом деле - он до него даже не долетел еще, но уже уворачивается, но медленно. В итоге - игрока отбрасывает назад в пространстве.
добавлено спустя 8 минут:
ЗЫ у меня прототип не поинт-клик-шутер, а скорее TDS с реальным управлением клавишами. Это в свою очередь влияет на выбор стратегии обработки данных сервером.
Но на мой взгляд ничего не мешает применить тот же алгоритм и для вашей игры.
Последний раз редактировалось: БулерМэн (17:26 27-04-2016), всего редактировалось 3 раз(а) |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Kann : |
|
причем тут лагокомпенсация?
|
лагокомпенсация для стрельбы же
чтобы чувак из будущего попадал по чувакам из прошлого
есть простой способ не делать откаты на сервере, собсно я уже написал 
если клиент к своему синхронизированному времени прибавляет условно пинг, то посылка дойдёт как раз вовремя
| Jurec : |
|
много сетевых игр сделал?
|
ни одна не выжила
| Цитата: |
|
если не учитывать сеть в начале
|
это да, и писать приходится в два раза больше
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Guest
2075 EGP
         
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
| Jurec : |
|
Прям вот так все за мультиплеер? Хм.. надо подумать
|
Ну ви таки
| Jurec : |
|
Что думаете? Нужны идеи
|
Вот ми и.
_________________
Трещит земля как пустой орех
Как щепка трещит броня |
|
|
|
Kann
64 EGP
Рейтинг канала: 3(45)
Репутация: 7
Сообщения: 232
Откуда: Москва
Зарегистрирован: 11.04.2008
|
|
| Sh.Tac. : |
| Kann : |
|
причем тут лагокомпенсация?
|
лагокомпенсация для стрельбы же
чтобы чувак из будущего попадал по чувакам из прошлого
есть простой способ не делать откаты на сервере, собсно я уже написал
если клиент к своему синхронизированному времени прибавляет условно пинг, то посылка дойдёт как раз вовремя
|
Стрелять надо на сервере, а не на клиенте, и не каких чуваков из будущего не будет
Клиент должен только нарисовать эффект стрельбы а не физически стрелять.
Тут же поинт-клик, не прямое управление, а значит концепция КС тут не нужна.
Так же как и реальный просчет попаданий физикой, стреляем на сервере, считаем нужный процент попадания в зависимости от хотелок геймдизайнера, или же как в еве, учитывая разные факторы, вроде скорости поворота пушек и т.д
На клиенте рисуем красивый выстрел, и попадание, все, все довольны.
И лагокомпенсация не нужна, делаем аналог сетевого RTS, посылаем не текущие координаты объекта, а команду, например лететь туда куда тыркнул мышкой, считаем время прохода пакетов по сети, делаем задержку на N миллисекунд и одновременно стартуем, на клиенте и сервере, далее раз в N секунд сверяем координаты.
Либо реализуем механизм жесткой синхронизации lockstep, и что бы не трахатся с детерминированными вычислениями, так же раз в N секунд сверяем координаты
Последний раз редактировалось: Kann (10:48 28-04-2016), всего редактировалось 1 раз |
|
|
|
Cooler
290 EGP
  
Репутация: 7
Сообщения: 1668
Откуда: OEG
Зарегистрирован: 24.02.2009
|
|
| Kann : |
|
попаданий физикой, стреляем на сервере, считаем нужный процент попадания в зависимости от хотелок геймдизайнера
|
Мсье явно не понимает в чём разница между физическим просчетом и RNG
_________________
Practice makes perfect.
Последний раз редактировалось: Cooler (11:15 28-04-2016), всего редактировалось 1 раз |
|
|
|
Kann
64 EGP
Рейтинг канала: 3(45)
Репутация: 7
Сообщения: 232
Откуда: Москва
Зарегистрирован: 11.04.2008
|
|
| Cooler : |
| Kann : |
|
попаданий физикой, стреляем на сервере, считаем нужный процент попадания в зависимости от хотелок геймдизайнера
|
Мсье явно не понимает разницу между физическим просчетом и RNG
|
Ну да, в поинт клик это особенно нужно, как собаке 5я нога
|
|
|
|
Cooler
290 EGP
Репутация: 7
Сообщения: 1668
Откуда: OEG
Зарегистрирован: 24.02.2009
|
|
Угу. А потом получаем, что линейный крейсер попадает по стоящему на месте (!) истребителю 1 из 20 раз всего лишь потому что дизигнер так захотел.
| Kann : |
|
Тут реальные задачи вроде как обсуждают, а не хотелки игроков
|
Ну-ну. Кто-то тут ранее писал про "должен". В добавок полное игнорирование написанного мной. Удачи.
_________________
Practice makes perfect.
Последний раз редактировалось: Cooler (11:29 28-04-2016), всего редактировалось 1 раз |
|
|
|
Kann
64 EGP
Рейтинг канала: 3(45)
Репутация: 7
Сообщения: 232
Откуда: Москва
Зарегистрирован: 11.04.2008
|
|
| Cooler : |
|
Угу. А потом получаем, что линейный крейсер попадает по стоящему на месте (!) истребителю 1 из 20 раз всего лишь потому что дизигнер так захотел.
|
Тут реальные задачи вроде как обсуждают, а не хотелки игроков
Хотя если это очередной топик для "мечтателей" тогда да, я оказался не прав, и умываю руки, куда уж мне, с своими советами
|
|
|
|
БулерМэн
420 EGP
Рейтинг канала: 2(21)
Репутация: 68
Сообщения: 1580
Откуда: Гороховец
Зарегистрирован: 07.02.2006
|
|
Вы еще подеритесь, горячие финские парни (с)
|
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
| Kann : |
Стрелять надо на сервере, а не на клиенте, и не каких чуваков из будущего не будет
Клиент должен только нарисовать эффект стрельбы а не физически стрелять.
|
Это адский ад будет. При приличном пинге можно просто клавиатуру засунуть в монитор по самый энтер. Ну серьезно - ты отдаешь команду, а у тебя корабли начинают движение через пинг * 2. Так никто и никогда не делал и не делает - это не играбельно. И еще один момент - я точно не буду делать сервер/клиент. Я буду юзать photon. Где клиенты есть и есть мастер-клиент.
| Kann : |
|
Так же как и реальный просчет попаданий физикой, стреляем на сервере, считаем нужный процент попадания в зависимости от хотелок геймдизайнера
|
Не, спасибо. Это будет совсем другая игра
добавлено спустя 2 минуты:
| Kann : |
И лагокомпенсация не нужна, делаем аналог сетевого RTS, посылаем не текущие координаты объекта, а команду, например лететь туда куда тыркнул мышкой, считаем время прохода пакетов по сети, делаем задержку на N миллисекунд и одновременно стартуем, на клиенте и сервере, далее раз в N секунд сверяем координаты.
Либо реализуем механизм жесткой синхронизации lockstep, и что бы не трахатся с детерминированными вычислениями, так же раз в N секунд сверяем координаты
|
Ну ок, вот сверил я - результат разный потому что погрешности float. И?
_________________
MOV topka, C++
Последний раз редактировалось: Jurec (17:22 28-04-2016), всего редактировалось 1 раз |
|
|
|
Kann
64 EGP
Рейтинг канала: 3(45)
Репутация: 7
Сообщения: 232
Откуда: Москва
Зарегистрирован: 11.04.2008
|
|
| Jurec : |
|
Так никто и никогда не делал и не делает - это не играбельно.
|
У вас что пинг больше 500мс ? кто вообще в такое будет играть с таким пингом ?
а все остальное не существенно, если вы только не участник киберспортивных команд, но там не кто не играет по "интернету"
Ну и близарды другого мнения, как и создатели остальных 100500 стратегий
Чето все играют, и не пыхтят, когда начало движения юнитов запаздывает от момента клика до начала движения.
И будете вы юзать фотон или еще чето, как то не играет роли, я юзаю стандартный Unet, с той же сетевой моделью, и это не сколько не запрещает сделать просчет стрельбы на мастер-клиенте а не у каждого клиента отдельно
| Jurec : |
|
Не, спасибо. Это будет совсем другая игра
|
Ваше дело, если считаете что у вас достаточно сил и средств на реализацию полноценной сетевой физики, то только порадуюсь если что то выйдет.
| Jurec : |
|
Ну ок, вот сверил я - результат разный потому что погрешности float. И?
|
И просто лерпите до исходного состояния синхронизируя с владельцем объекта, накопленная разница крайне мала что бы реально на что то влиять
Последний раз редактировалось: Kann (19:01 28-04-2016), всего редактировалось 1 раз |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Jurec : |
|
буду юзать photon
|
я "ниасилил" в своё время там ничего нет, просто комната, никакой синхронизации, всё надо делать самому, и даже сериализацию тож лучче свою, потому как "искаропки" тока передача словарей, и по-моему достаточно громоздким способом
_________________
This is what you get ...
(c) Radiohead |
|
|
|
БулерМэн
420 EGP
Рейтинг канала: 2(21)
Репутация: 68
Сообщения: 1580
Откуда: Гороховец
Зарегистрирован: 07.02.2006
|
|
| Jurec : |
|
результат разный потому что погрешности float. И?
|
и что мешает заменить координаты объекта на те, что получены с сервера?
Ну ладно, для полноты счастья можно вместо замены координат - направлять объект в сторону точных координат с определенной скоростью. Это определенно сгладит рывки, но физика этого будет просто изумительная: объекты будут двигаться по неестественным траекториям, и это будет запутывать еще сильнее чем рывки.
добавлено спустя 6 минут:
По крайней мере рывки будут говорить о малом лаге для самого игрока, и он сможет как-то подстроится под ситуацию, в отличии от ситуации, когда этого лага не видно.
Есть еще пример, как реализовано в одной онлайн-игре: при очень большом лаге - на клиенте пропадают другие игроки и динамические объекты. То есть игрок как будто бы выпал в вакуум. Статика вроде бы есть, локация прописанная в клиенте никак не изменилась, он сам двигается куда хочет, но враги пропали с радаров. А это значит, что связь с сервером временно потеряна и тебя как юнит скорее всего уже подстрелили, и это воспринимается нормально.
Последний раз редактировалось: БулерМэн (22:26 28-04-2016), всего редактировалось 1 раз |
|
|
|
|
|
|
|
|
Канал Игры Мечты: «Solarwind» |
|
|
|
