Евгений Шатунов

В такой постановке вопрос тянет уже на полноценную разработку игр. И суть вот в чем.

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

Это все должно работать слоями. Параллельно существующими математическими моделями. Параллельность существования тут означает только то, что между собой модели явным образом не взаимодействуют, но обмениваются результатами своей работы через свойства и атрибуты объектов игры, модифицируя их во время своей работы.
Вот у тебя уже есть какая-то модель отображения мира. Тебе надо просто рядом реализовать параллельную модель обработки столкновений.
В этой модели у тебя должны быть подвижные акторы и коллизионная геометрия. Для твоего случая достаточно это все посчитать на CPU в отдельной функции. В качестве геометрии коллизий можно взять прямо те же данные вершин, которыми ты рисуешь мир. Данные акторов можно взять прямо там, где готовятся позиции инстансов капель.
Сама модель обработки столкновений - это набор математических формул из уроков геометрии в средней школе.
Есть капля, с момента прошлого такта она пролетела какое-то расстояние. Проверяем пересечение капли с геометрией дома и генерируем событие столкновения когда оно зафиксировано.
Для капель неподвижным можно даже человека считать.

Ровно так же у тебя может существовать и еще одна модель - модель обработки физики, которая правильно посчитает движение капель с учетом ветра и гравитации. Еще эта модель у тебя может быть задействована для расчетов прыжков и падения персонажа.

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

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

Для поиска пути в таком дискретном пространстве стоит обратить внимание на алгоритмы поиска в ширину и в глубину.
Начать стоит с поиска в глубину. Его легко сделать и так же легко понять его неоптимальность. От поиска в глубину довольно легко перейти к поиску в ширину.
Алгоритмы поиска в ширину и в глубину дадут первичное понимание теории построения маршрута.

От поиска в ширину можно перейти к эвристическим алгоритмам поиска: A* или поиску по наилучшему совпадению.
На этом этапе еще полезно познакомиться с алгоритмом JPS. Он может стать даже выгоднее обычного A*.

A* должен стать для тебя основным инструментом поиска в дискретном пространстве. Но у A* есть проблема большой сложности поиска прямого маршрута.
При поиске пути по прямой лучше всего использовать алгоритм Брезенхама.
Этот алгоритм используется для рисования пиксельных примитивов. В частности - прямых.
И суть должна быть в том, чтобы сперва путь искать через Брезенхама по прямой от точки старта до точки финиша, а если Брезенхам наткнется на препятствие, то уже перейти к поиску через A*.

Для очень больших дискретных пространств есть варианты иерархического A*: HPA* и HAA*. Они применяются на иерархических дискретных пространствах вида открытого мира. В освоении они являются самыми сложными и самыми интересными.

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

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

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

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

Первый способ популяризирует публичные универсальные инструменты разработки.
Второй способ эксплуатирует проприетарные инструменты.

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

DirectX, Vulkan и OpenGL, равно как Metal и ряд проприетарных GAPI некоторых закрытых платформ, не являются графическими библиотеками. Это все - Graphics Application Programming Interface - GAPI.
Это - низкоуровневые интерфейсы драйвера GPU, позволяющие эксплуатировать ресурсы видеокарты в своих целях. Не только для рисования чего-то, а для ИИ, ML, сложных статистических вычислений, предсказаний и прочих расчетов на больших объемах данных.
Под капотом любого инструмента, будь-то проприетарный или публичный, в его графическом слое используется один или несколько GAPI. Без этого никак.
OpenGL, как и DirectX 11, нисколько не устарели, поскольку предоставляют упрощенный интерфейс управления ресурсами GPU. Они используются тогда, когда разработчикам не нужны самые тонкие механизмы управления ресурсами GPU, которые предоставляют DirectX 12 или Vulkan. Потому что последние, помимо прочего, требуют от разработчиков более глубокой экспертизы и больше ресурсов на разработку всего того же, что на OpenGL и DirectX 11 реализуется меньшими силами и за меньшее время.

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

