x67

Да, конечно

У предмета есть вектор скорости и вектор ускорения. Также есть одна угловая скорость (на плоскости) и одно угловое ускорение.
Собственно разберем простой случай, когда при свайпе предмет мгновенно достигает нужной скорости и нужной частоты вращения.
Тогда можно аппроксимировать свайп в линию (запросы: линейная фильтрация, тренд по точкам, линейная интерполяция и тп). Возможно подойдет просто взять начальную и конечную точку, попробуйте. Тогда у предмета скорость по оси Х будет равна (x2-x1)*К/(t2-t1), где 1 и 2 - точки начала и конца свайпа, а К - какой-то коэффициент, который будет вам удобен. А по оси Y соответственно (y2-y1)*K/(t2-t1).
Закрутку считать так. Берете начальную и конечную точки свайпа, получаете из них линию, далее ищите самую далекую точку от линии (или для простоты ищите расстояние средней точки до линии). Угловая скорость будет пропорциональна этому расстоянию.
Как сделать так, чтобы предметы ускорялись плавно?
Во первых надо запомнить, что ускорение не должно быть постоянным, должна быть какая-то инфляция его во времени. Причем быстрая. Далее нужно решить, есть ли у предметов разная масса (насколько физична игра?) Если нету, то мы работаем напрямую с ускорением, если есть, то появится еще сила, воздействующая на предмет. Предположим массы нет, тогда можно сделать простое ускорение, равное какому-то числу. Конечную скорость считаем также, но при этом не сразу присваиваем скорость, а постепенно изменяем по следующей формуле:Vx=Vx+ax*dt. dt - интервал между фреймами (для девайсов с переменным фпс, чтобы игра не скакала,) ах - ускорение по оси х. При достижении скорости ускорение становится равным нулю.
Еще один вариант плавного разгона - Vx=K*Vx+(1-K)*Vxzad, где К может быть в интервале от 0 до 1, а Vxzad - расчетная скорость, которой надо достичь. Чем больше К, тем медленнее будет ускоряться предмет. Если надо, эту формулу можно написать немного в другом виде, тогда с ней будет приятнее работать (можно будет легко задавать, за какое время предмет будет достигать своей скорости).
Для угловой скорости все это работает точно также.
Ну и да, в принципе можно обойтись без ускорения или сил с массой, задавая скорость алгоритмически, но с ускорением удобно будет вводить разные эффекты вроде гравитации, трения и тп.

я перебрал кучу языков программирования, движков и фреймворков

В 13 лет?
В 13 лет хорошо если есть примерное понимание парадигмы ООП, а вы тут заклинаниями кидаетесь. Для начала успокойтесь и на любимом ЯП напишите "морской бой" с графическим интерфейсом, иначе не поверю в серьезность слов и намерений)

А почему бы вам не пересесть на Юнити? Очень популярный движок и что важно, его освоить будет проще, чем UE4

Почему бы не сделать эти перекрестки вершинами графа? ребра - проходимость между вершинами, а параметры ребра - расстояние между перекрестками.

если у вас мало параметров (здоровье, урон за тычку, тычек в секунду, скорость передвижения) и все они, не знаю, как это назовут математики, но скажем так, линейно влияют на игру, то можно составить показатель для каждого юнита, который будет считаться по формуле
unit_factor=K1*P1+K2*P2+K3*P3+...+Ki*Pi, где Ki=коэффициент влияния параметра, Pi - сам параметр. Интуитивно мне думается, что здоровье (для неподвижных целей при отсутствии модификаторов урона, вероятностей попадания и крита, а также брони) будет иметь такой же коэффициент влияния как дпс, а скорость перемещения уже не укладывается в эту формулу с постоянным коэффициентом влияния и для нее коэффициент должен зависеть от количества тычек, урона за тычку и средних скоростей по игре в целом, как минимум.
В общем, выставляете значения интуитивно, что можно считать, считаете (дпс у танка должен быть гораздо ниже дпса дамагера и тп.), а потом эмпирически через ∞ итераций приходите к идеальному балансу)
Если у беларусов уже за много лет не получилось найти простой путь, то и у вас через тостер навряд ли это получится.

а на чем умеете?

При изучении, объект изучения лучше максимально упростить:
Возьмите простейший open-source 2д движок на вашем любимом языке и поймете его устройство.
Поставьте себе задачу сделать пинг-понг в 2д. Создайте необходимую логику - движение, столкновения. Создайте визуализатор всего этого. Не знаю, как сейчас со всякими джваваскриптами и другими высокоуровневыми языками и диалектами, но в свое время у меня эта задача на delphi занимала очень много строчек кода. Больше 1000 уж точно(хотя мне тогда было 14 и хорошо программировать я тогда не умел и не сумел бы). Когда вы убедитесь на своем опыте, что вас это не испугало и вы досконально разобрались во всем, переходите к 3д. Там появятся такие ключевые слова, как ОпенГЛ, директИКС. Скорее всего о них вы услышите еще пока в 2д будете пинг понг рисовать, но при переходе к 3Д вы поймете, что без готовых движков еще одно измерение увеличивает количество кода на целую степень и в ответ на Тостере точно не уместится)

игровой движок чаще всего выбирается так:
удается скачать юнити? Если да, то это юнити. Если нет, то не судьба.
Вы разрослись в числе, у вас есть финансирование и амбиции? Ну можно анрил попробовать, но если получается скачать юнити, это будет юнити.

Если не планируете развивать функционал в сторону сети, будь то мультиплеер, изменение цен и некоторых внутриигровых параметров, то нет