fgntfg
любопытный таск.
Saphire
Есть куча клиентов, и у одного из них (или где-то вне) - есть ретранслятор комманд от всех клиентов всем другим
Snusmumriken
...а вы?
Сервер есть, в виде клиента который соединяет других клиентов с собой и друг с другом.
У меня просто такое впечатление, что ты компенсируешь умными словами отсутствие реального понимания происходящего.
Saphire
У меня просто такое впечатление, что ты компенсируешь умными словами отсутствие реального понимания происходящего.
Так, ладно, успокоюсь...
В чем именно вознивает у вас вопрос?
Snusmumriken
Или я просто очень хочу конкретики
Snusmumriken
Желательно, расписанный по шагам процесс убийства игрока несколькими пулями, с обеих сторон (клиенты и сервер).
fgntfg
@Snusmumriken на самом деле - если "сервер" убивет всех суперхедшотом, то все с этого сервера уходят.
Saphire
Желательно, расписанный по шагам процесс убийства игрока несколькими пулями, с обеих сторон (клиенты и сервер).
Так, начем с самого начала:
Протокол состоит из однотипных сообщений о состоянии абсолютно всех требуемых клавиш
Т.е. по сути {button.state("w"), button.state("a"), ...}
fgntfg
Так, начем с самого начала:
Протокол состоит из однотипных сообщений о состоянии абсолютно всех требуемых клавиш
Т.е. по сути {button.state("w"), button.state("a"), ...}
быстро не получится. У тебя датаграмма будет со слона размером.
Snusmumriken
Допустим. Ну, там не клавиши а команды: shoot(vec), jump(press), jump(release)
fgntfg
но продолжай
Saphire
Допустим. Ну, там не клавиши а команды: shoot(vec), jump(press), jump(release)
Ммм, нет, вот это уже лишнее
Saphire
Вектор можно легко модифицировать, а проверить - никак
fgntfg
Ммм, нет, вот это уже лишнее
а если я на стрелочках играю? Не. Состояния - ровно то, что нужно
Snusmumriken
Хе, проверить на стороне клиента - можно.
На стороне сервера - тем более. В какую сторону повёрнута пушка - в такую и стреляем.
Я про векторы направления.
Векторы движения и координат - нельзя, да.
Saphire
а если я на стрелочках играю? Не. Состояния - ровно то, что нужно
...вы понятие "абстракция" и "пример" понимаете? Я не пишу идеально рабочий код и протокол, только минимум необходимый для понимания.
Saphire
Хе, проверить на стороне клиента - можно.
На стороне сервера - тем более. В какую сторону повёрнута пушка - в такую и стреляем.
Я про векторы направления.
Векторы движения и координат - нельзя, да.
...вектор направления выстрела? Ну ладно, допустим такое можно (все аимботтеры уже радостно потирают руки при обнаружении этого!)
Saphire
Хе, проверить на стороне клиента - можно.
На стороне сервера - тем более. В какую сторону повёрнута пушка - в такую и стреляем.
Я про векторы направления.
Векторы движения и координат - нельзя, да.
Слушай, я выше по сути пересказываю ту же самую статью, которую я тебе скинул.
https://gafferongames.com/post/deterministic_lockstep/ вот самая главная часть
Saphire
Там и показано на чем оно основано, и в чем проблемы, и как их решить.
Snusmumriken
Смотри как можно объяснить авторитарный сервер из той статьи:
1. Сервер держит у себя набор состояний игры за последние несколько секунд.
2. Когда от клиента приходит сообщенька о совершённом действии (со временем на стороне клиента, оно синхронизировано с учётом пинга) - сервер отматывает состояние назад, применяет к клиенту действие и обновляет его (и все новые объекты, которые могут быть связаны с этим действием) в будущее.
3. Сервер отправляет клиентам изменения вызванные последним состоянием в виде команд, типа создания новой лабуды или переключения состояния объектов, сдвига и прочего.
4. Клиенты принимают это счастье, самостоятельно откатывая время "назад", и аналогично применяя действия сервера.
Вот это - синхронизация, где у каждого своё состояние и авторитарный сервер.
Saphire
Смотри как можно объяснить авторитарный сервер из той статьи:
1. Сервер держит у себя набор состояний игры за последние несколько секунд.
2. Когда от клиента приходит сообщенька о совершённом действии (со временем на стороне клиента, оно синхронизировано с учётом пинга) - сервер отматывает состояние назад, применяет к клиенту действие и обновляет его (и все новые объекты, которые могут быть связаны с этим действием) в будущее.
3. Сервер отправляет клиентам изменения вызванные последним состоянием в виде команд, типа создания новой лабуды или переключения состояния объектов, сдвига и прочего.
4. Клиенты принимают это счастье, самостоятельно откатывая время "назад", и аналогично применяя действия сервера.
Вот это - синхронизация, где у каждого своё состояние и авторитарный сервер.
А это называется тонкий клиент и толстый сервер, ну или так как ты сказал. Здесь я ни с чем не против
Saphire
Просто я объясняю СОВЕРШЕННО другую схему устройства сетевого протокола
Snusmumriken
В которой невозможно читерство? : )
Snusmumriken
И да, я тебе показываю как надо объяснять
Saphire
Смотри как можно объяснить авторитарный сервер из той статьи:
1. Сервер держит у себя набор состояний игры за последние несколько секунд.
2. Когда от клиента приходит сообщенька о совершённом действии (со временем на стороне клиента, оно синхронизировано с учётом пинга) - сервер отматывает состояние назад, применяет к клиенту действие и обновляет его (и все новые объекты, которые могут быть связаны с этим действием) в будущее.
3. Сервер отправляет клиентам изменения вызванные последним состоянием в виде команд, типа создания новой лабуды или переключения состояния объектов, сдвига и прочего.
4. Клиенты принимают это счастье, самостоятельно откатывая время "назад", и аналогично применяя действия сервера.
Вот это - синхронизация, где у каждого своё состояние и авторитарный сервер.
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking - а это, описание аторитарного сервера от тех, кто его ввёл, или по крайне мере крупно использует для игр.
Saphire
В которой невозможно читерство? : )
Оно невозможно, если только ты не сделаешь какую-нибудь глупость вроде "вектор стрельбы" или "вектор шага" в самом протоколе.
Snusmumriken
Карочи, если схему долго объяснять - она сложная и нуждается в упрощении
Давай как-нибудь проще.
Saphire
Под клиентами и игроками подразумевается именно сама программа игры, если не сказано иного.
1. У всех клиентов имеется код для симуляции мира. Полностью, никак не обрезанный, и они знают абсолютно всё о игровом мире.
2. Сервер может быть встроен в одного из клиентов, а может стоять отдельно от всех.
3. Сервер не имеет никакого кода симуляции мира, он только заведует авторизацией и...
4. Сервер пересылает сообщения от одного игрока всем остальным, и так для всех игроков.
5. Один из клиентов назначен "главным" и является эталоном состояния игры. Все клиенты, у кого состояние отличается - выкидываются сервером из игры (либо оно корректируется по мере возможностей).
6. Клиенты посылают как можно более общие данные, которые можно легко проверить в симуляции, и в случае чего - несовпадения. В идеале нажатия только нажатия клавиш и, например, текстовые сообщения игроков (людей).
7. Симуляция мира должна быть реализована таким образом, что оно идеально совпадает с такой же симуляций в другом месте (при учёте того, что начальные условия одинаковы)
Saphire
Тут будут крупные расхождения при пинге выше 10мс, и они будут накапливаться.
И поэтому просто прочитай ту статью, которую я скинул.
Да, я не отрицаю, что это так. Но вышеуказанная схема работает только в идельных услвия и идельном мире без потери данных и совпадении состояний.
Для нормальной сети это надо кучу проверок и куда больше данных отсылать.
Snusmumriken
Конкретные данные должны приходить от сервера, для полноценной синхронизации. Иначе жёппка (((
Snusmumriken
А ещё, открою тебе очень страшную тайну.
Идеальные миры существуют только в головах людей.
Тебя интересует тот факт, что идеальный квадрат идеально вписывается в идеально квадратную голову того же размера?
Snusmumriken
Меня - нет.
Не практично.
Нужно какой-то магией определять то что на эталоне, синкать по времени.
С тру-физикой тут вообще проблемы, ибо бешеное количество данных.
Saphire
Гм... Надо было всё же сказать, что чистый локстеп никто не использует в играх...
Его всегда сверху покрывают проверками состояния клиента и эталона, и интерполяцией. Благо, последнее у нас легко доступно, ведь у нас уже есть весь код симуляции мира.
Saphire
Меня - нет.
Не практично.
Нужно какой-то магией определять то что на эталоне, синкать по времени.
С тру-физикой тут вообще проблемы, ибо бешеное количество данных.
А магия определения состояния - отсылка некоего хэша состояния игры в тик #N на сервер, и его сравнение с эталонным клиентов на тик #N
Snusmumriken
Ох. Оно ведь всегда будет отличаться.
Хеш не нужен потому что нет нигде ни одного одинакового состояния. К одному клиенту, пакет придёт через пол секунды, а к другому - через две милисекунды. А с третьим - вообще нет задержки, ибо на том же компе.
Как делать лагокомпенсацию в таком случае и пересылать меньше данных?
Saphire
...пилять, по сути локстеп в играх - это НЕХ полученная скрещиванием настоящего локстепа, авторитативного сервера, и интерполяции.
Snusmumriken
Во, ещё один страшный вопрос. Сколько лет уйдёт на реализацию такой сетевой системы у одного человека ))
Saphire
Во, ещё один страшный вопрос. Сколько лет уйдёт на реализацию такой сетевой системы у одного человека ))
Эм... ты смотрел статью? Ту, которую я тебе скинул? Четвертый раз говорю
Snusmumriken
Какую из? Ты их много прислал.
С кубиками - да.
Saphire
Это серия статей. И там снизу есть ссылка на следующую. Это первая и вторая статья.
Saphire
В общем - рассматривается:
1 - просто физический движок
2 - добавляем сеть на основе локстепа - т.е. симуляция стоит пока мы не получим пакет с состоянием ввода вывода другого игрока.
Минус в скорости
3 - пробуем другую сеть на основе "срезов" - т.е. передаём состояние всей игры от одного клиента другому. Тут уже нечто похожее на авторитарный сервер слегка. Оно жутко жрет траффик, но это оптимизируется в статье (этой или другой)
4 - а теперь совмещаем это всё.
Snusmumriken
Ох. Мобилы умрут на "остановке симуляции пока ждём".
Хех, просто вариация авторитарного сервера может быть гораздо экономичнее. Ясное дело, что у всех тонких клиентов есть возможность симуляции/интерполяции. Просто приходящее раз в несколько секунд состояние авторитарного сервера перезатирает текущее состояние клиента и синхронизирует всё. После получения этих сравнительно больших данных, ясное дело, происходит интерполяция до текущего времени на клиенте.
Кстати, для резкого уменьшения траффика, можно отправлять клиентам только актуальную для них информацию, которая находится, условно, близко к их камере. Очень сильно режет траффик.
Snusmumriken
Anonymous
что за шрифт и цветовая схема?
Snusmumriken
Цветовая схема - стандартная, obsidian на notepad++.
Шрифт - PTMono (опенсорц, производство РФ, хех) https://www.paratype.ru/public/, читаемость норм, мне нравится.
Anonymous
значит в шиндошс рендеринг какой-то совсем другой
Anonymous
у меня ptmono выглядит как... впрочем, это не важно
Snusmumriken
Размер шрифта ещё выставь.
И ты, возможно, не указал его глобально, вышли скриншот.
Anonymous
да скорее всего дело в том, что у тебя начертание жирное
Anonymous
а у меня в редакторе оно не ставится
Anonymous
мне мой норм :3
Anonymous
http://i.imgur.com/SG2FnyW.png
Snusmumriken
Это не PTMono.
Anonymous
я знаю
Anonymous
я и говорю, мне мой норм
Snusmumriken
Окей : )
Anonymous
птмоно у меня выглядит так
Anonymous
Snusmumriken
Выставь bold же!
Anonymous
эмм!
Anonymous
да скорее всего дело в том, что у тебя начертание жирное
Anonymous
а у меня в редакторе оно не ставится
Snusmumriken
Окей, тогда скачай версию bold и поставь : )
Ну, если хочешь, конечно.
Snusmumriken
Anonymous
да. няшно смотрится
Anonymous
но непривычно жесть
Snusmumriken
Хе, ничего, привыкаешь, а после суток непрерывного кодинга - отсутствует песок в глазах : )
Цветовая схема стандартная потому, что меня задолбало на 100500 девайсах настраивать-перенастраивать, но с другой стороны, тоже привыкаешь и норм.
Контраст достаточен и не избыточен. Разве что комментарии полусливаются с фоном, но это и плюс имхо. При чтении, на фоне остального текста, такая бледность выделяется, а при кодинге - не мешает.
Anonymous
мне вот интересно
Anonymous
почему большинство редакторов мутят какую-то хуйню с табами
Snusmumriken
Типа автопреобразования в пробелы?
Anonymous
типа в каждом редакторе табы отображаются по-разному
Anonymous
если я выравниваю в одном редакторе - отваливается выравнивание в другом
Roman
похоже на главный аргумент в войне табы vs пробелы в пользу пробелов
Snusmumriken
В целом, стандарт - один таб = 4 пробела.
Хех. А что ты выравниваешь?
Вот такую фигню
return {
Vers = dc(data, 0),
OP = dc(data, 1),
Result = dc(data, 3, 2),
SSSE = dc(data, 4, 4),
Даже я выравниваю пробелами, потому что между слов может быть хрен знает что, длина слов - хрен знает какая.
А вот до какого либо текста - табы.
Anonymous
Snusmumriken
Карочи, табы должны стоять только слева от текста.
Если ты лепишь табы между слов - ты поступаешь плохо.
Вот слева от текста - им самое место, ибо можно подогнать ширину пробелов под ширину экрана, и получить визуальную глубину вложенности в соответствии с пожеланиями.
Anonymous
типа остальное выравнивать пробелами?
Anonymous
кстати, логично, что если выровнять в geany отвалится во всех остальных редакторах, он даже сам это показывает