Информации по каждой отдельной области разработки игр хоть отбавляй. Ее настолько много, что одному человеку за жизнь не усвоить. Поэтому от современного специалиста сегодня требуется спрофилироваться, т.е. определиться со своим профилем работы и стать экспертом.
Я больше 15 лет занимаюсь разработкой игровых движков и медиаферймворков. Более 10 лет занимаюсь коммерческой разработкой кросслпатформенных инструментов. Я начинал свое обучение по книгам и документации для всех интересующих меня областей еще 20 лет назад. Я самостоятельно освоил множество API, включая графические, сетевые, звуковые и API целевых платформ, используя книги и документацию. Экспертные знания C++ и прочих языков я получил тоже через изучение документации, стандартов и книг.
Я могу сказать что обучаться по книгам и документации можно и самостоятельно. Еще можно заплатить деньги и получить более точечные знания через их интерпретацию на распространенных сегодня онлайн-курсах. Такие знания не всегда бывают лучше полученных самостоятельно, но времени на освоение того же объема знаний на курсах уйдет меньше чем при самостоятельном изучении. Иными словами, занятия на онлайн-курсах не отменяют важности самостоятельного изучения основных источников информации.
По открытым видеоурокам на ютубе и прочих видеохостингах обучаться нечему. Цель этих видео - чтобы зритель посмотрел рекламу и этим принес доход автору.

Решением вопроса будет скалярное произведение двух векторов. Операция еще называется Dot Product.

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

В качестве бонуса.
Чтобы определить направление вращения, можно воспользоваться векторным произведением, еще называемым Cross Product.

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

Низкий порог вхождения для C++ и Vulkan означает продвинутый уровень владения инструментом C++, экспертные навыки обработки графики, работы с шейдерами и управления памятью GPU (да, там все иначе). Для входа в работу с Vulkan нужно быть, как минимум, Middle Graphics Engineer и уже уметь уверенно работать с DirectX11 или OpenGL4.5. Без этих знаний вулкан будет очень сложно понять, а правильно работать с ним получится только через десятки и сотни полностью неудачных итераций написать одно и то же.

Vulkan является очень низкоуровневым GAPI и требует от пользователя изначально серьезной подготовки. У этого GAPI много точек привязки к системной памяти, содержимое которой трактуется как на GPU, так и на CPU. Поэтому работать с памятью в C++ правильно нужно уметь с самого начала. Поэтому, еще до начала работы с вулканом от пользователя требуются экспертные знания языка. В противном случае вместо обучения работе с довольно сложным GAPI получится блуждание по полю граблей, где ничего не понятно.

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

И тем не менее, вулкан легко не дастся. Для его понимания нужна база, нужно знать устройство GPU, принципы коммуникации с ним, принципы его работы и всю теорию обработки графики. Нужно уже уметь быстро писать много стабильного и сложного кода на C++, нужно уметь безошибочно писать на GLSL или SPIR-V. Нужно уметь пользоваться графическими отладчиками, профилировщиками, разбираться в диагностике проблем при работе с графикой.
Все это приобрести можно в процессе практики с DirectX11 и OpenGL4.5.

Без вышки работать можно не только в геймдеве. Вообще везде можно работать. Это иногда даже негласно приветствуется.
За такую работу можно даже получать некоторые деньги, которых будет хватать на жизнь.

Я работал с несколькими самородками. Эти ребята - реальные спецы своего дела. Вышка им бы только мешала в их работе, оттягивая на себя их реально ценное время. Они многого добились и продолжают добиваться. Это такие немного особые люди. А для всех остальных людей без образования будут мои следующие строки.

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

Оттарабанить 4-6 лет, вытягивая лямку нормативов на экзаменах без четкого понимания требований к тебе - это пустить деньги и время на ветер.
В ВУЗ нужно идти за обучением самоконтролю, за обучением самодисциплине, за обучением самоорганизации. Вот те самые навыки, которые сегодня дает ВУЗ. Диплом магистра, бакалавра или специалиста - это дополнительный бонус. Разовьешь эти навыки самостоятельно - станешь одним из точно таких же самородков.
В ВУЗ стоит идти за трамплином к знаниям. Чаще всего человека надо только подтолкнуть чтобы он стал специалистом. А толчком таким и является программа базового обучения в ВУЗе. Обучение базовое потому что его для последующей работы все равно хватать не будет. Дальше с этого трамплина нужно рвать во весь опор, находя и усваивая самые важные и самые нужные для своей работы знания. Осилишь найти все эти знания сам - ну чтож, ты один из немногих способных.
По окончании ВУЗа человек не выпускается готовым к работе. На этом этапе он обладает только самыми базовыми навыками и дальше нужно продолжать учиться по профилю работы. Для этого есть стажировки, квалификационные курсы, а так же разнообразные книги и циклы статей для самостоятельного обучения.
ВУЗы не готовят людей к работе, ВУЗы готовят людей к самостоятельной профессиональной подготовке.

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

