Языки программирования игр

ОБЯЗАТЕЛЬНО ДЛЯ НОВИЧКОВ

Всем

Языки программирования игр

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

Исторически игры были одним из первых применений программного кода на электронных вычислительных машинах. Уже в 1950-х годах появлялись игрушки вроде Tennis for Two и Spacewar!, написанные непосредственно на машинных кодах и ассемблерах. С появлением высокоуровневых языков программирования игры стали доступнее для разработки и масштабирования. Тем не менее, из-за высоких требований к производительности и контролю над аппаратными ресурсами в игровой индустрии долгое время доминировали компилируемые языки с ручным управлением памятью и близким доступом к железу.

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

Язык без движка — что реально получится

Прежде чем выбирать C++ или Python, стоит разделить "язык + библиотека" и "язык внутри движка":

Стек Что вы пишете сами Типичный потолок
Python + Pygame цикл, отрисовку, коллизии прямоугольниками змейка, Pong, Match-3, top-down аркада
Java + LibGDX / Swing то же, плюс кроссплатформенный деплой 2D-головоломки, простой платформер
C# + MonoGame низкоуровневый доступ к DirectX/OpenGL через API 2D/лёгкий 3D, ретро-стиль
C# + Unity только gameplay-логику в MonoBehaviour от мобайла до AA; рендер — движок
C++ + Unreal системы и оптимизацию; геймплей — Blueprints или C++ AAA 3D

Игровой цикл (game loop) — сердце любой игры: прочитать ввод → обновить состояние → нарисовать кадр → повторить. На "чистом" стеке вы реализуете его вручную; движок прячет этот каркас и добавляет редактор, физику, анимацию и сборку билдов (Игровой движок).

Минимальный пример на Python (Pygame)

Так выглядит каркас простой 2D-игры без движка — квадрат, который ездит по экрану:

Разбор по строкам:

  • pygame.init() — инициализация подсистем (звук, дисплей, ввод).
  • while running — игровой цикл; без него нет ни одной интерактивной игры.
  • pygame.event.get() — очередь событий ОС (закрытие окна, клики).
  • key.get_pressed() — состояние клавиш прямо сейчас (удобно для непрерывного движения).
  • screen.fill + draw.rect — очистка кадра и отрисовка "игрока" (здесь — прямоугольник).
  • display.flip() — показать кадр на экране.
  • clock.tick(60) — ограничить ~60 FPS, чтобы игра не ускорялась на мощном ПК.

Этого достаточно для учебной аркады. Чтобы добавить анимацию скелета, освещение, сеть на 100 игроков или стриминг open-world, пришлось бы дописывать тысячи строк инфраструктуры — проще взять Unity или Unreal. Готовые мини-игры с построчным разбором — Pygame в Lab; пошаговые проекты — Практикум.

