GavriKos

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

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

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

1. Место на диске
Просто посмотрите, сколько весит папка с собранной игрой.

2. Количество ОЗУ
Оценить максимум вы можете прямо в диспетчере задач, только проводите оценку не посреди главного меню, а в процессе максимума интенсивности игрового процесса. Также можете создать несколько виртуальных машин на вашем компьютере с разной конфигурацией и по очереди прогнать по ним игру.

3. Видеокарта
Оценить характеристики видео вы можете по загруженности игрой активными объектами и средствами, влияющими на отрисовку - шейдерам, освещению (трассировке лучей, отражениям и т.д.), постпроцессингу и т.д.. Тут зависимость простая - чем больше эффектов, тем круче видеокарта нужна, чтобы каждое обновление экрана всё это дело перерисовывать. Также почитайте про шейдерные модели. Например, та же 4 версия HLSL требует минимум DirectX 10 версии. Также грубо оценить видеокарту вы можете по тому же диспетчеру задач, сравнив значение столбца GPU во время интенсивной игры со значением мощности видеокарты.

4. Процессор
Оценка процессора самая сложная, т.к. в неё постоянно вмешиваются другие процессы. В том же диспетчере задач вы можете посмотреть, как сейчас ведёт себя процессор, плюс можете попробовать занизить его тактовую частоту или выделить игре больше/меньше ядер, чтобы посмотреть как она себя поведёт.

5. Прочее - интернет, звук и т.д.
Если ваша игра требует подключение к интернету, просто напишите "интернет". Если же она содержит механику потокового просмотра видео или стриминг, то также укажите скорость, которую можно замерить любой соответствующей утилитой. Если вы делаете игру для аудиофилов, укажите HiRes Audio. Если нужен контроллер - укажите какой. В остальном требования из разряда "это нужно или нет", а не "что конкретно нужно".

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

Как видите, данный процесс весьма трудоёмкий, а местами требующий специфических знаний. Потому порой проще воспользоваться услугами тестировщиков, или заглянуть на реддит. Например, в r/playmygame или в r/playtesters.

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

твоя ошибка

Caused by: java.lang.IllegalArgumentException: Health must be between 0 and 20.0(24.666667938232422)

ты пытаешься дать больше жизней чем это возможно, ограничивай

p.s. я правильно понимаю, что если я выстреливаю из лука и тут же меняю оружие в руке, пока стрела летит, то у меня просто ничего не сломается?

Во первых. Функциональное программирование не запрещает дата-объекты. Вот к примеру если у вас есть таблица 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.

Эта [s]бесполезаная х**та[/s] функция называется лигатуры.
Обсуждалось много раз, но в целом, вот: https://www.reddit.com/r/vscode/comments/kwc539/di...

Это лигатуры, в настройках шрифта

Обычно такие задачи решаются с помощью фильтра Калмана. Но вам этого датчика будет недостаточно для вашей задачи. Акселерометры не показывают абсолютных координат, они дают только скорость изменения скорости. Для получения координат надо дважды интегрировать ускорение, а при этом быстро накапливается ошибка, ведь нет способа ее устранить.
Для устранения ошибок используют дополнительную информацию о положении робота. К примеру можно поставить энкодеры на колёса, тогда сведения о перемещении вы будете получать не только от интегрирования ускорений, но и от вращения колёс. При этом вы никак не решаете проблему ошибки, вознкающей з-за проскальзывания колёс.
Вообще, фильтр калмана довольно гибкий инструмент, он подразумевает построение модели перемещения вашего робота и фильтрует поток информации с датчиков в соответствии с тем, насколько близко их показания соответствуют модели перемещения.
Грубо говоря, например, будут приняты с малым коэффициентом показания датчиков, которые говорят, что робот внезапно дёрнулся влево с большой скоростью и ускорением, которое очень маловероятно для математической модели перемещения вашего робота. А вот показания. которые близки к тому, что предсказывает модель, будут приняты с коэффициентом, близким к единице.
Прочитайте про фильтр Калмана, подумайте какие еще датчики можно прикрутить к вашему роботу кроме акселерометров и гироскопов, которые, безусловно, способны помочь, но их будет не достаточно для навигации робота в локальной системе координат.
Самый точный способ - это маркировать робота инфракрасным или любым другим светодиодом и находить его камерой, подвешенной над сценой. Так вы получите достаточно точную локализацию и относительно дешево.
Можно оставить на робота сканирующий оптический пассивный радар (фотодиод в трубочке на вращающейся башне), а маячки разместить на местности. Так робот вращая своей башней (с энкодером дляопределения угла поворота относительно корпуса робота) и регистрируя модулированные уникальные сигналы от маячков. сможет триангулировать и доуточнять своё положение. Даже двух разнесенных маячков, если они не на одной линии с роботом, достаточно для очень неплохой точности локализации.
Бывает, что на местности активные маячки разместить проблематично, тогда используются пассивные маркеры - яркие конусы, QR-коды, контрастные метки. Тогда на робота надо ставить камеру. таком случае добиться можно еще бОльшей точности локации, но в ущерб сложности и ресурсоемкости бортового оборудования.

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

В том же, в каком и в 2022-м.