Компьютерная графика - очень большая и сложная область. Обучаться до конкурентного уровня нужно очень усердно и очень долго.

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

Куда двигаться дальше. В инженерию П.О, в архитектуру П.О, в шаблоны проектирования, в общие концепции разработки программ. Языки программирования на этом этапе все еще не нужны, т.к. архитектура оперирует терминами над инструментами разработки. В наше время очень много талантливых и образованных разработчиков компьютерной графики, но их ярким отличием является абсолютная бездарность в инженерии и архитектуре П.О. Они считают что раз математику и физику знают, то остальное им не нужно. Это должно стать их фатальной ошибкой в конкурентном плане. Сегодня системным инженерам приходится за такими людьми хвосты чистить и слушать их брюзжание о том, что их прелестный код снова испорчен и ничего опять не работает.

После этого двигаться стоит в сторону инструментов разработки. Их должно быть несколько. C# и F# ты знаешь, это хорошо. Java будет прекрасным дополнением. Настоящий инженер не имеет права зажимать себя рамками одного лишь инструмента, это будет его минус в конкуренции. Rust слабо востребован и мало применяется, но знать его на некотором уровне будет просто полезно в качестве инвестиции и для общего развития. C++ сильно распространен и сильно востребован, однако рынок труда сейчас переполнен слабыми середнячками, которые мало на что годятся в реальной работе, а C++ является крайне сложным инструментом и не позволит тебе быстро начать с ним работать на том же уровне, на котором тебе позволяет тот же C#. Поэтому если брать C++, то уходить в него надо прямо очень серьезно для того чтобы получить конкурентное преимущество перед описанными выше людьми.

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

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

Инструмент всегда выбирается от задачи.

Первым делом нужно строго сформулировать для себя задачу. Чего ты хочешь добиться?
Сделать игру? Это не задача. Заработать денег на игре? Это не задача.
Задачу надо детально формулировать. Например: сделать игру по уже имеющемуся ТЗ в конкретные сроки и с затратами не выше заданного бюджета.

Исходя из задачи выбирается инструмент.
Разные инструменты предъявляют разные требования к профессионализму разработчика, бюджету и времени разработки. Разные инструменты влекут разные риски для процесса разработки.
Выбор инструмента заключается в сведении проф. навыков, бюджета, времени и рисков в одном месте.

Unity позволяет вести быструю разработку при минимальной квалификации, но влечет риски быстрого изменения системных требований и непредвиденных сопутствующих расходов в местном "магазинчике радостей". Плюс, в определенный момент потребуется заплатить немалые деньги за лицензию.

Чистый C# требует профессионализма и большого времени на разработку. Профессионализм требуется сразу довольно высокий. Человек должен не только языком владеть, но и быть в состоянии выбрать подходящие сторонние библиотеки для помощи.

Чистый C++ требует экспертного уровня профессионализма и, буквально, огромного времени на разработку. Незначительного уменьшения времени на разработку можно добиться покупкой сторонних инструментов за довольно большие деньги. Более того, экспертный уровень требуется не только в знании C++, но и в знании сопутствующих разработке игры областей. Математику, звук, графику, сеть и каждую из целевых платформ требуется тоже знать на экспертном уровне. Иначе выбор чистого C++ будет проигрывать выбору чистого C#.
Современный C# после сборки по своей производительности ничем не отличается от результатов сборки C++, а разработку на C++ вести значительно сложнее.

Более того, использование чистого инструмента всегда требует от пользователя экспертного уровня знания архитектуры ПО.

Самым простым решением для разработки именно игры будет взять Cocos2d-x, Defold или Godot.
Это уже готовые решения для разработки игр на различные платформы, в том числе и на Android.
Все движки предоставляют инструменты именно для С++, в отличие от SDL.

SDL выполнен на языке C и не является подходящим в контексте разработки на C++.

Если есть желание заняться именно разработкой движка, а не игры, то вместо SDL стоит взять SFML, который выполнен уже на C++ и является довольно хорошим фреймворком. На базе SFML можно довольно быстро сделать небольшой движок для небольшой игры.

Много решений подходит под такие критерии. Смотри, изучай, выбирай.

