mayton2019

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

Отсуствие классов в современном коде - это нормально. Мы живем в эпоху мульти-парадигменности когда языки не обязаны декларировать классы а могут начинаться с функций. А вместо сущностей использовать анонимные классы (tuples) или кортежи как наборы полей в передаваемых параметрах и просто массивы примитивов.

Отсутствие UML диаграмм в проекте - это тоже нормально. Я редко встречал проекты покрытые документацией именно в части чертежей, блок-схем всяких драконов и прочих ГОСТов. Более того. Современный ритм разработки и техники Scrum/Agile говорят что рабочий код важнее чем документация. Я с этим до конца не согласен но так оно есть в нашей реальности.

Чтобы помочь тебе в твоем вопросе - надо посмотреть код. В игре (2д) всегда есть двумерные координаты (Positions), или всякие геометрические фигуры (Bounding Box, Rectangles), ресурсы (картинки и звуки) и их можно описать через классы. Это потребует некоторой переделки твоего кода. Но возможно после этой переделки твой код станет читабельнее.

P.S. UML диаграмм на самом деле очень много. Там не только классы и компоненты. Есть еще очень полезные диаграммы последовательностей (sequence). Конечные автоматы. Реляционные диаграммы (БД). Схемы деплоймента и прочее.

Во первых. Функциональное программирование не запрещает дата-объекты. Вот к примеру если у вас есть таблица Employee из стандартного учебного набора Oracle то она может быть отражена таким образом в Haskell:

data Employee = Employee {
 empno :: Integer,
 ename :: [Char],
 job :: [Char],
 mgr :: Maybe[Integer],
 hiredate :: Day,
 sal :: Integer,
 comm :: Maybe[Integer],
 deptno :: Integer
}

В том что Haskell это достаточно строгий язык который лежит в категории ФП я надеюсь никто не сомневается.

А в мультипарадигменных языках типа Scala с объектами
вообще нет проблем. Берите - делайте объекты сколько надо.

Во вторых, UML проектирование - это такой-себе уровень абстракций, который удобно
обсуждать с бизнесом и показывать на слайдах. Но он вовсе не обязан следовать буква-в-букву коду.
Архитектура - это вообще не про код. Это про намерения, про взаимодействие, про стандарты и смыслы.

Методы UML объектов вы можете сделать функциями. Я не вижу в этом чего-то нерешаемого.
Рассматривайте метод как функцию где первый аргумент - это сам объект. Это такой легкий
троллинг ООП. Типа ООП - это функции где первый аргумент == this.