Дядя Миша писал: Элбер в 4A именно так работу и получил.
Я UE4 начал изучать, как только он стал бесплатным и только после его освоения можно было куда-то рыпаться...
Добавлено 12-08-2023 в 00:46:
Цитата:
Дядя Миша писал: Это с любым сложным софтом так.
Согласен
__________________
Kiss my ass if you don't like my Ford!
------------------------------------------ Game Area51 Update 1
First Person Shooter Released Jul 24, 2017
The game is a 3d shooter with the elements of the quest.
Я так и не прошел до конца. Видимо, вот он, откуда
Цитата:
Дядя Миша писал: Элбер в 4A именно так работу и получил.
Рынок труда сильно меняется в ГД. Когда-то и буззер загремел туда после релиза Паранойи. Сейчас вряд ли прокатит, если кто-то хочет именно так устроится. По крайней мере в ААА.
__________________
To start the match, Let's draw the sketch, Then add some magic from your heart!
Take gold and blue, Take silver too and put a sparkle in your art!
I love that dress, I love It, YES!!! I love the way It makes me feel.
I love the shoes, I love to choose, It was a dream and now It's real!
Если тебе действительно интересно, то я тебе могу многое рассказать о 3д максе и анриле, так как я в этих двух прогах работаю
Добавлено 12-08-2023 в 00:54:
Цитата:
XaeroX писал: Ну справедливости ради скажем, количество человеко-часов, затраченных на Перилос, плюс нужные фичи редактора, плюс движок - это что-то запредельное. Меня до сих пор оторопь берёт, как вспомню... Даже не верится, что мы всё это вытащили.
Ох сколько я в одну мосю потратил времени на Area 51 это просто ппц...
Но это в любом случаи был опыт из которого я сделал определенные выводы
Добавлено 12-08-2023 в 01:00:
Цитата:
Дядя Миша писал: Элбер в 4A именно так работу и получил.
Мне похрен, а ты сам-то в это веришь?
__________________
Kiss my ass if you don't like my Ford!
------------------------------------------ Game Area51 Update 1
First Person Shooter Released Jul 24, 2017
The game is a 3d shooter with the elements of the quest.
Ну чтож, приступаю к реализации первой из озвученных задач - имплементации сетевой подсистемы. Сама по себе сеть на первый взгляд кажется довольно-таки простой задачей - тут байты переслал, там принял. Построил дельта-таблицы (отсортировал в них строчки, естественно), чтобы не пересылать лишнего, а только необходимое. Проинтерполировал данные с предидущими.
Как будто бы всё несложно и тиерично. Проблемы начинаются когда мы хотим предиктинг. Предиктинг базируется на физическом поведении объектов. Физическое поведение объектов мы сами задаём в пользовательском коде. Значит нам надо этот код либо два раза скопировать на клиент и сервер, либо как-то иначе вызвать из другого места, причём имея в виду, что на клиенте возможно будут недоступны некоторые вещи, которые есть на сервере (ну в теории), поскольку полная клиентская симуляция сервера, скорее всего просто затормозит работу движка и ничего не даст нам. Особенно в синглплеере.
Перед тем как выработать собственный подход к проблеме, давайте пробежимся по исходникам уже существующих движков и посмотрим в общих чертах, как оно реализовано там. Поскольку это не обзор на редакторы, я не буду заводить отдельные темы, а буду писать прямо сюда по мере штудирования.
Добавлено 12-08-2023 в 12:42:
Если кто-то вдруг не понял. Проблемы в первую очередь у конечных юзеров, которым при неудачной организации всего этого дела придётся физический код куда-то два раза дублировать. Вспоминайте как все ненавидели этот предиктинг оружий в халфе, как он глючил, как была мешанина из пушек с предиктингом и без. Я не хочу чтобы мы второй раз наступили на эти грабли.
Обзоров пока что не будет, будут общие размышления по теме.
Итак, кроме двух классических сетевых моделей, есть так же два варианта имплементации поддержки сети:
1. Сеть как архитектура
2. Сеть как сервис
Первое - это то, что мы имели удовольствие наблюдать в трёх кваках, а так же в голдсорсе и сорсе и возможно (поскольку нет исходников) в Source2.
В чём тут смысл - сетевая архитектура буквально пронизывает весь движок и заставляет его подстраиваться под нее. Это приводит к тому, что даже в сингл-плеере мы имеем два набора энтить - клиентский и серверный, причём на полном серьезе данные передаются на виртуальный клиент через заглушку (заглушка прямо там же в коде движка, в виде обычных буфферов-массивов). Т.е. по сути выполняется никому не нужная работа.
Так же, ради предиктинга приходится дублировать код физики на клиентской части, с рядом оговорок, само собой, потому что предсказать поведение тех же монстров мы не можем. Предиктинг вообще можно рассматривать как более продвинутый вариант интерполяции, который учитывает некоторые нелинейные условия. Ну например прыжок, приседание или блокировку поезда (если мы предиктим его). Т.е. в принципе предиктинг можно заменить такой простейшей проверкой, типа испускания луча по ходу движения объекта и в 70% случаев этого окажется достаточно (в Darkplaces именно так и сделано).
Единственный плюс такого подхода - для нас олдскульщиков эта модель более привычная и совершенно чётко разделяет клиент и сервер даже если физически они находятся на одной машине. А так же даёт некоторые гарантии, что всё что работало в локальном режиме будет так же работать и по сети. Правда последнее выполняется лишь с рядом оговорок.
Вторая модель - это то, что повсеместно используется сейчас. У нас нет никакого разделения на клиентские и серверные объекты. Объект у нас всегда один. Сеть подключается только когда активен мультиплеер. Всё остальное время она не оказывает никакого влияния. И соответственно не потребляет ресурсов. Для локального игрока тоже всё прозрачно и по сети не передаётся. Для остальных - считывается состояние объекта, отсылается по сети и принимается. Ну и есть две функции исполнения физики - нормальный кадр и кадр предиктинга. Реализация физики для этих двух состояний может чуть-чуть отличаться, хотя это и необязательно. Таким образом:
1. мы не тратим ресурсы на сеть в синглплеере
2. мы не траим память на дельта-секвенции
3. нам не нужно расшаривать свой код на клиентские и серверные инстанции библиотек.
Но есть одна маленькая ложка дёгтя в этом подходе. Поскольку такой сервис не нарушает целостность архитектуры ядра, его прикручивают спустя рукава в надежде, что те, кому надо - сами всё допилят или переделают. Что мы, например, имеем удовольствие наблюдать во всяких Юнити.
Вообщем, подводя итоги, что хочу сказать. Обзоры писать не буду, ибо ничего такого заслуживающего внимания найти так и не удалось.
Только общие рассуждения:
Чем меньше движок (по крайней мере в пользовательской своей части) будет выпячивать свою принадлежность к клиент-серверной архитектуре тем будет только лучше для всех. Я вам объясню принципиальную разницу в этих подходах. Те, кто привыкли кодить под халфу\кваку, знают, что вот они настроили объект и в принципе - всё. Дальше он куда-то передаётся по сети, потом рендерер его подхватывает и рисует. Повлиять на что-либо, получить какую-то обратную связь в принципе невозможно. Иметь в свойствах объекта метод Draw тем более из области фантастики. Тогда как во всех современных движках оно именно так и устроено. Объект, игровой цикл - отправка на отрисовку. Сеть в данном случае действует максимально прозрачно для всех - она по необходимости просто реплицирует объект у клиента и всё. Ну то есть понятно, что есть так же протокол соединения, но он тем более находится где-то сбоку и сами объекты никак не затрагивает.
Соответственно при такой модели есть три способа синхронизации с сервером:
1. интерполяция - если игра запущена на удалённом клиенте, физика отключается и просто ловит обновления переменных по сети.
2. Предиктинг - физика делает несколько кадров как бы в песочнице, используя для нового кадра смешанные результаты от обновлений по сети и полученных локальных вычислений. Кол-во таких кадров определяется кол-вом пришедших обновлений.
3. Полностью локальная симуляция - физика на клиенте живёт своею жизнью (но синхронно с временем сервера) и иногда мягко интерполирует значения с локальными, если они вдруг не совпадают. Т.е. грубо говоря сервер может как рассылать обновления usercmd_t для всех клиентов, так и делать полное обновление стейта. Проблема такого подхода, что возникает как бы двойной лаг, если игнорировать остальные обновления стейтов, например в целях экономии траффика. Впрочем сама модель мне вполне нравится своей гибкостью, у нее потенциально гораздо больше настроек, чем у старой.
Благодаря наличию виртуальной машины нет нужды даже вручную прописывать мета-информацию для всех полей объектов. Можно собрать списки полей в полностью автоматическом режиме. Тут тоже возможны два варианта:
1. Собираем стейты со всех полей в каждом объекте, отправляем их на клиент целиком, ориентируясь на тип переменной. Если float - передаём четыре байта, если byte - передаём один байт. Получившийся пакет сжимаем каким-нибудь простейшим архиватором, тем же LZSS. Так же заводим delta_state для каждого серверного объекта, чтобы не отправлять данные, которые не изменились. Правда тут потребуется обратная связь, скорее всего - клиент, приняв обновления, должен будет отослать на сервер подтверждения что стейт синхронизирован и только тогда кэш будет считаться валидным.
2. Для тех, у кого много свободного времени - всё как в первом варианте, но при помощи встроенных средств языка вы указываете сколько бит использовать для передачи по сети той или иной переменной и таким образом вручную оптимизируете траффик свой игры. Работа несложная, но как правило такое дико раздражает если обязательно требуется, как в той же халфе - каждый раз когда мы хотим что-то передать на клиент, приходится лезть в delta.lst и что-то там сортировать, добавлять. Никому это не нравится. Ну а когда игра полностью готова - почему бы и не оптимизировать?
Из вышесказанного, надеюсь, уже понятно, что новый ксаш будет очень сильно напоминать Unity по крайней мере той его частью с которой будут иметь дело игровые программисты. По духу, по концепции, но не по реализации!
Надеюсь будет и способ по фасту вкинуть сеть в проект
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
В новом ксаше есть любопытное ограничение архитектуры: он способен рисовать только модели и больше ничего, кроме моделей.
Ну то есть как. Он может рисовать конечно буквы в меню или отладочные линии-полигоны, но штатная отрисовка универсального конвейера заточена только и исключительно под модели. Поясню почему так получилось:
Всё дело в системе материалов. Каждый материал состоит из трёх частей.
1. базовая часть
2. опциональная часть
3. пользовательская часть
Базовая часть - это настройки по умолчанию. То что никогда не придётся прописывать пользователю для каждого материала. Они всегда есть и их всегда можно поменять, но для всей группы материалов разом.
Опциональная часть - даже не знаю, работает ли она. Никогда её не использовал, просто не было нужды.
Пользовательская часть - это собственно та часть, которую мы все привыкли видеть как описание материала. В чём же подвох, спросите вы?
Так именно в том, что базовая часть вяжется к строго определённому типу модели, а материал без базовой части существовать не может - и текстурные юниты и юниформы во время рендеринга активно обращаются к модели и берут оттуда различную информацию. В принципе можно создать такую специальную фейковую модель для короткоживущих эффектов (например партиклей) и скорее всего в дальнейшем я именно так и сделаю. Но вот для долгоживущих эффектов (лучей, декалей), этот вариант наоборот оказывается невероятно удобным.
По сути получается такая секретная модель которая внутри движка неявным образом прилинкована к энтите и в течении всего времени её жизни аккумулирует в себя декали, которые были поставлены на эту энтить. Оптимизирует их там внутри себя, собирает в батчи, ну итд.
Причём, поскольку модель является частью стандартного конвейера, то такие декали сразу из коробки получают абсолютно весь функционал обычных моделей в плане настроек системы материалов. Т.е. ситуации, когда у моделей одни настройки, а у декалей другие, более ограниченные попросту не возникнет.
Дядя Миша писал: В новом ксаше есть любопытное ограничение архитектуры: он способен рисовать только модели и больше ничего, кроме моделей.
Нам с начала нулевых промывали мозги: браши устарели, браши это прошлый век, кубизм офигевший и так далее. На любой вопрос тогда маппер получал ответ: "сделай моделькой". Ну, собственно, вот и закономерный результат.
Не очень понял. Вот OpenGL позволяет рисовать вертексы, полигоны, текстуры, линии и т.д. Имеется ввиду что такие структуры смогут существовать как отдельный объект на сцене или что?
Цитата:
XaeroX писал: Нам с начала нулевых промывали мозги: браши устарели, браши это прошлый век, кубизм офигевший и так далее. На любой вопрос тогда маппер получал ответ: "сделай моделькой". Ну, собственно, вот и закономерный результат.
А сам то втихую на моей спонзе некоторые браши модельками и кривыми заменил Зрада.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
FiEctro то отрисовка в ImmediateMode. А я про объекты, которые загружены в видеопамять и не изменяются.
Декали ведь создаются один раз и потом уже не модифицируются.
| IP: 
11-08-2023 21:33
Зрада. 