Cocos2d-x является одним из самых популярных открытых движков. У него большое сообщество и масса поклонников. Есть документация и все нужное для старта.

Defold является еще одним очень популярным кроссплатформенным и открытым решением для разработки 2D игр. Сообщество тоже очень большое, документация и уроки для начинающих тоже на месте.
Defold часто выбирают в качестве решения для своей первой игры. И этот выбор далеко не случаен.

Godot Engine не менее популярен и не менее поднят по возможностям. В чем-то Godot даже будет лучше чем Cocos. Сообщество у него тоже большое. Документация тоже присутствует.

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

Дальше пойдут не такие популярные решения, однако и проходить мимо них тоже не стоит.

Urho3D является нареченной Open-Source альтернативой Unity. Движок используется многими энтузиастами. По разным уголкам сети раскиданы многочисленные группы обсуждения этого движка. Документация и примеры у него на месте.

GDevelop - это довольно популярное решение для небольших игр. Документация на месте.

Panda3D - тоже довольно популярное решение со своим сообществом. Документация имеется.

Hazel Engine - один разработчик - один движок. Полностью вся разработка изложена в видео на youtube. Пользоваться можно... на свой страх и риск.

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

GZDoom - современная инкарнация движка DOOM.

Дальше решения пойдут или сложные, или экзотические. Всё на свой страх и риск.

CryEngine - от Crytek.
X-Ray - движок S.T.A.L.K.E.R.
UE 3 - для коммерческих проектов использовать нельзя.
Lumberyard - от Amazon. Да-да, тот самый.
Banshee Engine - он просто существует.
Diligent Engine - у него есть свое сообщество.
Atomic Engine - на нем тоже выпускают игры.
Lumix Engine - тоже что-то может.
Horde 3D - просто существует и этого уже достаточно.

Существует семейство алгоритмов под названием Convex Hulling, позволяющих с требуемой точностью обернуть изображение в примитив.
Полученный контур примитива уже можно использовать для заполнения коллайдерами, тоже с требуемой точностью.
Для заполнения примитива коллайдерами может подойти алгоритм из семейства Bin Packing. Они позволяют учитывать перекрытие и неточность заполнения контура.
В результате, при подборе реализаций и при подстройке критериев ты можешь получить результат, сравнимый с приведенными на изображениях.

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

Коротко о разрушаемости в Noita излагается в презентации разработчиков на GDC.
Детальное описание разрушаемости в Jelly in the sky от автора игры: [1], [2], [3].

В Червяках же реализация разрушаемости довольно простая.
Мат. модель уровня состоит из битовой матрицы (где поднятый бит является заполненным, а снятый - пустым), и набора функций рисования в этой матрице. В этой битовой матрице изначально генерируется уровень и эта битовая матрица модифицируется в процессе игры. Функции рисования являются стандартными - это рисование линии от точки и до точки с заданной шириной, а так же рисование залитой окружности. Само рисование происходит нулевыми битами.
По своей сути Червяки являются таким замысловатым редактором для рисования.

Инструментов для решения такого вопроса очень много.
Методика решения всегда одна: необходимо выбрать и интегрировать в свой проект скриптовой движок.

Вопрос выбора скриптового движка является очень сложным и зависит от множества неочевидных критериев. Ответ на такой вопрос сможет дать только опытный инженер, неоднократно имевший дело с разными скриптовыми движками. Потому что даже между Lua, LuaJIT и Terra разница по функциональности и особенностям интеграции является очень существенной.
И, тем не менее, я этот вопрос оставлю открытым. На крайний случай всегда можно взять простой и легкий Lua, если глаза разбегаются, а решения нет.

Как производят интеграцию. Например - так, так, так, так, так или вот так.
После интеграции скриптового движка в свой проект, функциональность своего проекта можно прокинуть на сторону скриптов используя непосредственно API скриптового движка.

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

Одним компонентом и одной системой в таком случае не обойтись. Когда затронуто произвольное количество иных компонентов, связывать их все с каким-то одним компонентом - это зарывать ECS обратно в землю.

Почему дизайн с одним компонентом обречен. Каждая система в ECS должна работать с выборкой по компонентам. В EnTT это делается с помощью представления потока компонентов - entt::registry::view.
Такое представление оптимальным образом организует последовательность сущностей, в которых точно присутствуют обозначенные в представлении компоненты. Если начать проверять наличие у сущности иных компонент, помимо того что это противоречит концепции ECS, это затронет выборку из памяти за пределами отображения и сильно снизит производительность системы. Поэтому системе не стоит работать с компонентами за пределами своей выборки.

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

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

