Типичный фриланс⁠⁠1

Математика на серверной стороне нужна, когда мир не псевдо-плоский.

Собственно, нужно рассчитывать физику движения всего. Плюс поиск пути - тот еще геморрой.

Если речь про клиент - то вот математики уже надо овердохуя - от тригонометрии до матриц. Даже если использовать готовый игровой движок.

"Математику уже затем учить надо, что она ум в порядок приводит" - Стэтхем.

Вкатиться в геймдев с математикой 5 класса можно, но с оговорками:

Без математики в геймдеве можно решить 95% задач. Но мидловский грейд можно достигнуть только умея решать не менее 100% поставленных задач.

Не всегда можно решить задачу в рамках готового движка. Иногда понимание того как движок работает внутри необходимо, чтобы правильно решить задачу.

Если студия использует свой студийный движок, то совсем не везде есть разделение на команды движка и игры, которые отгорожены друг от друга кирпичной стеной. В моем случае бывало так что все разработчики могли коммитить и в код игры и в код движка, если задача того требовала (чаще, естественно, не требовала).

Не могу сказать, что прям лютой математики. Но высшей так точно достаточно.

Простейшим примером является процедурная генерация вещей , подземелий , городов, монстров, локаций и даже квестов.

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

А для генерации ландшафтов и для создания карт   частенько применяют шум Перлина , симплексный шум, или преобразование Фурье.

Так же частенько в создании игр используется линейная алгебра и в частности матрицы и вектора.

Сейчас конечно существует и альтернативные варианты, например: сторонние библиотеки, ассеты и пакеты. Но у таких вещей есть свои проблемы, в том числе недостаточная оптимизация, из за которой частенько даже простенькие игры подвисают на весьма мощных устройствах. А так же зачастую не самые оптимальные решения внутри, которые в самый неподходящий момент могут вылезти боком из за того, что они универсальны и не предполагали определенного сценария.

Из личного опыта кстати могу  привести пример.  Однажды у меня была задача для мобильной казуальной игры, где нужно было перебрасываться частицей из точки в точку по орбитам планеты на определенные отражатели.  Однако их периодически перекрывали другие вращающиеся объекты.

Казалось бы, что сложного, сделай круг вращения и меняй координаты,  но когда началось тестирование - выяснилось, что все это очень сильно тормозит на тот момент не самых мощных смартфонах среднего класса.  Проблема была в рендеренге объектов. Кроме того, по изначальной задумке было сделать именно похожую на орбиты модель перемещение объектов, естественно с определенными упрощениями.

Времени было в обрез и надо было что-то делать. И вот тут банальное знание формулы движения объекта по орбите космического тела и линейной алгебры - спасло всю ситуацию. Благодаря ей мы отказались от покадрового перемещения объекта и считали все объекты в одном методе, что в итоге и выиграло для нас немного производительности и мы закончили вовремя.

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