А я подумал, вы про model view presentation

Я подумал про minimum valuable product

А как называется человек, которому даешь задачу, а она у него уже сделана?

А как называется человек, которому даешь задачу, а она у него уже сделана?

Логарифм и резинки
#код
Как-то в одном из чатов обронили фразу: «а когда вам последний раз был нужен логарифм?». Забавно, но мне он потребовался буквально на следующий день. Это ещё один маленький пост о том, какого рода математика нужна геймплейному программисту в повседневной жизни.

Часто нам нужно сглаживать какие-то процессы, у которых нет чёткого конца или он меняется во времени. Ну, например, у нас один объект — пусть это будет ручной дракончик — движется на воображаемой резинке за другим объектом, который тоже постоянно в движении: скажем, это будет персонаж игрока. Если игрок оказался далеко от дракончика (например, телепортировался), то дракончик сперва летит к нему очень быстро, но при приближении постепенно замедляется, чтобы это смотрелось хорошо.

Новички обычно просто домножают скорость дракончика на расстояние до игрока. Это простое решение, но ужасно плохое, поскольку время, за которое дракончик долетит до игрока, будет напрямую зависеть от FPS. При низком фпс он будет добираться до цели быстро, а при большом топтаться на месте неожиданно долго. А если FPS скачет, то и вовсе придётся лицезреть нечто рывкообразное.

Юнитологи классом повыше обычно используют небезызвестную функцию SmoothDamp. Внутри там скрывается мудрённое решение из книги Game Programming Gems 4. Вот только нам приходится где-то хранить текущую скорость для каждого процесса сглаживания, да и в целом довольно страшно выглядит. Нельзя ли как-то попроще сделать и без лишних переменных в местах вызова?

На самом деле если мы задумаемся, как будет выглядеть FPS-независимый способ приближения со сглаживанием, то быстро поймём, что нам надо проходить одинаковую долю расстояния за одинаковое время. Например, за первую секунду проходим половину пути, за вторую секунду половину от половины, то есть остаётся четверть, затем 1/8, 1/16 и так далее. И никогда мы по настоящему не достигаем цели, но нам это и не надо. При таком движении неважно в какой точке этого процесса мы оказались (на первой секунде, второй и т.п.), мы всегда знаем, как рассчитать движение дальше. От пути всегда остаётся лишь

1 / 2^t

А значит пройденное расстояние от времени вычисляется по формуле:

1 - 1 / 2^t

Двойка здесь всего лишь указатель на то, что в качестве одинаковых промежутков мы выбрали половину расстояния. Мы можем подставить туда 3, чтобы получить треть, или любое другое число больше 1. Можно думать об этом числе, как о степени агрессивности нашего In в нашем FPS-независимом сглаживании (аналог InCubic, InQuad и т.д.). Формула продолжит работать.

Но для полного счастья нам не хватает настройки времени, за которое дракончик будет визуально догонять персонажа из любой точки. Конечно, полностью он догнать не может, но нам хватит преодоления, скажем, 98% пути:

1 - 1 / base^t = 0,98
base^t = 1 / (1 - 0,98)
t = log(1 / (1 - 0,98), base)

Ну вот и всё. Теперь мы можем инициализировать этими параметрами нашу бесконечную резинку-пружинку, после чего ей можно будет скармливать deltaTime, а в ответ получать LerpK. Таким образом получилось простое FPS-независимое сглаживание для всего, что можно лерпать. Финальный класс можно видеть на скриншоте.

По-моему, симпатично получилось. А вы что думаете?