Тот же смысл в Unity (C# внутри движка)

В Unity вы не рисуете каждый кадр вручную — движок вызывает ваш скрипт:

using UnityEngine;

public class PlayerMove : MonoBehaviour
{
    public float speed = 4f;

    void Update()
    {
        float h = Input.GetAxis("Horizontal");
        transform.Translate(h * speed * Time.deltaTime, 0, 0);
    }
}
  • MonoBehaviour — базовый класс компонента; Unity сам вызывает Update() каждый кадр.
  • transform.Translate — сдвиг объекта в сцене; коллизии, камера, освещение уже в движке.
  • Time.deltaTime — шаг времени между кадрами; движение не зависит от FPS.

Полный разбор учебных скриптов — Unity C# — скрипты для новичков.

Когда "чистый язык" — нормальный выбор

  • Обучение — понять цикл, координаты, столкновения (Разработка игр на Python — Python).
  • Олимпиада, курсовая, хакатон — одна механика за вечер.
  • Инструменты в студии — Python-скрипты для генерации уровней или автоматизации сборки (не рантайм игры).
  • Простая 2D-инди — если осознанно принимаете ограничения Pygame/LibGDX.

Когда нужен движок или свой стек

  • 3D, кат-сцены, сложная физика, мультиплеер, консоли.
  • Команда из художников и дизайнеров — им нужен визуальный редактор, а не только код.
  • Live-service, патчи, локализация, античит — инфраструктура движка или in-house платформы (Команда, Издатели).

C

Первые коммерческие видеоигры, включая такие культовые проекты, как Tetris (1984), Doom (1993) и Quake (1996), были написаны на языке C. Это не случайность — в 1980–1990-е годы C был стандартом де-факто для системного программирования, особенно в условиях, где важны были минимальные накладные расходы и прямой контроль над памятью и аппаратными ресурсами.

Язык C предоставляет компактный и предсказуемый машинный код, что критично при работе на платформах с ограниченной памятью и вычислительной мощностью (например, игровые консоли того времени — NES, Sega Genesis, PlayStation 1). Архитектура движков, таких как id Tech (Quake), строилась вокруг чёткого разделения между ядром движка (написанным на C или C++) и игровой логикой (часто на встраиваемых скриптовых языках, таких как QuakeC).

Несмотря на то что чистый C сегодня редко используется для разработки полномасштабных игр, его наследие сохраняется: большинство системных библиотек, графических API и middleware-компонентов по-прежнему предоставляют интерфейсы на C из-за его стабильности ABI (Application Binary Interface) и совместимости.

C++

С переходом к трёхмерной графике в середине 1990-х годов требования к производительности и структуре кода резко возросли. Именно тогда C++ начал вытеснять C как основной язык для разработки игровых движков. Причин несколько.

Во-первых, C++ поддерживает объектно-ориентированное программирование, что позволяет структурировать сложные иерархии игровых сущностей (персонажей, оружия, эффектов), не теряя при этом производительности низкоуровневых операций. Во-вторых, благодаря механизмам шаблонов и inline-функций C++ позволяет писать обобщённый код без накладных расходов времени выполнения. В-третьих, C++ предоставляет полный контроль над управлением памятью, размещением объектов в кэш-дружественных структурах данных и распределением задач по потокам — всё это критически важно для достижения стабильной частоты кадров (60 FPS и выше).

Современные AAA-движки, такие как Unreal Engine, CryEngine, id Tech, Frostbite, написаны в основном на C++. В Unreal Engine, например, основная логика движка, рендерер, физический движок и сетевой стек реализованы на C++, в то время как пользовательская логика может быть реализована в Blueprints (байткод Blueprint VM с вызовами C++ через reflection) или в нативном C++.

Следует подчеркнуть — C++ не "лучше" других языков универсально — он лучше в контексте задач, где важны предсказуемость, низкая задержка и максимальное использование аппаратных возможностей. Однако эта мощь достигается ценой сложности — ручное управление памятью, отсутствие встроенной сборки мусора, необходимость глубокого понимания архитектуры CPU и GPU делают C++ сложным для новичков и трудоёмким в поддержке.

C#

В отличие от C++, язык C#, разработанный Microsoft в начале 2000-х как часть платформы .NET, изначально не предназначался для высокопроизводительных приложений в реальном времени. Однако с появлением и стремительным ростом популярности движка Unity (с 2005 года) C# стал одним из самых распространённых языков в игровой индустрии — особенно среди инди-разработчиков, мобильных студий и образовательных проектов.

Причины выбора C# в Unity многогранны:

  1. Продуктивность разработки. C# обладает современным синтаксисом, богатой стандартной библиотекой, автоматическим управлением памятью (через сборку мусора) и мощной поддержкой IDE (в первую очередь, Visual Studio и Rider). Это позволяет командам быстрее прототипировать, итерировать и выпускать контент.

  2. Безопасность. В отличие от C++, C# изолирует разработчика от прямого доступа к памяти (за исключением unsafe-контекстов), что снижает вероятность критических ошибок вроде buffer overflow или dangling pointers.

  3. Кроссплатформенность через IL2CPP. Unity использует собственную систему трансляции C# в нативный код — IL2CPP (Intermediate Language to C++). Это позволяет компилировать игры на C# для мобильных платформ (iOS, Android), консолей и настольных ОС без необходимости переписывать логику на C++. Хотя это добавляет уровень абстракции, Unity оптимизирует критические участки, особенно в новых версиях движка.

  4. Экосистема и обучаемость. C# проще освоить для начинающих, чем C++. В сочетании с визуальным редактором Unity это сделало движок доступным миллионам разработчиков без академического бэкграунда в computer science.

Для старта на C# удобна галерея Unity C# — скрипты для новичков (каркас MonoBehaviour, движение, триггеры, UI) параллельно с курсом в редакторе и разделом C#.

Тем не менее, C# в Unity имеет ограничения, особенно в части производительности в высоконагруженных сценах. Сборка мусора может вызывать микрофризы, а отсутствие прямого контроля над кэшированием данных усложняет оптимизацию CPU-bound задач. Для частичного преодоления этих ограничений Unity активно развивает DOTS (Data-Oriented Technology Stack) — архитектуру, основанную на data-oriented design и Burst-компиляторе, генерирующем нативный код из C#.

Python

Язык Python обладает рядом качеств, делающих его привлекательным для определённых задач в игровой разработке — простота синтаксиса, интерактивность, богатая стандартная библиотека и быстрое прототипирование. Однако важно чётко разграничивать его потенциальные применения и ограничения.

В промышленной разработке AAA- или даже indie-игр Python не используется как основной язык реализации игрового цикла, особенно если речь идёт о производительности в реальном времени. Причина — интерпретируемая природа языка, динамическая типизация и отсутствие компиляции в нативный код, что приводит к значительным накладным расходам. Даже при использовании JIT-компиляторов (PyPy) или трансляторов в C (Cython, Nuitka), Python не достигает уровня производительности, необходимого для рендеринга, физики или сложной ИИ-логики при высокой частоте кадров.

Тем не менее, Python широко применяется внутри игровых студий в следующих ролях:

  • Инструменты разработки — генераторы уровней, редакторы анимаций, скрипты автоматизации сборки.
  • Серверная логика в многопользовательских играх (например, с использованием Twisted или asyncio), хотя здесь всё чаще предпочтение отдаётся Go, Rust или C++.
  • Образовательные и демонстрационные проекты: библиотеки вроде Pygame, Arcade или Panda3D позволяют быстро создавать 2D-игры или простые 3D-сцены, что делает Python отличным стартовым инструментом для обучения основам игровой логики и событийной модели. Подробнее — Pygame, готовые мини-игры с разбором и Panda3D. В Minecraft Java те же идеи (условие, счётчик, цикл) можно отработать через команды и datapack — без отдельного IDE, прямо в мире.

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

Java и Kotlin

На заре мобильной эры (2000-е годы) игры для телефонов с кнопочной клавиатурой и ограниченным экраном часто писались на Java ME (Micro Edition). Эта платформа обеспечивала кроссплатформенность между устройствами разных производителей и использовала ограниченный подмножество Java с собственной виртуальной машиной (KVM). Игры вроде Snake, Bounce или Asphalt: Urban GT стали культовыми благодаря именно Java ME.

С приходом Android в 2008 году ситуация изменилась. Хотя Android изначально использовал Dalvik VM, а затем Android Runtime (ART), основной язык разработки остался Java. В течение более чем десяти лет Java была доминирующим языком для Android-приложений, включая игры.

Однако для полноценных 3D- или высокопроизводительных 2D-игр даже на Android Java редко используется напрямую. Причины:

  • Сборка мусора в ART может вызывать непредсказуемые паузы.
  • Ограниченный контроль над памятью и кэшированием.
  • Недостаточная производительность для тяжёлых вычислений.

Вместо этого Android-игры чаще всего создаются с использованием:

  • Unity (C#) или Unreal Engine (C++), которые компилируются в нативный код и интегрируются в APK через соответствующие плагины.
  • Нативного C++ через Android NDK (Native Development Kit (NDK)), особенно если требуется максимальная производительность или интеграция с существующими C++-библиотеками.

Тем не менее, для простых 2D-игр (например, головоломок, карточных приложений) Java остаётся допустимым выбором, особенно в связке с фреймворками вроде LibGDX, который предоставляет кроссплатформенный API и компилирует Java-код в нативные бинарники для Android, iOS и десктопа.

С 2017 года Google официально поддерживает Kotlin как предпочтительный язык для Android-разработки. Kotlin сочетает в себе лаконичность и безопасность (null-safety, неизменяемость по умолчанию) с полной совместимостью с Java-библиотеками. В контексте игровой разработки Kotlin пока не получил широкого распространения как основной язык для игр, но может использоваться для написания UI-слоёв, меню или серверной логики.

Swift и Objective-C

На экосистеме Apple разработка игр исторически шла двумя путями:

  1. Собственные нативные игры с использованием SpriteKit (2D) и SceneKit (3D) — фреймворков от Apple, написанных на Objective-C и позже адаптированных под Swift.
  2. Кроссплатформенные игры через Unity, Unreal или Godot, где Swift/Objective-C используются только для интеграции с нативными API (например, Game Center, In-App Purchases, push-уведомления).

Objective-C, как язык объектно-ориентированного расширения C, долгое время был основным языком разработки под macOS и iOS. Его динамическая природа и runtime-интроспекция позволяли гибко управлять объектами, но за счёт производительности и сложности отладки. С появлением Swift в 2014 году Apple начала постепенный переход к более безопасному, быстрому и выразительному языку.

Swift компилируется в нативный код через LLVM, поддерживает value types (structs, enums), автоматическое управление памятью через ARC (Automatic Reference Counting) и предлагает высокую производительность — близкую к C++ в некоторых сценариях. Это делает Swift приемлемым выбором для 2D-игр и лёгких 3D-проектов, особенно в образовательной среде или при разработке мини-игр внутри приложений.

Тем не менее, для серьёзных проектов разработчики предпочитают использовать движки вроде Unity (C#) или Unreal (C++), компилируя их под iOS, а Swift оставляют для обёрток и интеграций.

JavaScript и TypeScript

С развитием HTML5, WebGL и мощных браузеров JavaScript стал де-факто стандартом для разработки веб-игр. Возможность запускать игру без установки, мгновенно распространять через URL и интегрировать с веб-сервисами делает этот подход привлекательным для казуальных, обучающих и рекламных проектов.

Однако JavaScript — интерпретируемый язык с динамической типизацией, что накладывает серьёзные ограничения на производительность и масштабируемость. Для преодоления этих ограничений появились:

  • WebGL: низкоуровневый API для рендеринга 2D/3D графики в браузере, основанный на OpenGL ES. Напрямую использовать WebGL сложно, поэтому чаще применяют библиотеки.
  • Фреймворки и движки:
    • Phaser — популярный 2D-движок с поддержкой Canvas и WebGL, ориентированный на быструю разработку.
    • Three.js — библиотека для 3D-графики, упрощающая работу с WebGL.
    • Babylon.js, PlayCanvas — более продвинутые 3D-движки с редакторами и поддержкой физики.
    • Godot Engine (экспорт в HTML5) — позволяет писать игру на GDScript или C# и экспортировать в веб.

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

Важно понимать: веб-игры принципиально ограничены средой браузера. Они не имеют прямого доступа к файловой системе, ограничены по памяти, подвержены блокировке фоновых вкладок и зависят от производительности JavaScript-движка (V8, SpiderMonkey и др.). Поэтому веб — это ниша для казуальных, социальных или демонстрационных игр, но не для требовательных проектов.

Графические API

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

DirectX (Microsoft)

  • Платформа: исключительно Windows и Xbox.
  • Версии — DirectX 11 (широко совместим), DirectX 12 (низкоуровневый, требует явного управления ресурсами).
  • Особенности — тесная интеграция с Windows, отличная поддержка в инструментах профилирования (PIX, Visual Studio Graphics Debugger). DirectX 12 позволяет достичь производительности, сопоставимой с Vulkan, но только на экосистеме Microsoft.

OpenGL

  • Платформа — кроссплатформенный (Windows, Linux, macOS до 2018 г., Android через OpenGL ES).
  • Особенности: высокоуровневый, с автоматическим управлением состояниями. Устарел на macOS и уступает Vulkan по производительности. OpenGL ES (Embedded Systems) до сих пор используется в лёгких мобильных играх.

Vulkan

  • Платформа — Windows, Linux, Android, Nintendo Switch.
  • Особенности — низкоуровневый, явное управление памятью, потоками и синхронизацией. Предоставляет максимальный контроль над GPU, но требует значительно больше кода и экспертизы. Используется в современных движках (Unreal Engine 4/5, Unity через SRP).

Metal (Apple)

  • Платформа — iOS, macOS, tvOS.
  • Особенности — низкоуровневый API от Apple, аналог Vulkan, но оптимизированный под архитектуру Apple Silicon и GPU от Imagination Technologies/AMD. Обязателен для высокопроизводительной графики на устройствах Apple.

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

Скриптовые языки

С самого зарождения игровой индустрии существует принципиальное разделение между ядом движка и игровой логикой. Ядро — это низкоуровневая, производительная, стабильная подсистема, отвечающая за рендеринг, физику, аудио, сеть и управление памятью. Игровая логика — это правила — как ведёт себя персонаж, что происходит при взаимодействии с объектом, как развивается сюжет. Эта логика часто меняется в процессе разработки, требует быстрой итерации и должна быть доступна программистам и гейм-дизайнерам.

Для этих целей используются встраиваемые скриптовые языки, отличающиеся лёгкостью интеграции, изолированностью выполнения и простотой синтаксиса.

Lua

Lua — безусловный лидер в этой нише. Разработанный в 1993 году в Бразилии, он сочетает минимализм (всего 21 ключевое слово), быстрый интерпретатор на C, лёгкую интеграцию с хост-языком и гибкую модель данных на основе таблиц.

Примеры использования:

  • World of Warcraft: пользовательские интерфейсы и аддоны пишутся на Lua.
  • Roblox: весь пользовательский контент (игры, объекты) — на Lua (в варианте Luau).
  • CryEngine, Lumberyard, Garry’s Mod, Factorio — все используют Lua для скриптов игровых событий.

Преимущества Lua:

  • Размер интерпретатора — менее 300 КБ.
  • Полный контроль над средой выполнения (можно изолировать скрипты или ограничить ресурсы).
  • Возможность горячей перезагрузки скриптов без перезапуска игры.

Недостатки:

  • Отсутствие статической типизации (хотя Luau частично это компенсирует).
  • Не предназначен для тяжёлых вычислений.

AngelScript, Squirrel, GDScript

  • AngelScript (C++-подобный синтаксис) используется в движках вроде Amnesia и TowerFall. Поддерживает прямую передачу объектов C++ в скрипты.
  • Squirrel — альтернатива Lua с поддержкой классов и генераторов; применялся в Left 4 Dead 2 и Final Fantasy Crystal Chronicles.
  • GDScript — язык, созданный специально для движка Godot. Синтаксис близок к Python, но скомпилирован в байткод и оптимизирован под сценовую архитектуру Godot. Не выходит за пределы движка, но обеспечивает отличную производительность внутри него.

Ключевой вывод — скриптовые языки не заменяют C++ или C# — они дополняют их, обеспечивая гибкость там, где скорость разработки важнее предельной производительности.

Языки шейдеров

Рендеринг в современных играх — это не просто вызов функции "нарисовать треугольник". Это выполнение программ на графическом процессоре, написанных на специализированных языках, ориентированных на массово-параллельную обработку.

Эти языки не являются универсальными — они компилируются в машинный код GPU и выполняются в строго определённых этапах графического конвейера (vertex shader, fragment/pixel shader, compute shader и др.).

HLSL (High-Level Shading Language)

  • Платформа: DirectX (Windows, Xbox).
  • Особенности — синтаксис, близкий к C, тесная интеграция с DirectX. Используется в Unreal Engine, Unity (при выборе DirectX-бэкенда).

GLSL (OpenGL Shading Language)

  • Платформа — OpenGL, OpenGL ES, WebGL.
  • Особенности — похож на C, но с ограничениями (нет рекурсии, динамических аллокаций). Каждый шейдер — отдельный файл с точками входа.

Metal Shading Language (MSL)

  • Платформа: Apple (Metal API).
  • Особенности: основан на C++14, поддерживает шаблоны и объектно-ориентированные конструкции. Компилируется в IR (Intermediate Representation), затем в машинный код GPU.

Кроссплатформенность через промежуточные представления

Современные движки (Unreal, Unity, Godot) всё чаще используют универсальный шейдерный код на HLSL, который затем транслируется в другие языки через промежуточный формат SPIR-V (Standard Portable Intermediate Representation). Это позволяет писать шейдер один раз и запускать его на Vulkan, Metal и даже WebGL (через дополнительные преобразования).

Шейдеры — это отдельная дисциплина, требующая понимания синтаксиса и архитектуры GPU, кэширования, bandwidth и latency. Ошибка в шейдере может привести не к падению программы, а к артефактам, перегреву или катастрофическому падению FPS.

Эмерджентные языки и будущие тренды

Хотя C++, C# и Lua доминируют сегодня, индустрия ищет альтернативы, сочетающие безопасность, производительность и модернизацию инструментария.

Rust

Rust привлекает внимание благодаря:

  • Отсутствию сборщика мусора при гарантии отсутствия data races и dangling pointers.
  • Zero-cost abstractions и прямой компиляции в нативный код.
  • Растущей экосистемой (Bevy — игровой движок на Rust).

Однако Rust пока не используется в крупных коммерческих играх. Причины: сложность владения borrow checker’ом в контексте циклических ссылок (типично для игровых сущностей), отсутствие зрелых инструментов профилирования и долгое время компиляции. Тем не менее, Rust активно применяется в инструментах разработки, серверной логике и мидлваре.

WebGPU и новые веб-стандарты

WebGPU — следующее поколение графического API для браузеров, призванный заменить WebGL. Он предоставляет Vulkan/Metal/Direct12-подобный интерфейс с поддержкой compute shaders и асинхронного выполнения. Написание кода для WebGPU пока ведётся на JavaScript/TypeScript, но в будущем возможно появление компиляции из Rust или C++ через WebAssembly с прямым доступом к GPU.

Zig, Odin, и другие системные языки

Языки вроде Zig и Odin позиционируются как "C без боли" — с современными конструкциями, но без рантайма. Пока они остаются нишевыми, но в инди-разработке уже появляются экспериментальные движки на этих языках.

Многоязыковая архитектура современной игры

Типичный AAA-проект сегодня — это сложная многоуровневая система, в которой участвуют:

Уровень Язык / Технология Назначение
Ядро движка C++ Рендеринг, физика, память, сеть
Игровая логика C# (Unity) / Blueprints + C++ (Unreal) / Lua Поведение персонажей, квесты, события
Шейдеры HLSL / GLSL / MSL Визуальные эффекты, освещение
Инструменты Python, C#, JavaScript Редакторы, билд-системы, аналитика
Серверная часть C++, Rust, Go Многопользовательская логика
Веб-компоненты TypeScript, WebGL Страницы продвижения, мини-игры

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

Где смотреть реальные кодовые базы

Учебные примеры в движке редко показывают полный масштаб AAA-проекта. Сообщественный каталог Open Source Game Clones (глава 125) индексирует репозитории по языку (langs), движку (frameworks) и зрелости (Playable, Very Active). Удобный приём: выбрать клон в том же стеке, что и ваш трек (C# / Unity, C++ / SDL, Luau после Roblox), собрать проект и искать в коде один узкий вопрос — pathfinding, инвентарь, сетевой тик. Там же — подборка по стекам с прямыми ссылками на GitHub.