Данил

Как построенн язык программирования, например: Как понять, как устроенны ключевые слова; Препроцессорные процессы: define, include и др.; - Я правильно понимаю, нужно опустится на ещё более низкий уровень до ассемблера? - Ассемлер является той фундаментальной сущностью в программировании (не считая машинный код, который и так человек не должен понимать)?

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

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

Любая программа - это просто алгоритм. Так что смотрим что делает программа и спокойно разбираем её алгоритм. А если есть исходный код - то вообще все полностью можно разобрать.

Ну и вообщем, какие-то фундаментальные знания - на чём базуется/построенна програмированние и IT, тоже не помешало. Например рекомендуют SICP почитать, правильно ли я тогда пойду или это не то. Если да, можете ещё набросать ваши варианты? Буду признателен.

Фундамент - бинарная логика. Над ней - процессорные инструкции или машинный код. Далее - ассемблер, минимально простая абстракция для составления инструкций для процессора. Следующий этаж - язык программирования высокого уровня, который в своем составе имеет какой-то типовой набор абстракций (переменные, функции, операции с памятью, блоки и разные типы данных), функций и алгоритмов для более человечного описания алгоритмов и для работы с данными. ЯП бывают разные и решают проблему в какой-то определенной области или для какой-то цели. Также существуют предметно/проблемно-ориентированные ЯП (DSL - domain-specific language) - более узкие решения. Дальше - стандартные и дополнительные библиотеки для упрощения работы с определенными данными, алгоритмами и прочее. Выше лежат фреймворки реализующие какой-то определенный каркас/функционал для реализации программ/алгоритмов для решения задач в рамках какой-то специфической области.

Оффтоп: денег в вебдеве как правило больше, особенно в РФ (но глобально - тоже). Если это не смущает, читайте дальше =)

С++, Linux, Verilog - это все хорошо, но я бы занимался этим после того, как поработаете какое-то время, и поймете, куда хотите расти.

Абсолютный must, имхо:

• Язык C. Это рабочая лошадка firmware, без него никуда, зато остальные языки - совершенно опциональны.
  
• Какой-нибудь простой ассемблер (сегодня я бы сказал, армовский). Не обязательно быть мастером, но очень помогает понять, как работает процессор в принципе.
  
• Скучная школьная теория: архитектура ЭВМ, устройство операционных систем, конечные автоматы - все это для эмбеддера куда более актуально, чем для веб-девелопера
  
• Электроника. Необязательно уметь спроектировать шестислойную плату с учетом EMC, но читать схемы - это важно. А также способность потыкать плату тестером или осциллографом (в большинстве случаев ошибка все равно в софте, но успокаивает).
  
• Стандартная периферия и интерфейсы: UART, I2C, SPI, DAC/ADC. Это до какой-то степени можно выучить и на ардуине, но лучше освоиться с настоящим железом
  
• Умение читать документацию на железо. Должно прийти при освоении предыдущих пунктов, если не ограничиваться копипастом из туториалов.
  

Если освоите до какой-то степени (главное - не увлекаться) этот набор, то можете работать в firmware. А дальше уже можете развиваться куда душа лежит, и где будут карьерные возможности - Linux, C++, электроника, DSP, whatnot.

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

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

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

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++ и прочих языков я получил тоже через изучение документации, стандартов и книг.
Я могу сказать что обучаться по книгам и документации можно и самостоятельно. Еще можно заплатить деньги и получить более точечные знания через их интерпретацию на распространенных сегодня онлайн-курсах. Такие знания не всегда бывают лучше полученных самостоятельно, но времени на освоение того же объема знаний на курсах уйдет меньше чем при самостоятельном изучении. Иными словами, занятия на онлайн-курсах не отменяют важности самостоятельного изучения основных источников информации.
По открытым видеоурокам на ютубе и прочих видеохостингах обучаться нечему. Цель этих видео - чтобы зритель посмотрел рекламу и этим принес доход автору.

Всё как и должно быть. Потому что не всегда C++ приложение можно просто так запустить на другой машине.
На тулчейне от Microsoft (очевидно, вы используете Visual Studio для разработки, т.к. недостающие библиотеки из текста ваших ошибок - это студийный C++ рантайм) при использовании динамической линковки рантайма нужно приложить некоторые дополнительные усилия, чтобы этот рантайм появился на другой машине (т.к. его там ещё может не быть - ведь рантайм для каждой мажорной версии студийного компилятора свой). Вы можете как установить рантайм централизованно, так и положить его рядом с вашим приложением. Ну или вы можете слинковать рантайм статически.

Задача, которую вам сейчас нужно решить, называется развёртыванием (deployment). Это абсолютно нормально, что вы столкнулись с необходимостью разобраться с этим, раз вы пользуетесь C++.

Нет лучшего источника информации по этой задаче в рамках тулчейна Visual C++, чем вот эта страница: en/ru. Разбирайтесь, и у вас точно всё получится - абсолютно в каждом C++ проекте production-уровня эта задача решается тем или иным способом. Возможно вам потребуется дополнительно разобраться, что это вообще такое за "рантайм" и почему он требуется для работы вашего приложения.