Дело не в том, что абстрактная модель данных питона предполагает, что всё является объектами. В яваскрипте делается попытка сделать точно такое же предположение и он прекрасно используется в HTML5-играх. Главное ограничение, из-за которого в разработке игр на первом месте стоит C++ или вообще чистый С - это работа с памятью. В питоне на фундаментальном уровне используется сборщик мусора (без него ничего работать не будет), и начиная с некоторого размера и сложности игры это смертный приговор. Для некоторых AAA-проектов эффективная работа с оперативной памятью это настолько критично, что для движка пишут свой собственный менеджер памяти, отдельный от операционной системы той машины, где игра будет запускаться.
Тем не менее, да, питон для игр актуален. Вообще, для того, чтобы у вас была, технически, игра, вам нужно четыре кардинальных вещи:
- рендерить графику;
- воспроизводить звук;
- обрабатывать логику мира игры
- и обрабатывать ввод команд от игрока.
Все эти компоненты уже существуют в виде готовых библиотек (что характерно, чаще всего скомпилированных или из C, или из C++) (примеры вразброс: SDL2, OpenAL, Raylib, XInput), и любой язык, способный обращаться к ним, годится для того, чтобы собрать на нём игру. Включая питон.
Но насколько эффективен данный язык программирования для игр, даже с использованием NumPy?
Конечно, быстрая числодробилка поможет, но как я уже упомянул, ключевая проблема использования в играх Python и всех вообще языков с автоматической сборкой мусора это собственно сборщик мусора.
Вы просто не сможете по-настоящему эффективно реализовать ни
пул кэшированных объектов, ни
Flyweight в языке, который не даёт вам контроля и гарантий того, в каком порядке, где и как надолго вам выдаётся память. Вы можете потратить очень много сил на то, чтобы игрок не испытал в неподходящий момент "остановку мира" потому что GC захотелось вот именно сейчас прибраться в памяти.
Кроме того, как язык с динамической типизацией, питон на каждый объект данных в памяти тратит некоторое дополнительное количество памяти на метаданные, в частности, на данные о типе.
Вот отличный доклад Яндекса о кишках питона, в разделе "Типизация" объяснено, о чём я говорю. Если вам нужно хранить информацию, например, о двух миллиардах актёров на вашей сцене, overhead даже в одно лишнее поле в объекте может стать причиной сменить язык программирования.
Вы не увидите проблем, о которых я говорю, в маленьких играх, но это не значит, что их нет.
Возможно ли сделать рабочую 3д игру с примитивной графикой так, чтобы в это комфортно было играть?
Конечно, можно. Вот питонячьи биндинги к OpenGL:
https://github.com/moderngl/moderngl Примитивная графика или нет определяется в значительной степени не самим рендерером, а вашими художниками по моделям и текстурам. Для пользовательского ввода я вот за пару минут нагуглил
https://pypi.org/project/pynput/ Всё, можно делать игру. Насчёт комфорта уже всё в ваших руках как разработчика - как я уже несколько раз упомянул, до определённого масштаба игры современное железо без проблем воспроизведёт вам игру на питоне с приемлемой частотой обновления кадров и отзывчивостью ввода.