Правильно ли такое структурирование кода в контексте ООП?

Foggy Finder, Благодарю за ответ, теперь вопросов не осталось.

Правильно ли такое структурирование кода в контексте ООП?

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

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

что качаемо лички, то если вам не сложно, то можете написать на
почту: [e-mail]
в телеграмм: Kr1po4ek
в вк: cenpa1

Правильно ли такое структурирование кода в контексте ООП?

Благодарю за критику, в целом к некоторым пунктам у меня есть некоторые вопросы.

что касаемо пункта 1:
я совершенно забыл про модификатор доступа protected, большое спасибо что напомнили о его существовании.

в пункте 2:

В случае появления частицы "древесная опилка", её поведение должно быть расширено, а именно нужно добавить возможность горения этой частицы. Можно, конечно, использовать наследования от FallableParticle и расширение поведения, но именно горение не подразумевает того, что частица обязательно может падать. Я имею в виду, что у меня так же может добавиться частица "древесина", которая должна гореть, но не должна падать, разве в такой ситуации не лучше разное поведение определить в интерфейсы и после уже собирать классы из них?
Так же я не совсем понимаю, где интерфейс "IFallable" зависит от "ParticleStorage", как мне кажется от интерфейса зависит "Mover", который получает лист экземпляров от "ParticleStorage", но если я ошибаюсь, то стоит перечитать про зависимости.
Что касаемо поведения "Падающий" частицы, то я просто не смог запихнуть контроль поведения во внешний класс, так как тогда это порождало ещё больше зависимостей, чем при таком варианте, но чисто логически это правильно, песок же ничего не знает о том, что под ним, не падать сквозь материю ему не позволяют законы физики)

А вообще, большое спасибо за ваш ответ и за то, что потратили своё время на неопытного маслёнка.

Правильно ли такое структурирование кода в контексте ООП?

Foggy Finder, Хорошо, честно сказать вы меня заинтриговали, с нетерпеньем жду вашего ответа.

Почему функция pygame.display.update() не обновляет мой экран?

Alexander, хорошо, приму к сведению. Отвечая на предыдущий вопрос про несчастный global: нигде, мой воспаленный рассудок сам додумался

Почему функция pygame.display.update() не обновляет мой экран?

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

Почему функция pygame.display.update() не обновляет мой экран?

Alexander, хорошо, я понял ошибку своего построения (хотя проблема не в этом), но могу я спросить на правах новичка и дилетанта: как мне глобальные переменные из одного файла передать в функцию класса второго файла (и возможно ли это)?

Почему функция pygame.display.update() не обновляет мой экран?

pygame.key.get_pressed() выдает состояние любой клавиши(прим. = "клавиша нажата?")

if keys[pygame.K_UP or pygame.K_w]:
    motion = 'up'

а эта конструкция уточняет, что нажатая клавиша это "K_UP" то движемся вверх

p.s если убрать :
pygame.key.get_pressed()
то по непонятной мне причине постоянное движение при нажатой клавише невозможно

Почему функция pygame.display.update() не обновляет мой экран?

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