Функции интерполяции у тебя всегда чистые, т.е. зависят только от переданных им аргументов. Для любого типа данных, от скаляра и до матрицы, можно определить функцию интерполяции между двумя значениями. Это все - внешние относительно ECS вещи, а внутри ECS на каждый ***InterpolationComponent у тебя будет своя система, которая делает выборку по целевому компоненту и по компоненту интерполируемости. Таким образом, уже на стадии выборки компонентов у тебя останутся только подходящие сущности, а все остальные - отфильтруются.
Заметить стоит еще то, что такой подход позволяет одно конкретное значение интерполировать только одной функцией за раз. Если для одного значения требуется несколько одновременных интерполяций, такой подход уже не подходит. С другой стороны, для того чтобы правильно свести несколько таких анимаций для одного значения, требуется значительно более сложная система, чем просто функция интерполяции.

C++ не является полноценно "родным" языком для Android. Но для этой платформы можно вести разработку на C++.
Такие движки, как cocos2d-x [?], Urho 3D [?], Unreal Engine 4 [?], Godot Engine [?] и, буквально, море менее известных проектов, позволяют вести разработку игр с использованием языка C++.

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

Если использование C++ для тебя является важным, о Unity можно забыть. Это взаимоисключающие инструменты.
И это не важно. Тот же Urho 3D позиционируется как Open Source Unity. Godot Engine обладает не меньшей свободой и гибкостью, но предлагает больше.

Самой главной ошибкой начинающих работать с ECS людей является попытка засунуть в ECS сразу и вообще всё.

У тебя игра по типу монополии. Что есть в монополии?
В игре заявлены игроки, дискретное поле, активы и события. Еще могут быть заявлены дополнительные правила.
Игроки и активы имеют свои эффекты и могут быть деактивированы событиями. Собственно, это и есть сущности игрового ECS-мира.

И тут важно понять, что не сами игроки и активы являются сущностями ECS, а лишь свойства игроков и активов являются сущностями.
Сами игроки являются внешними к ECS, для каждого игрока в ECS заводится сущность, идентификатор которой сразу прикрепляется к объекту игрока. Теперь игрок может взаимодействовать с миром игры через данные своей сущности. Точно так же делается и для активов.

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

По своей сути, в монополии ECS будет выполнять задачу документооборота между сущностями. Добавить компонент владения, убрать компонент владения, зачислить деньги, списать деньги, добавить компонент активности, убрать компонент активности. ECS управляет только общими свойствами между полностью обезличенными сущностями, где между игроком и купленным им активом нет фактической разницы.
Механизм перевода хода тоже является полностью отдельным от ECS, он может только опираться на набор компонент игроков и данные компонент.

ECS является подходом декомпозиции не только логики и данных, но и подходом отказа от агрегации и наследования в пользу косвенной композиции. Явной композиции в ECS тоже не предусматривается, а косвенная композиция не намекает на связность или структурированность данных. Косвенная композиция обозначает только наличие каких либо данных по некоторым косвенным признакам.
Более того, в рамках ECS сторонний код и с данными нормально работать не способен. Для стороннего кода в ECS предусматривается уровень абстракции для чтения и записи данных.

Это все должно говорить о том, что ООП возможно применять только рядом с ECS и отдельно от ECS, но не вместе с и не внутри модели данных ECS.

К примеру есть сущность игрок с набором компонентов наследованная от Entity,

Нет, это сразу будет не ECS. Сущность игрок - это и есть entity, являющаяся эфемерной единицей в мире ECS.
И методов у entity быть не может. Вся логика сущностей распределена по системам и сильно зависит от имеющихся у сущности компонент.
Более того. Если ты говоришь о том, что в твоем мире может существовать сущность с характеристикой игрока, таких сущностей в твоем мире может быть до 100% всего ECS мира. Если игрок у тебя должен быть представлен единичной сущностью, значит это уже не сущность, а внешний объект, по ошибке введенный в ECS мир.

В ECS базовым правилом является то, что в любой момент времени любая сущность может получить или утратить любой компонент.

Про состояния, пустые компоненты добавлять удалять в entity как флаги что сущность в каком либо состоянии, и отдельные системы для обработки каждого состояния это нормальный подход ?!

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