Почему скорость игры в сборке может сильно отличаться от редактора в Unity?
Добрый день!
Есть 2d проект состоящий из двух сцен (меню и основная игра). В меню присутствуют двигающиеся декоративные элементы. В самой игре есть элементы использующие 2d физику. В процессе разработки периодически делал новые сборки для проверки. На определенном этапе столкнулся с такой проблемой: при открытии exe-шника такое впечатление, что время течет намного быстрее (все двигающиеся элементы очень сильно ускорены). При переходе во вторую сцену (сама игра) все элементы, которые используют физику работают тоже не корректно (наоборот, как будто замедленно). При этом в редакторе самого Unity все проигрывается, как и раньше с заданной скоростью. Проблема выявилась только при проверке сборки. В промежутке между сборкой, в которой все отображалось корректно, и сборкой, в которой "все ускорено" было добавлено несколько новых префабов со звуком и откорректирован код для их проигрывания. Так же, в этот период была случайно удалена часть префабов из папки Assets и затем восстановлена из отдельного бэкапа. Удаленные префабы за этот промежуток между сборками не редактировались. При создании сборки пробовал все возможные варианты компрессии и сборок для разработчиков - результат не меняется.
Понимая, что скорее всего причин может быть много и что выкладывать кучу скриптов не целесообразно, прошу, по возможности, подсказать в направлении чего стоит начать поиск проблемы.
Проверил fps по Вашему совету, и действительно, в редакторе около 60, а в сборке около 2000. И действительно, я совсем забыл про Time.deltaTime. Остается непонятным, почему до этого в сборках fps соответствовал редактору, и ошибка не проявлялась, и из-за чего предполагаемый лимит в сборках в 60 fps слетел.
Теперь встал вопрос с восстановлением изначальной скорости всех объектов, т.к умножение на Time.deltaTime, как я понимаю надо выполнять вместе с "поправочным коэффициентом". А простое вычисление =(FPS в сборке / FPS в редакторе) не дает точной исходной скорости, т.к. fps в сборке сильно варьируется. В любом случае спасибо за решение главной проблемы, остальное - дело техники!
Time.deltaTime - это и есть выравнивающий коэффициент. это время, которое прошло между кадрами.
Поэтому если вы в Update .. делаете движение объекта.
То умножив смещение на Time.deltaTime - вы как раз получите везде одинаковую скорость.
Что при 30 FPS что при 3000 FPS. всегда будет N метров в секунду. где N не зависит от частоты кадров, а только от размера смещения (скорости) объекта
Спасибо большое за уделенное время, даже после закрытия вопроса!
Насчет того, что Time.deltaTime позволяет задавать скорость в ед/с а не в ед/кадры я понял, теперь трудность перевести скорость объектов, которая была рассчитана в ед/кадры при 60fps в скорость ед/сек :) Решил довольно большим костылем - ограничил fps в сборке на искомые 60. Понимаю, что костыль, и что при проседании fps все погорит, но в рамках данного небольшого проекта думаю можно это простить. На будущее, насколько я понял, чтобы не зависеть от fps надо все не-физические перемещения умножать на Time.deltaTime; все физические на Time.fixedDeltaTime
Простой
