Дмитрий Александров

Не совсем понятно жанровое направление. Без программирования сейчас никуда, но есть исключения в виде конструкторов.
Из крупных:
1) Unreal Engine 4. Максимально удобный с отличным инструментарием, вместо кода можно использовать BluPrint(визуальный конструктор логики).
2) Unity тоже подходит но без знания С# ловить особо нечего.

Из конструкторов:
1) FPS Creator, максимально простой конструктор для игр в жанре FPS.
2) RPG Maker, тоже что и п1 но для RPG.
3) Не шибко популярный у нас Kodu от MS, как по мне идеальный вариант для прототипирования и обучения.
4) Еще менее популярный у нас spark game engine, лично мое мнение что это идеальный вариант для творческих людей, код писать не надо, все визуально и интуитивно. Смотрел его, остались очень приятные впечатления.

Из интересных и требующих кода:
1) LibGDX, очень классная и хорошо документированная либа но писать придется много.
2) JMonkey engine, тоже что и п1 но с инструментарием и множеством дополнительных фич.
3) Cocos2d, аналогичен LibGDX только в профиль.
4) love2d, очень крутая штука с очень низким порогом вхождения в кодинг. Все на Lua скриптах.

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

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

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

PS вообще вопрос очень абстрактный и без живых примеров которые будут просто огромные сложно дать простой ответ "вот как это происходит".

Т.к. в тегах игра для примера оттолкнемся от апдейтов.
Предположим что у вас игровая логика апдейтится 60 раз в секунду.
Мы знаем стартовые точки, направление и ускорение у обоих точек ("А" и "В").
Предположим что движения вы тоже апдейтите вместе с логигой 60 раз в секунду(просто такое обычно вяжут по своему и может быть не 60 а меньше или наоборот больше).
Зная все вышеперечисленное делаете все по шагам опять же для примера и понимания:
1) Найти абстрактно точку пересечения без учета времени "С". Если такой точки не существует значит остальные пункты пропускаем.
2) Самым обычным циклом произвести вычет сколько времени потребуется точке "А" для достижения точки пересечения "С" с учетом скорости и направления.
3) Повторить пункт (2) для точки "В".
4) Сравнить результаты полученные на шаге (2) и (3) и если они равны значит точки пересекутся.

А где обновление физики? Где .dispose() шейпа который после передачи в фикстуру уже ненужен? Самое главное, где Exception? Телепаты в отпуске.

На С++ писать сложнее чем на джаве. Наговнокодить можно на любом языке и будет очень медленно и прожорливо, по потреблению ресурсов впринципе потеряете не так много если сравнивать java vs c++, если конечно не будете в рекурсивном цикле создавать миллиарды строк текста.
В любом случае, как писали выше, язык это дело вкуса и серебрянной пули несуществует вообще. Игры можно писать на готовых движках. Скажем если выбор падет на юнити то тут балом правит C# и JS. Если выберете Unreal то С++ или скриптовый блюпринт. Если же выберете путь писать двиг самому особенно для мобилок то тут будет адская смесь явы и с++. Если возьмете некий "полудвижек" или фреймворк то там вас привяжут к конкретному языку или скриптовому языку. Кроме того на каждой платформу правят свои языки и кроме того их может быть много. На андроиде это java и намного реже с++(в основном гемор из за невероятного числа костылей) или примеси html5. На IOS это objective-c и swift и так же иногда с костылями html5. На Windows С++\С\С# и реже все остальное, на маках objective-c в основном, на линуксах С++\С\Mono\Java\Python\Perl\Lua\NodeJS\Go и еще туча другого добра. Если же пишут многопользовательскую игру то сервера очень часто пишут на питоне\го\джаве\ноде.
В общем если желаете нацелиться на максимально возможное с минимальными затратами то начинайте учить джаву или с#(эти языки очень похожи и выучить другой будет легко) а дальше берите фреймворк или готовый двиг и творите. Задумывать о том что тот язык медленный\прожорливый\etc Вам не имеет смысла вообще никакого т.к. абсолютно все языки примерно одинаковы по скорости если их "хорошо готовить" и основная разница только в следующем:
1) Сложность синтаксиса языка.
2) Скорость изучения языка.
3) Сложность изучения языка и его принципов.
4) Скорость написать программы.
Обобщенный пример: Java или C# очень простые языки и можно уже через пару недель писать довольно серьезные программы но они будут медлительны по одной простой причине, для того чтобы понимать что вот это медленно и надо писать по другому пройдет очень много времени и стажа т.к. многие моменты коварно абстрагированы в недрах VM. Ситуация с С\С++ другая, языки в 10ки раз сложнее особенно новичку, для написать сколь нибудь сложной софтинки придется усиленно изучать язык пол года и больше но за счет необходимости читать и понимать и большего времени изучения у вас изначально код будет быстрее просто потому что уже будет хоть небольшое но понимание почему так медленнее а так быстрее и почему так ресурсов кушается больше а так меньше. То же самое относится и к переносимости языка на другие платформы, джава сильно абстрагирует api от железа и OS и программист просто пишет 1 код и он просто работает везде где есть джава. На С++ огромное число граблей при переносе софтины с win на линуксы и наоборот, почти весь код который как то работает с OS или железом придется переписывать заново. Ну и про скорость написания софта, java\c# сильно впереди, чужой код в сотни раз проще понять чем чужой код на с\с++, программист думает именно над алгоритмом исключая думы над тонкостями работы с памятью и т.д.
Выбор полностью за вами =D.

Начните с просмотров юмл диаграмм (в гуглокартинках "game uml diagram"), дальше когда будет общее представление выцеплять определенные темы и читать уже конкретно про них.
Хотя на практике вам такие знания врядли потребуется из за наличия готовых движков.

А что Вы хотите узнать от движка которому 3 дня от роду?)

UE4 Blueprint, вот я умею жарить яишницу и варить пельмени, смогу ли я пойти работать поваром в крутой ресторан? =D
Блюпринт годен только для прототипирования игры на коленке за пару вечеров.
С++ изучить меньше чем за пару лет с частой практикой вряд ли сможете.
Лучше опирайтесь на движки попроще, юнити к примеру и изучайте js или c# в нем, входной порог ниже и учить их в разы легче.

Пишете сами себе ТЗ. Если за месяц и меньше сумели собрать прототип игры с большей частью фич из ТЗ(как правило основная идея игры, ее изюминка) то продолжайте разработку. Сами поймете какие темы надо подтягивать и штудировать.
Пытаться что то делать сразу для мобилок очень плохой вариант т.к. это на порядок сложнее.
UE4 или любой другой двиг в связке с С++ вообще ошибочный вариант, 95% что забьете на это очень быстро. Лучше начинайте с какого нибудь FPS\RPG\GAME Maker или тучи других движков которые больше ориентируются на визуальную часть и простейшие языки типа бейсика, есть еще неплохой "Лаборатория игр Kodu" от MS.

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