NegroAzul

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

Да, как бы, ничего не мешает писать один С++ код для множества платформ. Почти весь мой трудовой стаж связан именно с разработкой кроссплатформенных игр. Я работал с несколькими (самодельными и не очень) движками и имею свое собственное детище, прекрасно и однозначно собирающееся на 5 целевых платформ (Win, Mac, Linux, ios, Android), к которым без труда можно добавить и консоли, и новые платформы.

Нет, вру, не без труда. Попотеть над слоем абстракции придется. Но попотеть придется только над ним, все остальное заведется само, т.к. изначально написано в стандарте C++, без расширений под конкретные компиляторы, и с применением ряда очень важных для кроссплатформенности подходов.

Кроссплатформенность подразумевает решение ряда вопросов, которые и выливаются в слой абстракции над операционной системой. Эти вопросы, зачастую, решать никто не хочет. Несколько раз встречал такое сам и еще мне рассказывали о том, как тот или иной движок сперва был только под конкретную ###, а потом решили портировать на @@@. Оказалось, что компилятор, которым всегда и собирали движок, нашпигован расширениями языка, которые конечно же все пользовали на 100%, и при смене компилятора ни один файл исходников не остался без доброй сотни ошибок. Т.е. переписывать надо было ВСЁ.

Mercury13 хорошо рассказал про Unicode пути к файлам. Drakonoved правильно подметил про разделители путей к файлам. Максим Гришин очень хорошо напомнил про порядок следования байт. Это все и есть часть этого ряда вопросов.
У каждой платформы есть свой API, которого не будет на другой платформе. Но на другой платформе будет свой API, со своими именами и схожей функциональностью. И работу с API надо абстрагировать от универсального кода.
Еще, на одной платформе у тебя может быть разомкнутый главный цикл обработки сообщений (Win), а на другой - замкнутый (Android). Надо подстраиваться. GUI везде разный, надо подстраиваться. Сама структура приложения на одной платформе может быть монолитной, а на другой - композиционной. Графические и звуковые API могут быть и кроссплатформенными, однако простоты использования это им не прибавляет. Инициализация все равно будет платформозависимой.
На самом деле даже в рамках работы на одной платформе надо соблюдать ряд правил, чтобы иметь возможность из одного кода получать и 32-битное приложение, и 64-битное тоже. Об этом неплохо написано на сайте разработчиков PVS-Studio.

И все это решается. От части - с помощью архитектурных приемов. Один из таких я уже показывал в другом своем ответе.
И еще эти вопросы можно не решать.
ДубльГИС, например, уже давно работает на базе Qt, что сильно упростило им кроссплатформенную жизнь. Qt решает ряд проблем кроссплатформенности.

По поводу книг добавлю "A tour of C++" от Страуструпа. Подкупает своей компактностью - этакий ликбез для С++-программистов. Из минусов то, что там в кучу С++98 и С++11. Ещё "Overview of the New C++ (C++11/14)" от Мейерса. Это презентационные материалы с его тренинга именно по С++11/14, я там был, отличный тренинг. Из минусов - это всё же слайды презентации, какие-то моменты могут быть не понятны без докладчика. Далее, поскольку у Вас уже есть опыт, вполне подойдёт выделить список тем и разботать каждую в отдельности по статьям, записям с конференций, вопросам на SO (или Тостере :) ).

Что именно читать - не так важно, найдёте сами. Чем мне действительно хотелось бы поделиться, так это мыслями по поводу С++11/14 (будем для краткости называть его С++14, т.к. стандарт уже одобрен). Это не просто "новые фишки в С++". Это качественно новый язык. Разница в стилях кодирования между С++14 и С++98 можно сравнить с разницей между С++98 и С. Не такая радикальная, но сравнимая. Возможности С++14 коснулись практически всех аспектов кода. Я позволю себе выделить наиболее значимые, на мой взгляд, изменения, значимые именно для "рядового" программиста, который не пишет буст и не оптимизирует компиляторы:

• Семантика перемещения*. Контейнеры STL теперь можно возвращать из функции по значению. Строки можно эффективно конкатенировать оператором сложения. Это прекрасно читается.
• Лямбда-функции. Алгоритмами STL можно, наконец, спокойно пользоваться и не бояться вызвать демонов описанием очередного внешнего шаблонного класса-функтора. Логика работы алгоритма теперь указывается ровно там, где он используется.
• auto. Казалось бы, это мелочь. Но теперь имя типов итераторов STL не занимает кучу места в программе (ещё очко в пользу STL). Многие конструкции стали более компактными и ушло ненужное дублирование имени типа (принцип DRY!)
• STL + стандартная библиотека. В С++ чудовищная скудная стандартная библиотека, особенно по сравнению с C#. Но STL, как одна из основных её частей, шагнула вперёд, и не только за счёт других фишек, благодаря которым стало удобно пользоваться тем, что уже было. В ней появились std::unordered_map (хэш-таблицы), std::array и std::tuple - очень полезные в определённых случаях контейнеры. Также добавился ряд полезных алгоритмов (см. доки к заголовочному файлу <algorithm>). А вы знали, что в С++11 есть класс std::Hash, который позволяет считать хэш от произвольных стандартных типов, включая std::string?
• std::function. Мало того, что класс предоставляет механизм универсальных колбэков, он позволяет элегантно написать и легко использовать классы типа ScopeGuard (Страуструп называет его finally). Это даёт новый виток развития парадигме RAII, ключевой и уникальной для С++. Ранее для этих целей использовался кривоватый BOOST_SCOPE_EXIT.
• std::unique_ptr. Благодаря семантике перемещения оказалось возможным создать эффективный умный указатель с монопольным владением объектом. У нас уже был boost::shared_ptr, так что std::shared_ptr не стал таким прорывом.

