Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Свободные библиотеки для сетевых реалтайм-игр. Кто использовал? (4 стр)

Свободные библиотеки для сетевых реалтайм-игр. Кто использовал? (4 стр)

Страницы: 13 4 5 611 Следующая »
gamedeveloper01Постоялецwww19 мая 201818:44#45
Odin_KG
> лагокомпенсация
Очевидно имеется ввиду чтобы движения игрока были плавными, а не прерывистыми из-за пинга.
DelfigamerПостоялецwww19 мая 201819:04#46
Odin_KG
> Это я не знаю, что означает. TCP, в теории, должен пакеты доставлять
> гарантированно, а UDP - нет.
Lag compensaion - это когда клиент не ждёт, пока пакет доплетётся до сервера и вернётся обратно, а начинает двигать локальную куклу сразу в ответ на нажатие кнопки; а сервер, в свою очередь, в своих расчётах специально учитывает тот факт, что пришедшее ему сообщение о выстреле относится не к тому, где куклы находятся сейчас, а к тому, где конкретный клиент их видел полчаса назад. С дополнительным учётом того, что то, что клиенту пришло полчаса назад - было отправлено с сервера почти час тому назад.
Odin_KGПостоялецwww19 мая 201819:13#47
gamedeveloper01
Delfigamer
Я так и подумал, что тут это имеется в виду. Но мне казалось, что это нужно своими ручками на UDP делать, а не ждать такое поведение от универсальных сетевых библиотек.
DelfigamerПостоялецwww19 мая 201819:16#48
gamedeveloper01
> Очевидно имеется ввиду чтобы движения игрока были плавными, а не прерывистыми
> из-за пинга.
Это только одна из огромного множества техник.
В принципе, лагокомпенсация - это любое отступление от схемы "клиент послал команду - сервер принял, подумал, послал ответ - клиент принял и показал на экране". Причём интерполяция - это даже далеко не самое сложное.
Вот компенсация оружия, например - вот это действительно интересная тема.
Odin_KGПостоялецwww19 мая 201820:29#49
Delfigamer
> В принципе, лагокомпенсация - это любое отступление от схемы "клиент послал
> команду - сервер принял, подумал, послал ответ - клиент принял и показал на
> экране".
Это понятно. Но мне непонятно, как это можно требовать от универсальной библиотеки, ведь игры-то все технически бесконечно различаются, если, конечно, не брать варианты, которые встроены в тот же движок.
skalogryzУчастникwww20 мая 20181:14#50
Odin_KG
> Но мне непонятно, как это можно требовать от универсальной
> библиотеки, ведь игры-то все технически бесконечно различаются, если, конечно,
> не брать варианты, которые встроены в тот же движок.
именно так.
если протокол библиотеки будет требовать чтобы каждый пакет (с информацией об игре) был отмечен игровым временем,
и библиотеке сообщат какую разницу во времени называть лагом, то библиотека в принципе сможет сориентироватся и дать движку дополнительную информацию о том, что "лаг есть".

лагокомпенсация всё-равно должна реализовываться игровым движком.
(по сути - сама простейшая интерполяция, внесение измений задним числом, и экстраполяция, в случае плохой связи с сервером).

Odin_KGПостоялецwww20 мая 20183:00#51
skalogryz
> если протокол библиотеки будет требовать чтобы каждый пакет (с информацией об
> игре) был отмечен игровым временем,
> и библиотеке сообщат какую разницу во времени называть лагом, то библиотека в
> принципе сможет сориентироватся и дать движку дополнительную информацию о том,
> что "лаг есть".
Получается, что это всё нужно, чтобы только библиотека сообщила, что время между пакетами превысило некую норму. Хм... ну это как-то примитивно, чтобы реально чем-то помочь, а потому почти бессмысленно.

>лагокомпенсация всё-равно должна реализовываться игровым движком.
Так я и думал :-)

Sh.Tac.Постоялецwww20 мая 20184:11#52
Odin_KG
> библиотека сообщила, что время между пакетами превысило некую норму.
там не так конечно : )
клиент должен уметь считать серверное время по отметкам времени
без этого о синхронизации можно даже не заикаться

но обычно даже это приходится делать руками

skalogryzУчастникwww20 мая 20185:36#53
Odin_KG
> Хм... ну это как-то примитивно, чтобы реально чем-то помочь, а потому почти бессмысленно.
именно так - примитивно и бессмысленно.

при реализации библиотеки я вижу три варианта:

1) Простой. Содержимое пакета данных "дельты игры" библиотека не распознаёт.
Данные подготавливаются/парсятся игровым движком.
она просто вешает на него временную метку и отсылает на сервер (а так или иначе, следит за тем был ли получен пакет или нет)
Соответственно получив такой пакет, библиотека сразу передаёт его серверу и забывает.

2) Формальный. Содержимое пакета данных "дельты игры" библиотеке известен в некоторой форме.
Например игровой движок может сообщить, что на каждый игровой объект будет посылаться
id - int32
x,y,z - single
health - int32
cooldown - int32
parentid - int32
библиотека сама решает как эти данные складывать и паковать.
При подготовке пакета, движок передаст все необходимые данные библиотеке и она их перешлёт.

Т.к. библиотека знает о том какие данные передаются и как их читать, она может отслеживать изменение состояния объекта
(например путём того, что она ведёт историю данных).
При получении очередного пакета с дельтой, она может сверять известную ей историю с пакетом, и предлагать некоторую интерполяцию для известных ей данных.

