Создание аркады InfinitySpace, часть 3⁠⁠

Текущий проект,конечно, вряд-ли стоит перетаскивать, чтоб не терять уже наработанное время,  но на будущее, очень советую, да.

Если планируете развиваться и дальше в мобильной разработке, то вам придется в любом случае выучить еще один язык. А может даже и не один. Прошу, не сочтите мои слова за менторство или попытку вас обидеть, но я уже много лет занимаюсь разработкой под мобилки, и знаю о чем говорю. Поэтому прошу отнестись к моим словам внимательно.

Я не зря предложил Flame.  он построен поверх гугловского фреймворка Flutter, который позволяет легко и просто писать мультиплатформу на все мобилки + веб. Конечно, для этого придется изучить Dart, но это простой Java-подобный язык, при наличии даже небольшого опыта работы с Java/C++ он легко осваивается.
Бонусом пойдет то, что вы сможете работать и с самим Flutter-ом, который благодаря поддержке гугла работает "из коробки" даже на грядущей Фуксии (он кстати пока единственный, кто поддерживает разработку под нее), которая, как говорит Гугл, рано или поздно заменит привычный нам андроид.
А ведь Flutter- это настоящее RAD-средство для разработки приложений на мобилки., и уметь под него писать -очень полезный скилл.
libgdx настоятельно не советую. Вместо написания игры, будете заниматься написанием движка :)

Когда вижу классы написанные на Lua, аж вздрагиваю. Зачем? Если так нравится ООП, зачем использовать Lua? Есть куда более приспособленные для ООП языки.
Вся прелесть Lua какраз в том и есть, что нет никаких классов, всё -таблицы, и код собирается через композицию. А вы пытаетесь, фигурально выражаясь, удалять гланды через задницу, и при этом жалуетесь на костыли.
Если так хочется ООП и шустрый 2Д движок на мобилки - берите что-нибудь типа https://flame-engine.org  и не мучайтесь.

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

наоборт - это проще чем вычислять пересечение площадей фигур, для примера, как ты определишь что попал в круглый метеорит?

Был бы у вас какой open game art... Или гугл с креатив комонс на крайняк.

Вам бы заодно в меню графику перебабахать...

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

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

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

не трать на графику время, все эти "а может еще поярче" выжирают все время, удобнее использовать пустышки/примитивы - у объектов четко видны границы. разрешений хоть и много но пропорции везде одни и те же  : 2к1 и 3к2 (2340x1080,  1920x1200) т.ч.делай 2 комплекта спрайтов и масштабируй. при написании таких игр траблы могут быть только при использовании гироскопа или с активным дрочем мультитача, в остальном все как и на пк.