* Не путать семантику перемещения с r-value references. Последние взрывают мозг. Но это не более чем механизм для реализации семантики перемещения и точной передачи (perfect forwarding). И тем и другим можно прекрасно пользоваться, не заглядывая под капот и не убиваясь в попытках понять, как именно работает эта магия.

По поводу выбора версии Visual Studio. Если есть возможность, лучше использовать VS2013. В ней добавлены такие замечательные и очень полезные возможности С++14, как списки инициализации и инициализация членов класса прямо в месте объявления. В VS2012 этого нет, а по сравнению с VS2010 из интересного в ней появились только range-based циклы, но они не настолько круты. Полный список отличий в MSDN.

В С++14 ещё много, реально МНОГО нового, по сравнению с С++98. Но большая часть либо просто заимствована из boost, так что так или иначе народ этим уже пользовался, либо достаточна специфична. Я постарался выделить именно принципиально новые моменты, которые меняют стиль написания кода. И код на С++14 смотрится гораздо компактнее и понятнее, чем на С++98. Да пребудет с вами С++14. Я кончил. Спасибо.

0. Прочитайте Страуструпа последнее издание (англ). Если язык вы знали то это лучшая книга чтобы обновить знания

1. C++11 C++14, в производстве чаще пока еще С++03
2. Лучший компилятор clang++ (поддерживает любой стандарт и любую платформу)
3. boost это набор библиотек на все случаи жизни самый хорошо сынжинереный. Стоит писать не под него а с использованием
4. пункт 3
5. C++ для задач требующих точного понимания стоимости каждой операции, это embedded DSP Server computing
Math много чего еще

Учтите, С++ это инструмент который нужно учить постоянно

Дополню
-----------
С++ мультипарадигменный
А так же много уровней абстракции поддерживает

На нем можно писать как на чистом С - это самый низкий уровень
Можно ООП и абстракции
Можно паттерны
А можно функциональный стиль

С С++ в этом и проблема что знать нужно очень много.

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

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

Потом Страуструп (тогда это было издание по стандарту 03). Здесь я дополнил свои знания деталями которые пропустил при самостоятельном изучении. Тут стоит отметить что Страуструп весьма странная книга и написана тяжело. Секцию же ООП вообще там лучше не читать (самая последняя).

Где-то рядом я прочитал Гради Буч - ООА и ООП с примерами применения. Очень хорошая кика чтобы понять к чему все это придумали вообще. Сильно выправляла мозги

Потом был Керниган и Ричи Язык программирования С. Эту я прочитал просто от безделья, но теперь считаю что это было необходимо. Здесь можно понять зачем придумали именно С. И насколько там все просто, задумано.

Следом пошли техники: Герб Саттер Решение сложных задач на С++ и Новые сложные задачи С++
читать обязательно, разобрано много костылей и проблем языка. Дано очень много дельных советов

С Мейерс - Эффективное использование С++ туда же. Прекрасный разбор.

Макконнел - Совершенный код. Очень крутая книга. Она отшлифует уже почти бриллиант.

Помимо всего прочего я работал над проектами и постоянно читал всяческие форумы, блоги, дискутировал с коллегами. Решал задачки разных собеседований.

Отдельного внимания заслуживает книга Банды четырех (Паттерны).
Я ее с трудом дочитал, читал ее я уже аж после всего перечисленного и после примерно 7-8 лет опыта С++.
Я уже давно был Senior dev. и наконец нашел таки время и для нее. Она мне показалась до ужаса скучной и очевидной, поскольку почти все предложенные решения я придумывал и сам неоднократно. Кроме того, большинство этих решений неоправданно тяжелы, и очень запутывают код. Тема холиварная и спать надо много, но я пожалуй остановлюсь только на том что в моей практике, худшими с точки зрения цены ошибок были разработчики которые учились начиная с этой книги. Их код недодерживаем запутан и очень плохо поддается рефакторингу. Такой код имеет самые долго отлеживаемые ошибки.

Где-то рядом я прочитал Фаулера - Рефакторинг. Вполне себе неплохо. Рекомендую. Но тут стоит к опытному коллеге обратиться. Идея то проста Тесты - Маленькие комиты - YAGNI KISS и SRP но детали лучше познавать на практике.
У меня был хороший лид, который меня в конце концов научил :)

Совсем забыл! Александреску же! Скажем так - не так страшен Александреску как тот кто его начитался :)
Фана доставил много, а так же дал возможность на эти игрища потерять около 3-х месяцев работы. Даже не знаю
стоит ли читать. Наверное стоит, но нужно помнить что на практике лучше не использовать если вы уже не эксперт.

Остальное С++ не касается, но чтобы стать профессионалом Вам потребуются алгоритмы и структуры данных (Кормен, Кнут), многопоточность (Энтони Уильямс), другие языки(питон, JS, java), оптимизация и профилирование.
и много много разных специфических знаний

Удачи Вам в этом нелегком но, безусловно, интереснейшем пути :)

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

Помните С++ сделан ради свободы выбора средств разработчику. От этого и отталкивайтесь.