kk95

Мне не очень нравится идея давать советы людям, о которых я ничего не знаю, но если вкратце, то я считаю, что отец прав.

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

Однако, это всё применимо если вы действительно готовы учиться. На той же прикладной математике халявы не будет.

Есть волшебный метод, который называется "декомпозиция". Мои наблюдения говорят, что 80% людей им просто не владеют. От слова - вообще. Ни в профессиональной, ни в обыдиной жизни. Но вот те, кто объясняют доходчиво - владеют им виртуозно.
Заключается он в следующем. Если надо что-то объяснить, и это что-то чуть сложнее таблицы умножения (но и ее кстати тоже), задачу можно всегда разбить на части, из которых компонуется готовое решение. Вы должны на первой "итерации" объяснить ответ "с птичьего полета", как последовательностей этих самых подзадач, без углубления в детали, без подробных выкладок, что называется - "на пальцах". Причем, конечно, на языке понятном и воспринимаемом партнером. Когда (и если) он поймет вашу идею, поймет шаги - начинаете углубляться в объяснение конкретных подзадач. Вот тут уже начинаете использовать меньше "его" терминов, больше "своих". В какой-то момент он начинает сам понимать и самостоятельно додумывать решения. Тогда переходите к следующей подзадаче. Конечно, каждую подзадачу часто можно (а иногда - для очень сложных задач - и нужно) декомпозировать дальше. И так до того момента, когда вы можете объяснить полностью.
Тогда вы и сами понимаете "roadmap" вашего объяснения, не теряете нить рассуждений и не сбиваетесь, и партнеру легче выстраивать "цепочку понимания", следя за ходом объяснения и сразу понимая, где именно он перестал улавливать мысль. Разумеется, при этом очень важно, что-бы собеседник был заинтересован в том, что-бы получить от вас объяснение, а не просто спросил чтобы "а поговорить".

Если у тебя есть интерес к математике и ты любишь логически рассуждать, то основы программирования тебе дадутся легко. В любом императивном языке программирования используются конструкции "если-то-иначе" и "повторять-до-тех-пор", то есть используются условия, которые могут быть "истиной" или "ложью". Остаётся только изучить синтаксис самого языка: где-то пишут if условие then действие end, а где-то if (условие) { действие } и тому подобное. То есть различия только в написании. Вот тебе основы программирования в двух словах.

Что касается разработки именно игры, то есть понятие основного игрового цикла. С точки зрения программирования - это обычный цикл "повторять-до-тех-пор", просто он не заканчивается до самого конца игровой сессии. Этот цикл делит игру на так называемые "кадры" или "тики", из которых и состоит игра. Каждый кадр - это отдельное состояние игры, которое соответствует отдельной итерации основного цикла. Тебе нужно придумать, каким образом одно состояние сменяет другое, как осуществляется переход, какие вычисления при этом производятся. Такой "кадр" обычно не соответствует кадру на экране (другими словами ход игры не зависит от FPS), хотя это уже отдельная сложная тема.

1. Язык выбирай в зависимости от того, какой движок или платформу будешь использовать. Не оглядывайся на другие игры. Например, Unity и соответственно C#.
2. Курсы, учебники, ютуб-каналы - без разницы. В любом случае ты потратишь какое-то время, и его не получится сильно уменьшить. То есть это прямая конвертация времени в знания и навыки без сильных колебаний курса цены этой конвертации. В целом, время будет зависеть от твоего начального бэкграунда (т.е. что ты знаешь и умеешь уже сейчас).
3. В программировании (да и в других областях) сложную задачу принято разбивать на части (декомпозиция). Сначала нужно изучить понятие игрового цикла, и как время будет течь в игре (или как время в игре соотносится с реальным, учитывая паузы и сохранения). Затем решить, в каком порядке и что там будет выполняться более детально. Однако любая мелкая игровая система всё равно будет достаточно сложна, и её снова нужно разбивать на совсем уж простые. А простые - снова разбивать на элементарные. Поэтому от умения разбивать зависит, закончишь ли ты программу (игру) или нет.
4. Сетевая часть - обычно самая сложная (и самая глючная), потому что для каждой своя оптимизация. В двух словах, устройства обмениваются сообщениями по сети, и эти сообщения могут пересылаться с разной скоростью, а могут порой вообще теряться в никуда. Клиент-серверная модель предполагает, что есть некое главное устройство (например, ты арендовал сервер в дата-центре), к которому подключаются все остальные (т.н. клиенты). Но вот как будет реализовано взаимодействие, контроль ошибок, чтобы не глючило, вот это уже зависит от самой игры.

С железом на ты. Прекрасно понимаю как всё работает и мне это нравится

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

. Английский знаю на базовом уровне.

Понравилась веб вёрстка (на парах в унике учили) и тоже считаю что это интересно

На мой взгляд, ты выбрал самое простое, поэтому оно тебе нравится. Потому что насчет железа - есть сомнения, что ты реально понимаешь как работает L3 кеш процессора, или чем USB 3.1 отличается от USB 3.0
Тут лучше уточнить что именно ты подразумеваешь что ты с железом на "ты".

Учи английский. Не школьную программу, а умение общаться.
Развиваться - в самостоятельность. Почему твою судьбу должен решать кто-то другой? Сам реши, не ищи легкого пути, просто приложи старание в выбранное направление. Звучит просто, исполняется сложно, но повторю - не ищи легкого пути, его нет.

Адблок.

Не доустановлен Quickfix

Обновите модификаторы, а потом устанавливайте модули