Вот я как раз стал обладателем множества эксклюзивных вещей, написанных лично мной.
Вы же знаете, что во всех проектах родом из 90-х обязательно лежит уникальный код, написанный энтузазистами. Потом это всё может обрасти дополнительными библиотеками, но невозможно построить свой продукт полностью из чужих библиотек
Можете посмотреть на Neo Axis Engine который именно так и устроен.
Свой код там только на шарпе, остальное всё сторонние либы.
Даже в Юнити изначально было больше своего и с каждой версией стороннего становится всё меньше, что хорошо и правильно.
Ну так блин это архитектурой называется, естественно у проекта из кучи либ архитектура выйдет крайне странной и не гибкой, но если строить что то поверх, в целом жить можно. Зависит всё опять же от конечной цели.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Ну чтож, по дельте могу определённо сказать следующее.
Сам факт передачи состояния объекта на клиент однозначно зависит от наличия у этого объекта модели. Каких-то других условий пока что не предусмотрено и если объем трафика окажется приемлимым, я полагаю никаких дополнительных условий там и не понадобится.
Собственно, в квейке оно так и было, в халфе ещё ввели дополнительную проверку на EF_NODRAW, но я думаю это лишнее, т.к. ломает интерполяцию.
Даже невидимая модель должна отсылать свое состояние на клиент, в случае если она играет какую-то анимацию. А если же её состояние не меняется, так обновления не будет происходить в любом случае.
Дядя Миша писал: Сам факт передачи состояния объекта на клиент однозначно зависит от наличия у этого объекта модели.
Т.е. если объект выполняет какую то чисто логическую операцию на сервере, типа мультименеджера, то он не будет отсылаться клиентам только потому что на нём не висит модель ? Или о какой модели вообще речь?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
FiEctro писал: Т.е. если объект выполняет какую то чисто логическую операцию на сервере, типа мультименеджера, то он не будет отсылаться клиентам только потому что на нём не висит модель
Совершенно верно. А зачем ему отсылаться клиентам?
Дядя Миша
Ну чтобы у клиента тоже мог выполниться скрипт? Объясни вообще как ты пришел к такому? Может я что то не понимаю.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
FiEctro писал: Дядя Миша
Ну чтобы у клиента тоже мог выполниться скрипт?
Какой смысл в этом вообще? Вся логика происходит на сервере, задача клиента лишь в том чтобы происходящее просто отрендерить, и посылать на сервер команды которые игрок выполняет.
FiEctro писал: Ну чтобы у клиента тоже мог выполниться скрипт?
Клиент только отправляет ввод на сервер и рисует окружающий мир, то что сервер ему прислал. Классическая клиент-серверная архитектура.
Что ты не понимаешь? Она всегда таковой была, пока не началось засилье Юнити, где роль сервера свели до чисто декоративной.
Если что-то выполняется на сервере мы имеем лаг. Если что-то выполняется на клиенте мы имеем двойной лаг. Потому что сперва клиент читает что ему прислал сервер, потом сам что-то выполняет, потом отправляет на сервер, потом сервер рассылает всем остальным. Т.е. с точки зрения соответствия реальным событиям, эта схема вообще не выдерживает никакой критики.
Но зато она сильна проще в реализации, да.
Каждый в своём маня-мирке, синхронизация только по часам и рандом-сиду.
Ну от конкретной игры конечно зависит. И раз в минуту корректирующая синхронизация, которая может перевернуть всё с ног на голову.
Добавлено 24-07-2024 в 18:53:
На архитектуре с сильным уклоном в сторону клиента высокоскоростные шутера не делаются - сразу все косяки наружу вылезают.
Там наоборот хорошо когда большие открытые пространства и кемперинг.
Добавлено 24-07-2024 в 18:55:
На геймдеве была дискуссия насчёт предиктинга, так дошли до того, что вместо предиктинга подключают... бота
Ну то есть вместо предиктинга сторонних игроков (потому что там тоже двойной лаг) включают бота, который себя ведёт "почти как тот игрок", типа бот анализирует его стиль игры. Другой сказал, если ко мне на сервак лагучий игрок заходит - его автоматика сразу выбрасывает, чёб другим игру не портил.
Добавлено 24-07-2024 в 19:44:
Схема дельта-компрессии, которую я щас реализую в самих квейках не встречается, поэтому я не могу однозначно сказать за её оптимальность в условиях плохого сетевого коннекта. Но вот в плане потребления памяти - она оптимальная. Дельта от Кармака могла легко сожрать десятки гигабайт на 128-и игроках. Понятно, что такое нам не нужно.
Дядя Миша писал: Схема дельта-компрессии, которую я щас реализую в самих квейках не встречается, поэтому я не могу однозначно сказать за её оптимальность в условиях плохого сетевого коннекта. Но вот в плане потребления памяти - она оптимальная. Дельта от Кармака могла легко сожрать десятки гигабайт на 128-и игроках. Понятно, что такое нам не нужно.
Я бы кстати очень был бы не против какое-нибудь чтиво почитать о том, как дельта-компрессия в играх устроена и работает. Я знаю общие принципы того, как оно устроено, но не понимаю как это всё в сборе функционирует.
Ну чтож товарищи, настала пора сделать выбор. Точнее может даже и не выбор, а высказать свою позицию по вопросу. А дело тут вот в чём.
Изначально, как вы помните, я планировал смешать клиентские и серверные энтити в единый массив. Но подобная архитектура резко усложняет работу с сетью, всегда приходится удерживать в голове тот факт, что один и тот же объект существует и на клиенте и на сервере. Плюс мы получаем разные стили интерполяции в синглплеере и мультиплеере и невозможность заставить сервер тикать лениво. Т.е. скажем 10-20 раз в секунду, полагаясь на то, что визуальные рывки будет проинтерполированы клиентом.
Из плюсов совмещённого хранения только экономия памяти, да и то не слишком значительная, я полагаю. Ну может быть мегабайт 10 или 20, а может и того меньше. Виртуальная машина хранит объекты оптимальным образом, поскольку не имеет обязательных полей, как было в первой халфе, гигантская структура entvars_t, которая выделялась для любого объекта.
Этого у меня нет, оно просто без надобности. На данный момент тысяча энтить на сервере (с учётом пользовательских полей, системных полей и переменных для анимации) занимают около одного мегабайта. Ну и клиентский комплект плюс-минус столько же. Т.е. не критично в принципе.
Плюсом лично для меня будет работа с хорошо знакомой архитектурой, для тех кто кодил под голдсорс - аналогично. Для тех же кто работает с Unity - вот тут вопрос. Я знаю что там только один объект, клиентской копии нет, правда и с сетью там непонятная ситуация, вроде как только сторонние решения, неизвестно насколько надёжные.
Вот собственно вопрос - насколько лично вам удобно и комфортно мыслить в рамках клиент-серверной архитектуры? Т.е. как в голдсорсе и старом ксаше? Напоминаю, что здесь вернётся та же самая заморочка, когда поле, подлежащее репликации на сервере надо будет обязательно добавить и на клиенте тоже. Хотя и не будет ограничения, что переслать можно только те поля, что жестко определены в entity_state_t. В новом ксаше кол-во сетевых полей полностью в ведении пользователя, он сам определяет что передать на клиент.
Вообщем вот примерно такие мысли у меня. Что скажете?
Если тебе неудобно смешивать, ты не смешивай, а поверх этого сделай какой-то интерфейс через который можно будет работать с каждой энтитью равноправно, не думая о том на сервере она или на клиенте.
Удобнее мыслить в рамках сериализации и десериализации особо не залезая под капот.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
23-07-2024 12:04
