NubasLol

Все познается на больших проектах,
в качестве примера возьмем методику MVC опенкарта где есть три слоя абстрации:
1) если это запрос то для этого есть модель
2) если это что-то из пхп кода то это контроллер
3) если это хтмл то это шаблон
Парни почистили от мусора код и "выкинули" в свет. Все просто красиво и самое главное бесплатно и без смс.
Но, а теперь взглянем почему же все ненавидят опенкарт. А потому что разработчиками не предусмотрены моменты как можно расширять и кастомизировать код, и все пишут свои кастомайзы там где и предусмотренно, в контроллере и когда владельцы сайта начинают баловаться модулями то оказывается схожие по функционалу модули пытаются внедрить одновременно свой код в одно и то же место одного и тогоже контроллера и начинается чихорда когда одни функции используют данные которые будут получены двумя строками ниже или два разных модуля добавили свои параметры в стандартную функцию.
многие умники догадались что можно весь треш перевести в шаблон где уже все данные получены, и контроллеры и шаблоны начинают разрастаться когда 3000-5000 строк в одном файле это норм и не такое видали, сайт начинает глючить, найти ошибку или добавить свой кастомайз становится просто невыносимым, я еще молчу про ocMod или vqMod (но это уже другая история)
итог 3 версия опенкарта использует twig темплейты, где нельзя так просто "ворваться" со своим php кодом, но и основных проблем не решила.

Ну вот сломалась у тебя база данных. Ошибку выдаёт. Что будешь делать? Пол-шаблона то уже вывелось.

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

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

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

Cобери путь в контроллере, проверь наличие файла и верни тот который считаешь нужным

Можно воспользоваться panic/recover и модифицировать возвращаемые параметры(если все-таки нужно вернуть ошибку)

func myFunc() (err error) {
	defer func() {
		if r := recover(); r != nil {
			log.Println(r)
			internalhttp.NewJsonResponse().ErrorResponse(w, r)
			err = r.(error)
		}
	}()
	
	...
	
	if err := myOtherFunc(); err != nil {
		panic(err)
	}

	return
}

Скажите, что еще нужно добавить к этому и где можно прочесть как правильно подобрать комлектующие?

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

На основне 1070 и AMD Ryzen 7 2700.

Странно в основе указывать видеокарту.

Например, ITC делают сбалансированные сборки: https://itc.ua/articles/pk-mesyacza-iyul-2019/
Ну и ютуб.

В спецификации на гошку это описано.

In a case or default clause, the last non-empty statement may be a (possibly labeled) "fallthrough" statement to indicate that control should flow from the end of this clause to the first statement of the next clause

То есть, fallthrough передает управление первой строчке следующего кейса, не проверяя никаких условий.

Вступить в команду в качестве программиста или геймдизайнера. Учить тот язык, который потребуется. Мне кажется, что (настоящему) программисту выучить любой язык не проблема при желании и необходимости (разве что С++ может показаться излишне сложным, если выбрать его в качестве первого языка, но в качестве второго уже не так страшно).

Если самому собирать команду, то, скорее всего, придется забыть о программировании, т.к. других хлопот слишком много будет. И другие направления в геймдеве придётся долго и глубоко изучать, так что разумно будет программирование принести в жертву. И нужно будет чётко сформулировать, чем ваша игра будет выделяться, доказать это (хотя бы себе и команде), а потом повесить это в рамку в качестве иконы и всё время помнить об этом - ведь это то, что принесёт деньги. Абстрактная просто игра в вакууме прибыли не генерирует. Ну и всем остальным KPI тоже, конечно, уделять внимания в качестве управленца.

Хотя, если ваша цель сделать простенькую игру в одиночку, и прибыль с проекта вам не нужна, то можете взять любой игровой движок, тот же Unity, и просто начать что-то делать. А дальше уже в зависимости от степени вашей мотивации и вовлечённости, вы либо добьетесь высот в этом деле, либо бросите, поняв, что это не ваше.

PHP был выбран
как самый простой язык для начала карьеры

Известное заблуждение. PHP гораздо более сложен, чем думают неопытные веб-"программисты".

насколько логична моя идея войти в gamedev через бэк енд

Ну примерно так же логична, как идти в пилоты пассажирских авиалайнеров после сдачи прав на категорию "B".

Так же интересно, насколько глубокие знания математики нужны.

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

Без обид, хотите в гейдев - учите C#.

В интерфейс пользователя вклад выводится как заработанная сумма очков, делённая на 10 и округлённая методом floor (отбрасыванием дробной части числа).