Alexandroppolus

Задачка действительно простая, но я бы попытался оптимизировать память с прицелом на "sliced strings" - просто как иллюстрация, потому что объемы крошечные.

const full = '#'.repeat(7); // полная строка
for (let i = 1; i <= 7; i++){
    console.log(full.substr(0, i));
}

Если верить некоторым статьям по v8, full.substr(0, i) внутри себя использует тот же строковый буфур, что и full, а не создает новый. Конкатенация тоже переиспользует, но через менее эффективную по памяти структуру. Честно говоря, замеры не проводил )

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

Если тебе надо "увеличивать маленькие значения", то можно использовать какую-нибудь выпуклую функцию для каждого значения, например кубический корень. Ну и потом, в конце, всё равно понадобится четвертая формула, дабы впихнуть всё в отрезок [0, 1]

Или даже так: сначала линейно нормализовать по четвертой формуле, а потом применить некоторую функцию F, возрастающую и выпуклую на отрезке [0, 1], такую что F(0)=0, F(1)=1. Например кубический корень.

мухоморы - лучшее лекарство! кодинг в режиме берсерка

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

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

копия мира на клиенте обновляется по сообщениям ws. Перерисовка - по requestAnimationFrame, где берутся текущие координаты. Обычно такой подход дает плавное движение.

тут есть досадный момент: например, игрок нажимает кнопку-стрелку вправо, но пока об этом дойдет по ws до сервера, пока сервер сдвинет игрока и сообщит об этом обратно на клиента, могут пройти десятки или даже сотни миллисекунд, это будет ощущаться как тормоза. Потому иногда делается "оптимистическое обновление" - на клиенте объект начинает ехать, не дождавшись сообщения от сервера. Выглядит более гладко, но возможен рассинхрон. Так что как лучше, непонятно, обычно это набор компромиссов.

Зачем вручную менять класс? Это "антиРеакт". Держи тему в контексте, завязывай рендер компонента App на значение из контекста, по клику меняй это значение - правильный общепринятый способ. А твой вариант хрупкий и вообще дурацкий.

Худший вариант - base64, лишняя работа и лишняя память на кодирование/декодирование, да и объем пересылаемых данных на 33% больше.
FormData лучше, там байты пересылаются как есть, но на сервере придется всё равно парсить multipart/form-data, вырезать оттуда файл.
Самый быстрый вариант - просто отправить файл или блоб прямо в fetch. На бэке можно будет простримить его в файл, или ещё куда, без всякого парсинга.