Например: движок может указать библиотеке, что x,y,z,cooldown - должны интерполироваться линейно, а id, health, parentid не должны интерполироваться вообще никак.
Проблема начнётся в тех случаях, когда интерполяция должны быть более сложной; (физика! и физические библиотеки это не то, от чего должна зависеть библиотека сетевая)
Тут, конечно, может помочь сервер, просчитав недостающую (сложную) интерполяцию дополнительно.
(но если делать что-то частично, то почему бы просто не сделать всё?!)

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

Правка: 20 мая 2018 5:36

Odin_KGПостоялецwww20 мая 201812:27#54
Sh.Tac.
>там не так конечно : )
>клиент должен уметь считать серверное время по отметкам времени
>без этого о синхронизации можно даже не заикаться
Это всё уже незначительные детали, которые общего смысла не меняют.

skalogryz
>именно так - примитивно и бессмысленно.
>при реализации библиотеки я вижу три варианта:
Я определенно выбрал бы вариант 1. Хотя бы потому, что типы данных, которые буду передаваться по сети будут разнообразными, а не только в виде:

id - int32
x,y,z - single
health - int32
cooldown - int32
parentid - int32

На деле это всего лишь один тип сообщения из многих, хотя он и основной. Но с ходу можно придумать еще кучу полезных сообщений типа чат, настройка своего юнита (цвет фуражки поменял), подсоединение к игре, отсоединение от игры. Всё это хотя и выполняется относительно нечасто, но в любом случае требует реализации. И в результате получится, что реально в игре 10-15 видов сообщений, из которых "игровое" только одно. А делать нужно всё равно все.

Sh.Tac.
skalogryz

Я так понимаю, что ночью никто не спит - все пишут код. Похвально :-)

Правка: 20 мая 2018 12:39

Роман ШуваловУчастникwww20 мая 201816:22#55
skalogryz
> при реализации библиотеки я вижу три варианта:
Четвертый вариант: движок, использующий библиотеку, во время инициализации передает в нее callback-функцию, которую библиотека просто дёргает и всё. Ей не нужно уметь считать интерполяцию векторов и делать поправку на физику - она просто вызовет callback движку с просьбой "посчитай, ты умеешь". Именно так я и сделаю, если решусь-таки сделать (доделать) собственную библиотеку. Короче, суть в том, что сетевая библиотека должна знать и понимать, что и когда надо делать. А вот как делать - этим должен заниматься движок игры, ведь он единственный кто умеет делать это хорошо.
Odin_KGПостоялецwww20 мая 201816:52#56
Роман Шувалов
> Четвертый вариант: движок, использующий библиотеку, во время инициализации
> передает в нее callback-функцию, которую библиотека просто дёргает и всё. Ей не
> нужно уметь считать интерполяцию векторов и делать поправку на физику - она
> просто вызовет callback движку с просьбой "посчитай, ты умеешь".
Это правильный подход.
DelfigamerПостоялецwww20 мая 201818:18#57
Роман Шувалов
> Четвертый вариант: движок, использующий библиотеку, во время инициализации
> передает в нее callback-функцию
Delfigamer
> В библиотеках, API с участием колбэков считается дурным тоном, ибо работа с
> ними - тот ещё геморрой.
skalogryzУчастникwww20 мая 201819:30#58
Роман Шувалов
> Четвертый вариант: движок, использующий библиотеку, во время инициализации
> передает в нее callback-функцию, которую библиотека просто дёргает и всё. Ей не
> нужно уметь считать интерполяцию векторов и делать поправку на физику - она
> просто вызовет callback движку с просьбой "посчитай, ты умеешь". Именно так я и
> сделаю, если решусь-таки сделать (доделать) собственную библиотеку

это как раз второй вариант:
skalogryz
> При подготовке пакета, движок передаст все необходимые данные библиотеке и она их перешлёт.
(передать можно или напрямую, или через callback-и)
> Тут, конечно, может помочь сервер, просчитав недостающую (сложную) интерполяцию дополнительно.
(опять же - интерполяция, через callback-и же)
Основная разница между "первым" и "вторым" в том что сетевая библиотека "знает" что она передаёт.

та библиотека, которую я сам пилю (паскаль-с), работает по "первому" методу (т.е. библиотеке не знает о данных игры)
но в процессе доделывания лаго-компенсации, мне как-топодумалось что сам "лагокомпенсатор" мог бы быть отдельным компонентом.

+ схема

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

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

Delfigamer
> В библиотеках, API с участием колбэков считается дурным тоном, ибо работа с ними - тот ещё геморрой
ммм, а с делегатами - дурной тон?

Odin_KG
> Я так понимаю, что ночью никто не спит - все пишут код. Похвально :-)
так и есть. Но смог отладится, и нашёл логический баг, затычку сделал. (затычка, потому что основана на принципах конкретной игры)
Теперь хожу и думаю, как сделать так чтобы решение было красивым и работало для всех случаев.

Правка: 20 мая 2018 19:40

Odin_KGПостоялецwww20 мая 201820:17#59
Delfigamer
>В библиотеках, API с участием колбэков считается дурным тоном, ибо работа с ними - тот ещё геморрой.
"Дурной тон" или "не дурной тон" - это не важно. Главное - результат.

skalogryz
> так и есть. Но смог отладится, и нашёл логический баг, затычку сделал.
Ну, это радует :-)

Страницы: 13 4 5 611 Следующая »

/ Форум / Программирование игр / Сеть

2001—2018 © GameDev.ru — Разработка игр