ZlaYa1000, отрефакторю и закину обратно, да. Сейчас душа лежит героя допилить =)

NekoriDes, я его сам выпилил временно =)

alexprey, окей, буду текстом код закидывать
:D

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

В Си это же делается ещё быстрее и без массивов через побитовый сдвиг влево.

Sergarr:

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

Кстати, технически вектор "impulse" выражает m*v, поскольку в карте-примере из поста масса фактически не имеет значения (видимо, просто забыл удалить её из кода) и её хранение отдельным используемым скаляром приведёт только к увеличению числа рассчётов; при увеличении функционала, например, при добавлении взаимных столкновений, массу нужно будет вынести из вектора в отдельный скаляр, а вектор назвать "velocity". Показанная карта-пример, конечно, не лучшая из возможных, но, на мой взгляд, вполне адекватна (если оставить за скобками утверждение о полноценности модели в ней).

Попробую популярно пояснить лежащий в основе архитектуры подход.

Физический объект является описанием поведения игрового объекта (behavior; VisObj и DmgObj - тоже behavior по сути), он содержит в себе только те данные, которые касаются непосредственно связанного с физикой поведения игрового объекта (определение и движение объекта в пространстве), и никаких более. Этими данными являются: радиус-вектор, вектор импульса, радиус столкновений и логика движения. Последнюю в теории можно вынести из объекта, но тогда система несколько потеряет в модульности. Кроме того, хранить логику движения внутри метода полезно тем, что в случае её отсутствия/отключения у какого-либо объекта код движения даже читаться не будет.

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

Сам игровой объект - оболочка, через которую связаны все его компоненты. Система обработки ("стак" в GameField) обращается к нему с командой на апдейт, все взаимодействия между компонентами производятся в нём и нигде более.

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

В карте-примере отсутствует преждевременная оптимизация. Ощущение её наличия могло возникнуть из-за того, что данные, которые никак не задействованы в логике примера, были удалены из неё целиком. Массу вот только пропустил.