UNITY: Реализация движений для динамичного шутера. Часть 2

[Tutanhomon]

CheckWallsAround()

Здесь стоит использовать NonAlloc версии методов.

Насчет UnityEvent, отчасти дело вкуса, но большой их минус перед с# ивентами - сильно сложнее отследить, кто на них подписан, но в этом конкретном случае не так страшно, только в одном префабе используются

[HexGrimm]

А почему у вас для поворота камеры используется время? Похоже на ошибку.
newCameraRotation.x += inputView.y playerSettings.verticalSensetivity * Time.deltaTime * playerSettings.verticalInverted == true ? 1f : -1f);

[Red_Atom]

Это связано с тем, что данный метод вызывается в Update и привязан к частоте кадров

[HexGrimm]

Да совсем нет, это ввод игрока. Иначе на разных мониторах будет разная чувствительность у одной и той же мышки. + так заложена акселерация, что тоже для шутера сойдет за ошибку.

[Red_Atom]

Эм... что значит "нет"? Посмотрите на метод Update и увидите, что метод CalculateView() вызывается в нём. Этот метод не вызывается при вводе игрока, он вызывается каждый кадр и потому привязано к fps. Умножение на Time.deltaTime нужно для компенсации разницы в fps.

[HexGrimm]

Но поворот это же конечная величина, которая не зависит от фпс. Игрок в физическом времени подвинул мышку на одно и то же расстояние, и умноженное на чувствительность в градусах - камера в итоге должна повернуться на один и тот же градус, вне зависимости за какое число кадров это произойдет. Если умножать на дельтатайм, то сумма уже может не сойтись.

[Red_Atom]

Да, действительно. Вы абсолютно правы. Только что переделал код. На самом деле в таком случае этот метод даже не нужно вызывать в Update - вместо этого его лучше сразу же вызывать при получении ввода от NewInputSystem. Большое спасибо, что обратили внимание на этот момент!

[Jijiki]

не так важно как прыгать и двигаться(я сейчас так думаю), потомучто реально 3 ляма треугольников нагружает например(и получается нужен реально либо нанит либо воксель-воркер или не знаю) если не склеивать квадранты-они же чанки, важно многопоточная прогрузка уровня(меша), сужу по воксельной ситуации, я впервые в жизни пролетел по воксельному миру своему - 32х2х32 - чанка там с каналами и воркерами и всё улётно летит и нет заиканий и нет утечек, и вот такого же я у себя пока не достигал в простых играх(без вокселей, хотя дошел, до анимаций, карты в масштабе-1 чанк если по воксельным меркам, двойной свет, физика и BVH), но это не сравнимо с подгрузкой и выгрузкой мешев как в вокселях(ну 30-50 мегабайт на 4х2х4 = по 16х16х16 размер чанка - это улётно реально), плюс еще тут почти бесплатный ао, да еще плюс ко всему воксели это уже почти VoxelCone GI, я правда на gl+rust тесчу всё это

[taisnigs]

Если в игру играть весело, пусть там и треугольников немного, то и ладно. А если не весело, зато графика красивая, то играть то зачем?

[Jijiki]

суть в том, пока я учился и пытался, я понял, что не важно какая игра, её просто надо доделать, переходить в инкапсуляцию и многопоточку(вы же не будете забивать main thread или будете?), управлять ресурсами, и делать интерактив, в диапазонах вокселей, бесконечный мир с такими вводными это 0.5% на проц, и 30-50МБ озу, с картинкой почти как из VoxelCone GI, потомучто есть ао, если доделать хотябы 1 игру до конца технически появляется понимание что и почему мы делаем (ну 3 миллиона это я погарячился 3 миллиарда уместнее будет), тоесть инкапсуляция тут выступает во всей своей красе, да на начале мы делаем 1 маленькую сцену, но там теже воркеры подобные воксельной обработке многопоточной, это надо понимать, а значит это надо делать и разбираться как управлять ресурсами в условиях инкапсулируемой логики на многопотоке

тоесть отвечу на ваш вопрос, значит надо делать ту игру в какую вы будете играть прежде всего, ведь инкапсуляция на многопоток, от 1 сцены отрисовки отличается я сейчас дошел до этого и увидел разницу, поэтому и надо доделать до конца хотябы 1