Артем Тарковский

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

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

P.S. Без CRT кода просто твой C/C++ код компилируется в то, что ты написал. Нет ни единой чужой строчки кода. Ты просто видишь, во что компилируется код и понимаешь что все компилируемые языки это просто упрощение жизни, а не изобретение чего-то нового. Все эти парадигмы все равно сводятся к языку ассемблера, какие бы они не были. Собственно, и интерпретируемые языки - это просто ассемблерный код, анализирующий текст и в зависимости от того че там написано выполняющий какие-то действия.

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

Не занесется, верно. Будет передаваться указатель на readonly секцию:

lea eax, [Адрес]
push eax
call foobar

В некоторых случаях если передается дело в указатель оптимизатор может оптимизировать в read-write секцию. В некоторых, может. gcc точно так не делает, поэтому модифицировать строковый литерал не модифицируя права доступа - не советую :)

Математика в gamedev нужна в любом случае. Даже если делается маленькая игрушка, то нужно хотя бы понимать, как работает пропорция...
Но вот вопрос - какой уровень математики нужен в gamedev.
TL;DR: очень желателен средний уровень (хотя бы уровень 11 класса).
Долгое объяснение:
1) Игру можно делать вообще без математики - движок берёт на себя сложную математику. Но чем больше игра, тем больше будет нужно понимание математики - математика может пригодиться при расчёте выстрелов, при расчёте "хитрого" поиска пути, обязательно пригодится в при разработке ИИ, и уж точно пригодится при расчёте баланса (но это работа гейм-дизайнера, а не программиста).
2) Причём, нужно именно понимание - не столько умение решать типовые задачки, сколько способность анализировать формулы придумывать свои. Например, какую-то фишку можно сделать несколькими способами, и вероятнее всего, более производительным будет тот способ, который лучше использует математику. Помимо обычной математики, может пригодиться геометрия. И уж точно пригодится булева алгебра.
3) Начиная с восьмого класса, в школе учат не только считать тривиальные задачки, но и развивают так называемое "математическое мышление". Особенно этому учат "задачки со звёздочкой" (более сложные, но необязательные, не знаю, во всех ли учебниках есть такие). Именно математическое мышление позволяет лучше продумывать алгоритмы. (N.B. рекомендую почитать Я.И.Перельмана с его "Занимательной математикой")
4) ААА-игры делаются не одним-двумя программистами, при разработке ААА-игр программистов используются десятки (а всего разработчиков может быть сотни, от гейм-дизайнеров до композиторов). Все из них не обязательно должны знать математику хорошо. Но если не знать, то вероятность развиться "повыше" - то сложнее.
5) При некоторых играх математика почти не нужна (при использовании приличного движка), а в некоторых играх математика точно нужна.
6) Программирование - техническая наука. Да, "гуманитарии" тоже могут стать программистами, но им будет сложнее. Ещё Ломоносов сказал: "Математика ум в порядок приводит" - в нашем классе математики в школе была такая картинка на стене. И я как учитель могу подтвердить эту мысль.

Итог.
Можно ли сделать игру без математики? Можно.
Математика поможет разработке игры? Почти наверняка.
Хочется развиваться хотя бы до сениора? Учи математику.

На официальном сайте unrealengine.com в разделе Learn есть пункт Video Tutorials:
https://wiki.unrealengine.com/Videos
Там есть видео-уроки по созданию простеньких игр в том числе и на C++.
P.S. на английском языке

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

AAA-проекты не пишут математики. Вам нужно знание sdk и умение программировать. А подкруткой физики, освещением, моделями и прочим займётся команда специальных людей в этом проекте. Равно как и сценарием, локациями, звуком... вплоть до того, что затюнят движок под нужды проекта.
Но всё же, если отвечать по существу: в этих движках 99% физики уже реализовано и вам математику не нужно знать вообще. Ну разве что на уровне понимания координат/векторов и всякого такого. Если нужно что-то сверх того, то вам необходимо знать математику очень хорошо. И не просто, а с умением разбираться или составлять нужные алгоритмы для машины.

Начать с https://unity3d.com/ru/learn и учебника по шарпу. Учебники ищите по вопросам тостера.

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

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

PC+Steam и браузер + HTML5 - очень разные платформы по монетизации и циклам разработки. Крайне разные. Если упрощённо, то браузерные HTML5 - это конвеер, берущий массовостью выпускаемых игр, Steam - это штучное производство оригинального продукта.

>где реальнее получить первые деньги и заработать?
С первого продукта нигде. Со второго скорее всего тоже. В этом плане HTML выглядит лучше, потому что путь в пару продуктов можно пройти за полгода-год, а в стиме за 2-3 года.

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

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

Про Gem:
Gem это есмъ библиотека, скомпанованная определённым образом. То есть это набор кода (модули, классы и тд), которые решают некоторую задачу.
Утилита gem занимается тем, что управляет этими библиотеками. Например 'gem install colorize' скачает с интернета библиотеку (далее "гем") в каталог, доступный для твоих программ (конкретное место зависит от настроек и способа установки Рубина). После чего ты сможешь в своём коде написать require 'colorize' и пользоваться методами, которые данный гем предоставляет. Гем может требовать для установки другие гемы.

Про Bandler:
Чтобы не ставить/обновлять гемы по-одиночке каждый раз, люди написали Бандлер (который сам является гемом). Работает это так: в Gemfile ты описываешь какие гемы тебе нужны (каких версий, где взять и прочее...). После чего запускаешь bundle install Бандлер проходит по твоему Gemfile и устанавливает (с помощью утилиты gem) нужные гемы, а также создаёт файл Gemfile.lock, в котором описывает что, откуда и почему он поставил. Это важный файл! храни его в репозитории.
Если сказать bundle update, то бандлер заглянет в файлы Gemfile и Gemfile.lock, проверит версии и установит гем последней доступной версии. Внимание! не обновит, а поставит новый! То есть старая версия останется.
Здесь мы приходим к команде bundle exec. Эта команда означает: выполнить нечто с помощью гема из файла Gemfile.lock. Внимание! в рельсе всё (пока не взматереешь) следует запускать через bundle exec! Это исключит конфликт версий. Например: bundle exec rspec, bundle exec rails db:migrate и тд.

Про Рельсу:
Посмотри в каком-либо рельсовом проекте bin/rails, там обычный рубиновый код: require_relative '../config/boot'
Смотрим в config/boot.rb: require 'bundler/setup' Вот тут подключается гем Bundler и далее (можно посмотреть по исходникам) вызывается Bundler.setup, который, в свою очередь, смотрит в файлы Gemfile и Gemfile.lock и подключает указанные библиотеки (с помощью require), после чего методы оных библиотек становятся доступны в проекте. Кстати, Рельса сама является гемом, точнее набором гемов.