Viktor T2

import base64

text = 'eyJzaWQiOiJmYVVGVjBpTVo2OTRpY3BTVnhsMGJNbzBaUEJGTmcyWiIsImFpZCI6bnVsbCwiZXhwIjoxNjY3MTQ4NTQyfQ'
print(base64.b64decode(text + "=="))

Пожалуйста

Правильный ответ

print(base64.b64decode(text + '=' * (-len(text) % 4)))

Все же написано в сообщении об ошибке. Строка не добита символами = до нужной длины, чтобы быть кратной 4

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

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

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

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

1. Для системных тулов, мат. вычисления, веб
2. Множество готовых батареек, качественные веб-фреймворки, живое и дружелюбное сообщество
3. Если мнение авторов питона - на сайте, мое - замечательный синтаксис, соотношение "скорость разработки - качество кода - скорость выполнения" одна из самых высоких
4. Сегодня - питон (много работы, высокие зарплаты). Завтра - скорее всего java (очень активно идет развитие стека typesafe и, мне кажется, что в будущем он займет свою довольно внушительную нишу в веб разработке. Но это завтра может настать очень не скоро, если вообще настанет. Ну и это все таки не для веб студий и не для сайтов-визиток вариант. Проекты сложности выше средней с долгосрочной поддержкой). RoR - работы меньше, оплата еще выше. Пхп - работы горы, зарплаты намного меньше. Но вообще трудно сказать. Есть еще nodejs (развивается гигантскими скачками), но не могу про него ничего сказать толкового. Работы под него довольно много, но как изнутри не знаю.
А вообще сейчас набегут Рубисты, Явисты, Пхпшники и начнется холивар, поэтому надо текать ) Изучив любой из php\python\ruby на достаточном уровне и выдавая качественный код Вы будете востребованы как специалист еще довольно долго.

Вместо base64 можно использовать условный base65.
Он тоже "избыточен", но в любом случае всё упирается в ограничения тех текстовых систем, через которые должно проходить изображение в виде текста.
Например, если все системы поддерживают ASCII, то можно расшириться до условного base127, например. Можно ли использовать спец. символы, какие именно - вам виднее, это будет конкретное ограничение конкретной проблемы, которую вы решаете.

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

Однако у вас ведь информация не совсем произвольная. Поэтому зачем вам универсальное решение? Пусть решение решает конкретно вашу узкую проблему по пересылке именно изображений, а не любой информации. Можно попытаться сжать само изображение.

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

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

Почти везде, это язык общего назначения. Понятно, что на нём не пишут операционные системы, драйвера и прошивки, так как он интерпретируемый.

Можно поставить atop и настроить сохранение снапшотов информации о процессах.

Для начала стоит поставить себе Linux.
Почитать книгу, например.

Самое главное - практиковаться

Я научился, когда снес Windows на своем рабочем компьютере, и установил Linux.

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